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.
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', '(e-mail address removed)'
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.