how do you manage your gems' gemspecs?

Discussion in 'Ruby' started by ghorner, Apr 10, 2009.

  1. ghorner

    ghorner Guest

    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/.gems.yml.
    I wrote more about my solution here:
    http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jeweler.html
    How do you manage your gems' gemspecs?

    Gabriel
     
    ghorner, Apr 10, 2009
    #1
    1. Advertising

  2. ghorner

    Luis Lavena Guest

    On Apr 9, 11:57 pm, ghorner <> 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/.gems.yml.
    > I wrote more about my solution here:http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jewele...
    > 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/tasks/gem.rake

    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, Apr 10, 2009
    #2
    1. Advertising

  3. ghorner

    cldwalker Guest

    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 <> wrote:
    > On Apr 9, 11:57 pm, ghorner <> 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/.gems.yml.
    > > I wrote more about my solution here:http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jewele...
    > > 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/tasks/gem.rake
    >
    > 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
     
    cldwalker, Apr 10, 2009
    #3
  4. ghorner

    Luis Lavena Guest

    On Apr 10, 1:51 am, cldwalker <> 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 Lavena, Apr 10, 2009
    #4
  5. ghorner

    Juan Zanos Guest

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

    > On Apr 10, 1:51 am, cldwalker <> 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
     
    Juan Zanos, Apr 10, 2009
    #5
  6. 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.
     
    David Masover, Apr 10, 2009
    #6
  7. ghorner

    cldwalker Guest

    On Apr 10, 9:28 am, Luis Lavena <> wrote:
    > On Apr 10, 1:51 am, cldwalker <> 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/building-dry-
    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
     
    cldwalker, Apr 10, 2009
    #7
  8. ghorner

    cldwalker Guest


    > 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-ta...968de892c785d/jeweler.thor/gemspec_builder.rb

    > 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
     
    cldwalker, Apr 10, 2009
    #8
  9. ghorner

    Luis Lavena Guest

    On Apr 10, 2:20 pm, cldwalker <> 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/8901b806cbdacd30b6dcbf92c...
    >
    > > 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
     
    Luis Lavena, Apr 10, 2009
    #9
  10. ghorner

    cldwalker Guest

    On Apr 10, 2:13 pm, Luis Lavena <> wrote:
    > On Apr 10, 2:20 pm, cldwalker <> 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/8901b806cbdacd30b6dcbf92c...

    >
    > > > 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
     
    cldwalker, Apr 11, 2009
    #10
  11. ghorner

    Eric Hodel Guest

    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/.gems.yml
    > .


    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-jeweler.html
    > 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', ''

    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
     
    Eric Hodel, Apr 13, 2009
    #11
  12. ghorner

    cldwalker Guest

    On Apr 13, 5:04 pm, Eric Hodel <> wrote:
    > 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/.gems.yml
    > > .

    >
    > 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.


    My gem's build dependency is a config file containing file globs. This
    is no more of an extra dependency than a manifest file or a Rakefile
    with embedded file globs. Since my gem rebuilding doesn't depend on my
    global config file, I'm not sure what two things you're referring to
    and why it'd be harder for someone ...
    Actually, when rebuilding my contributors would have one less
    dependency: no gem creator dependency (i.e. no hoe or jeweler
    dependency). Just with the rake task mentioned at the end of my post,
    they could rebuild my gems.

    >
    > 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.


    Since I'd be generating my manifest file from a rake task using globs,
    I'm not sure how manifest files help.
    If you're creating manifest files by hand, then that's a level of file-
    checking I personally don't want for every file change.

    >
    > > I wrote more about my solution here:
    > >http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jewele...
    > > 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', ''
    >
    >    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


    Thanks for sharing. I prefer my gem metadata in an open format i.e.
    yaml. Having to extract them from the readme and/or a Hoe or Jeweler
    config just adds more work and dependencies.
     
    cldwalker, Apr 14, 2009
    #12
  13. ghorner

    Eric Hodel Guest

    On Apr 13, 2009, at 21:45, cldwalker wrote:
    > On Apr 13, 5:04 pm, Eric Hodel <> wrote:
    >> 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/.gems.yml
    >>> .

    >>
    >> 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.

    >
    > My gem's build dependency is a config file containing file globs. This
    > is no more of an extra dependency than a manifest file or a Rakefile
    > with embedded file globs. Since my gem rebuilding doesn't depend on my
    > global config file, I'm not sure what two things you're referring to
    > and why it'd be harder for someone ...


    With what you've described, if I want to build a gem of yours from
    source, first I have to download the source for your project, then I
    have to go find your ~/.gems.yml, download it, then merge it into my
    ~/.gems.yml (if I was following your scheme) and keep them up to date
    when either my gems or your gems change.

    Having to download from a separate repository is an extra dependency.

    > Actually, when rebuilding my contributors would have one less
    > dependency: no gem creator dependency (i.e. no hoe or jeweler
    > dependency). Just with the rake task mentioned at the end of my post,
    > they could rebuild my gems.


    So if I don't need ~/.gems.yml, why do you need or have it? It seems
    to be a useless extra file.

    >> 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.

    >
    > Since I'd be generating my manifest file from a rake task using globs,
    > I'm not sure how manifest files help.


    There's no way to verify your glob is correct without manually
    checking it every release as it has no history to compare against.

    Using a glob, eventually you'll forget to release a file, or release
    files that shouldn't be there (I've worked on around 50 gems, and
    released a few hundred, and this happens with globs). A manifest file
    can ensure you won't have either problem.

    With a manifest file you can see what has been added or removed easily
    using diff.

    > If you're creating manifest files by hand, then that's a level of
    > file-
    > checking I personally don't want for every file change.


    I don't edit manifest files by hand, rm and patch takes care of it for
    me, rake check_manifest | patch will update a manifest file once I've
    verified it is correct.

    >>> I wrote more about my solution here:
    >>> http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jewele
    >>> ...
    >>> 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', ''
    >>
    >> 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

    >
    > Thanks for sharing. I prefer my gem metadata in an open format i.e.
    > yaml.


    I didn't realize ruby code and plain text files weren't an open format
    and required dependencies to use, unlike yaml which requires a fairly
    hefty dependency.

    What do you do when you add a major feature to your gem? By having
    your description and summary come from your README.txt you only have
    to update one place. With your setup you now have to update two things.

    Also, your summary and description are the same, which is wrong
    (looking at hirb):

    $ ri Gem::Specification
    [...]
    description (RW):
    A long description of this gem
    [...]
    summary (RW):
    A short summary of this gem's description. Displayed in `gem
    list -d`.
    [...]

    > Having to extract them from the readme and/or a Hoe or Jeweler
    > config just adds more work and dependencies.


    Looking at the rakefiles for your various projects, you've duplicated
    your tasks across them. What's going to happen when you want to
    update your tasks, find a better way of writing them or find a new
    tool (like flog or flay)? You're going to have to hand-merge each of
    your existing rakefiles with the new task.

    When you use a library to define your tasks you don't have to worry
    about this, you just install a newer version of the library and you're
    done.

    I've released a large number of gems and I can assure you your path of
    avoiding a library in the name of less work and fewer dependencies
    only leads only to more work and more suffering.
     
    Eric Hodel, Apr 14, 2009
    #13
  14. ghorner

    cldwalker Guest

    On Apr 14, 5:27 pm, Eric Hodel <> wrote:
    > On Apr 13, 2009, at 21:45, cldwalker wrote:
    >
    >
    >
    > > On Apr 13, 5:04 pm, Eric Hodel <> wrote:
    > >> 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/.gems.yml
    > >>> .

    >
    > >> 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.

    >
    > > My gem's build dependency is a config file containing file globs. This
    > > is no more of an extra dependency than a manifest file or a Rakefile
    > > with embedded file globs. Since my gem rebuilding doesn't depend on my
    > > global config file, I'm not sure what two things you're referring to
    > > and why it'd be harder for someone ...

    >
    > With what you've described, if I want to build a gem of yours from  
    > source, first I have to download the source for your project, then I  
    > have to go find your ~/.gems.yml, download it, then merge it into my  
    > ~/.gems.yml (if I was following your scheme) and keep them up to date  
    > when either my gems or your gems change.
    >
    > Having to download from a separate repository is an extra dependency.


    I guess I didn't make it clear enough in my post. The ~/.gems.yml is
    for personal use
    to generate a gemspec. None of my gems depend on it for rebuilding.

    >
    > > Actually, when rebuilding my contributors would have one less
    > > dependency: no gem creator dependency (i.e. no hoe or jeweler
    > > dependency). Just with the rake task mentioned at the end of my post,
    > > they could rebuild my gems.

    >
    > So if I don't need ~/.gems.yml, why do you need or have it?  It seems  
    > to be a useless extra file.


    It serves as a config from which I can generate any of my gem's
    gemspecs. The goal is for centralized gemspec management. If you have
    your own set of rake tasks to do this, I'm all ears.

    >
    > >> 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.

    >
    > > Since I'd be generating my manifest file from a rake task using globs,
    > > I'm not sure how manifest files help.

    >
    > There's no way to verify your glob is correct without manually  
    > checking it every release as it has no history to compare against.
    >
    > Using a glob, eventually you'll forget to release a file, or release  
    > files that shouldn't be there (I've worked on around 50 gems, and  
    > released a few hundred, and this happens with globs).  A manifest file  
    > can ensure you won't have either problem.
    >
    > With a manifest file you can see what has been added or removed easily  
    > using diff.
    >
    > > If you're creating manifest files by hand, then that's a level of  
    > > file-
    > > checking I personally don't want for every file change.

    >
    > I don't edit manifest files by hand, rm and patch takes care of it for  
    > me, rake check_manifest | patch will update a manifest file once I've  
    > verified it is correct.
    >


    Thanks, good to know. I'll look into it for future gem building.

    > >>> I wrote more about my solution here:
    > >>>http://tagaholic.me/2009/04/08/building-dry-gems-with-thor-and-jewele
    > >>> ...
    > >>> 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', ''

    >
    > >>    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

    >
    > > Thanks for sharing. I prefer my gem metadata in an open format i.e.
    > > yaml.

    >
    > I didn't realize ruby code and plain text files weren't an open format  
    > and required dependencies to use, unlike yaml which requires a fairly  
    > hefty dependency.


    I misspoke. I meant a standard format. Hoe, jeweler and any other gem
    creator each have their meta language for gemspecs which makes sharing
    gem building configs impossible. My goal with yaml is to return to
    using original gemspec attribute names. I'm not particularly attached
    to yaml i.e. I could use ruby hashes instead. As for dependencies, I'm
    sure you're aware that yaml comes with stdlib while hoe, jeweler and
    other gem creators do not.

    >
    > What do you do when you add a major feature to your gem?  By having  
    > your description and summary come from your README.txt you only have  
    > to update one place.  With your setup you now have to update two things..
    >
    > Also, your summary and description are the same, which is wrong  
    > (looking at hirb):


    I've seen so many other gems that do this I thought it was standard.
    Unless rubyforge, github and other third party sites are using
    summaries, I'm not sure why this is important.
    >
    > $ ri Gem::Specification
    > [...]
    >       description (RW):
    >            A long description of this gem
    > [...]
    >       summary (RW):
    >            A short summary of this gem's description. Displayed in `gem
    >            list -d`.
    > [...]
    >
    > > Having to extract them from the readme and/or a Hoe or Jeweler
    > > config just adds more work and dependencies.

    >
    > Looking at the rakefiles for your various projects, you've duplicated  
    > your tasks across them.  What's going to happen when you want to  
    > update your tasks, find a better way of writing them or find a new  
    > tool (like flog or flay)?  You're going to have to hand-merge each of  
    > your existing rakefiles with the new task.


    If my rakefiles don't contain any gem-specific config, it won't be
    hard to run a task to copy my latest rakefile across my gems. A side
    note, most of my gems' rakefiles don't have this latest Rakefile setup
    yet.

    >
    > When you use a library to define your tasks you don't have to worry  
    > about this, you just install a newer version of the library and you're  
    > done.
    >
    > I've released a large number of gems and I can assure you your path of  
    > avoiding a library in the name of less work and fewer dependencies  
    > only leads only to more work and more suffering.


    I appreciate the tasks the libraries provide. What I don't appreciate
    is the gem-specific non-standard build configs that gems have. When
    someone else uses my gem I want to let them use their own tasks for
    rebuilding my gem without being forced to rely on my gem creator.
     
    cldwalker, Apr 15, 2009
    #14
  15. ghorner

    Ryan Davis Guest

    On Apr 15, 2009, at 02:50 , cldwalker wrote:

    > If my rakefiles don't contain any gem-specific config, it won't be
    > hard to run a task to copy my latest rakefile across my gems. A side
    > note, most of my gems' rakefiles don't have this latest Rakefile setup
    > yet.


    That's what I thought, and I was wrong. It is exactly the reason why
    hoe was born.
     
    Ryan Davis, Apr 15, 2009
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tomás

    Gems -- #include <gems.hpp>

    Tomás, Mar 4, 2006, in forum: C++
    Replies:
    7
    Views:
    447
    Tomás
    Mar 5, 2006
  2. Lloyd Zusman
    Replies:
    3
    Views:
    203
    Lloyd Zusman
    Jun 21, 2005
  3. Dany Cayouette

    'private' gems/gems hierarchy

    Dany Cayouette, Nov 25, 2005, in forum: Ruby
    Replies:
    3
    Views:
    174
    Jim Weirich
    Nov 25, 2005
  4. Thaddeus L Olczyk

    Problem getting gems/listing gems. EINVAL

    Thaddeus L Olczyk, Aug 15, 2006, in forum: Ruby
    Replies:
    0
    Views:
    203
    Thaddeus L Olczyk
    Aug 15, 2006
  5. Patrick Hurley

    Creating binary gems, from source gems

    Patrick Hurley, Mar 4, 2007, in forum: Ruby
    Replies:
    0
    Views:
    149
    Patrick Hurley
    Mar 4, 2007
Loading...

Share This Page