From: cldwalker Date: 2009-04-15T18:50:14+09:00 Subject: Re: how do you manage your gems' gemspecs? 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', 'drbr...@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 > > > 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.