Asp Forum - how do you manage your gems' gemspecs?

ghorner

4/10/2009 2:58:00 AM

Hi,
I'm curious how people manage creating their gemspecs. I'm not
asking for a flame war on gem creators i.e. hoe vs newgem vs jeweler.
I'm just wondering if your gem creators encourage creating Rakefiles
with some gemspec configuration inside of it. If so, how do you do
this gem after gem and not get annoyed that you're not being DRY?
I ended up going with a solution where I generate all my gem's
gemspecs from one config file: http://github.com/cldwalker/dotfiles/blob/master....
I wrote more about my solution here:
http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-je...
How do you manage your gems' gemspecs?

Gabriel

14 Answers

Luis Lavena

4/10/2009 3:52:00 AM

On Apr 9, 11:57 pm, ghorner <gabriel.hor...@gmail.com> wrote:
> Hi,
> I'm curious how people manage creating their gemspecs. I'm not
> asking for a flame war on gem creators i.e. hoe vs newgem vs jeweler.
> I'm just wondering if your gem creators encourage creating Rakefiles
> with some gemspec configuration inside of it. If so, how do you do
> this gem after gem and not get annoyed that you're not being DRY?
> I ended up going with a solution where I generate all my gem's
> gemspecs from one config file:http://github.com/cldwalker/dotfiles/blob/master....
> I wrote more about my solution here:http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-......
> How do you manage your gems' gemspecs?
>

Manually built... nah, just kidding ;-)

rake-compiler gemspec is strictly YAML, and plays as a manifest file
so there is no glob in that.

I can diff it before committing, since every time the gemspec is
updated the gem is generated in GitHub.

http://github.com/luislavena/rake-compiler/blob/master/task...

I'm not fond for one place for everything as configuration files. The
thing with that is that I need to go to some other place every time I
need to update the gemspec or any kind of info.

Just my two cents,
--
Luis Lavena

ghorner

4/10/2009 4:52:00 AM

Nice rake task. I didn't know github gems allow for yaml gemspecs. For
me it's worth having one gemspec config file outside of my gem
directory in exchange for being DRY i.e. not having to write the same
common gemspec attributes for every gem.

Gabriel

On Apr 9, 11:52 pm, Luis Lavena <luislav...@gmail.com> wrote:
> On Apr 9, 11:57 pm, ghorner <gabriel.hor...@gmail.com> wrote:
>
> > Hi,
> > I'm curious how people manage creating their gemspecs. I'm not
> > asking for a flame war on gem creators i.e. hoe vs newgem vs jeweler.
> > I'm just wondering if your gem creators encourage creating Rakefiles
> > with some gemspec configuration inside of it. If so, how do you do
> > this gem after gem and not get annoyed that you're not being DRY?
> > I ended up going with a solution where I generate all my gem's
> > gemspecs from one config file:http://github.com/cldwalker/dotfiles/blob/master....
> > I wrote more about my solution here:http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-......
> > How do you manage your gems' gemspecs?
>
> Manually built... nah, just kidding ;-)
>
> rake-compiler gemspec is strictly YAML, and plays as a manifest file
> so there is no glob in that.
>
> I can diff it before committing, since every time the gemspec is
> updated the gem is generated in GitHub.
>
> http://github.com/luislavena/rake-compiler/blob/master/task...
>
> I'm not fond for one place for everything as configuration files. The
> thing with that is that I need to go to some other place every time I
> need to update the gemspec or any kind of info.
>
> Just my two cents,
> --
> Luis Lavena

Luis Lavena

4/10/2009 1:29:00 PM

On Apr 10, 1:51 am, cldwalker <gabriel.hor...@gmail.com> wrote:
> Nice rake task. I didn't know github gems allow for yaml gemspecs. For
> me it's worth having one gemspec config file outside of my gem
> directory in exchange for being DRY i.e. not having to write the same
> common gemspec attributes for every gem.
>
> Gabriel
>

In theory to be SAFE, the gem builder prefers YAML over Ruby code.

Keeping the common attributes outside your repository reduces the
clarity of your code since other users (besides you) can contribute
with the project.

Regards,
--
Luis Lavena

Juan Zanos

4/10/2009 2:01:00 PM

On 10 avr. 09, at 09:30, Luis Lavena wrote:

> On Apr 10, 1:51 am, cldwalker <gabriel.hor...@gmail.com> wrote:
>> Nice rake task. I didn't know github gems allow for yaml gemspecs.
>> For
>> me it's worth having one gemspec config file outside of my gem
>> directory in exchange for being DRY i.e. not having to write the same
>> common gemspec attributes for every gem.
>>
>> Gabriel
>>
>
> In theory to be SAFE, the gem builder prefers YAML over Ruby code.
>
> Keeping the common attributes outside your repository reduces the
> clarity of your code since other users (besides you) can contribute
> with the project.
>
> Regards,
> --
> Luis Lavena
>

DRY is a useful principle, but when the code required to implement it
is larger than repeating something simple you might consider whether
it's appropriate. In this case the things you are trying to avoid
repeating are simple and memorable - such as your own name. There's
also the concern that anyone building your gem might accidentally be
labeled as the original author. There are other valuable principles
you might want to balance, such as the KEIOPSPCFIE (keep everything
in one place so people can find it easily ) principle.

Best,
Juan

David Masover

4/10/2009 3:36:00 PM

On Friday 10 April 2009 09:01:04 Juan Zanos wrote:
> DRY is a useful principle, but when the code required to implement it
> is larger than repeating something simple you might consider whether
> it's appropriate.

Worth mentioning, it still might be worthwhile. For example, it might be
something simple, but something that may change in the future. Or it might be
repeated so often that the code to implement it (kept in one place) is smaller
than the combined places where it's pasted.

> In this case the things you are trying to avoid
> repeating are simple and memorable - such as your own name.

Yeah, in that case, it probably doesn't matter.
I suspect there's more to a gemspec than that, though.

ghorner

4/10/2009 5:14:00 PM

On Apr 10, 9:28 am, Luis Lavena <luislav...@gmail.com> wrote:
> On Apr 10, 1:51 am, cldwalker <gabriel.hor...@gmail.com> wrote:
>
> > Nice rake task. I didn't know github gems allow for yaml gemspecs. For
> > me it's worth having one gemspec config file outside of my gem
> > directory in exchange for being DRY i.e. not having to write the same
> > common gemspec attributes for every gem.
>
> > Gabriel
>
> In theory to be SAFE, the gem builder prefers YAML over Ruby code.
>
> Keeping the common attributes outside your repository reduces the
> clarity of your code since other users (besides you) can contribute
> with the project.
>
> Regards,
> --
> Luis Lavena

Luis,
My one config file isn't keeping the common gemspec attributes
outside of the gem. I still generate and ship all of my gems with the
full gemspec. I just like to generate my gemspec from one central, DRY
location.

Someone brought up a similar point about not shipping my gem with its
meta gemspec i.e. the rake tasks that generate my gemspec using file-
related globs. I think that's a valid point so I updated the end of my
post with a solution to it(http://tagaholic.me/2009/04/08/bui...
gems-with-thor-and-jeweler). I basically generate from my central
config and ship with my gem a yaml containing globbish gemspec
attributes to be used by a rake task.

Gabriel

ghorner

4/10/2009 5:20:00 PM

> DRY is a useful principle, but when the code required to implement it
> is larger than repeating something simple you might consider whether
> it's appropriate. In this case the things you are trying to avoid

Actually the code required to implement it is 60 lines (1/4 spent on
documentation):
http://github.com/cldwalker/thor-tasks/blob/8901b806cbdacd30b6dcbf92ca2968de892c785d/jeweler.thor/gemspec_...

> repeating are simple and memorable - such as your own name. There's
> also the concern that anyone building your gem might accidentally be
> labeled as the original author. There are other valuable principles
> you might want to balance, such as the KEIOPSPCFIE (keep everything
> in one place so people can find it easily ) principle.

I probably didn't make it clear but I would still be shipping my gem's
with their gemspec.
I just prefer generating them from one central location. This
principle would be preserved since I ship gems with their gemspec.

Gabriel

Luis Lavena

4/10/2009 6:13:00 PM

On Apr 10, 2:20 pm, cldwalker <gabriel.hor...@gmail.com> wrote:
> > DRY is a useful principle, but when the code required to implement it
> > is larger than repeating something simple you might consider whether
> > it's appropriate. In this case the things you are trying to avoid
>
> Actually the code required to implement it is 60 lines (1/4 spent on
> documentation):http://github.com/cldwalker/thor-tasks/blob/8901b806cbdacd3......
>
> > repeating are simple and memorable - such as your own name. There's
> > also the concern that anyone building your gem might accidentally be
> > labeled as the original author. There are other valuable principles
> > you might want to balance, such as the KEIOPSPCFIE (keep everything
> > in one place so people can find it easily ) principle.
>
> I probably didn't make it clear but I would still be shipping my gem's
> with their gemspec.
> I just prefer generating them from one central location. This
> principle would be preserved since I ship gems with their gemspec.
>

Well, what happens if I configure the central location in my machine
with different values than yours?

The thing is that you're generating the gemspec for that gem from a
central location. We all know that the gemspec gets bundled with the
gem itself, the problem is the generator tasks and the obscure process
of updating the gemspec without knowing where the central location is.

Sometimes DRY is overrated.

--
Luis Lavena

ghorner

4/10/2009 11:14:00 PM

On Apr 10, 2:13 pm, Luis Lavena <luislav...@gmail.com> wrote:
> On Apr 10, 2:20 pm, cldwalker <gabriel.hor...@gmail.com> wrote:
>
>
>
> > > DRY is a useful principle, but when the code required to implement it
> > > is larger than repeating something simple you might consider whether
> > > it's appropriate. In this case the things you are trying to avoid
>
> > Actually the code required to implement it is 60 lines (1/4 spent on
> > documentation):http://github.com/cldwalker/thor-tasks/blob/8901b806cbdacd3......
>
> > > repeating are simple and memorable - such as your own name. There's
> > > also the concern that anyone building your gem might accidentally be
> > > labeled as the original author. There are other valuable principles
> > > you might want to balance, such as the KEIOPSPCFIE (keep everything
> > > in one place so people can find it easily ) principle.
>
> > I probably didn't make it clear but I would still be shipping my gem's
> > with their gemspec.
> > I just prefer generating them from one central location. This
> > principle would be preserved since I ship gems with their gemspec.
>
> Well, what happens if I configure the central location in my machine
> with different values than yours?
>
> The thing is that you're generating the gemspec for that gem from a
> central location. We all know that the gemspec gets bundled with the
> gem itself, the problem is the generator tasks and the obscure process
> of updating the gemspec without knowing where the central location is.
>
> Sometimes DRY is overrated.
>
> --
> Luis Lavena

If you look at the gemspec_update task in my post, you'll see that the
gemspec values won't differ.
There's nothing obscure about doing rake gemspec_update.

Gabriel

Eric Hodel

4/13/2009 9:04:00 PM

On Apr 9, 2009, at 20:00, ghorner wrote:

> I'm curious how people manage creating their gemspecs. I'm not
> asking for a flame war on gem creators i.e. hoe vs newgem vs jeweler.
> I'm just wondering if your gem creators encourage creating Rakefiles
> with some gemspec configuration inside of it. If so, how do you do
> this gem after gem and not get annoyed that you're not being DRY?
> I ended up going with a solution where I generate all my gem's
> gemspecs from one config file: http://github.com/cldwalker/dotfiles/blob/master...
> .

This makes it harder for other people to develop with your gems. Now
they need two things in order to build your gems if they want to
install a gem.

Using globs is a bad idea, you end up including files you don't want
in your gem. A manifest file that gets automatically checked at
release time solves this problem elegantly.

> I wrote more about my solution here:
> http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-je...
> How do you manage your gems' gemspecs?

I keep them per-project and largely generate them from the non-Rakefile:

Hoe.new('gmail_contacts', GmailContacts::VERSION) do |p|
p.rubyforge_name = 'seattlerb'
p.developer 'Eric Hodel', 'drbrain@segment7.net'

p.extra_deps << ['gdata', '~> 1.0']
p.extra_deps << ['nokogiri', '~> 1.2']
end

description, summary, and homepage are all figured out for me from the
README.txt

comp.lang.ruby

how do you manage your gems' gemspecs?

ghorner

Luis Lavena

ghorner

Luis Lavena

Juan Zanos

David Masover

ghorner

ghorner

Luis Lavena

ghorner

Eric Hodel

x Login to ForumsZone