On Apr 13, 2009, at 21:45, cldwalker wrote:
gemspecs from one config file:dotfiles/.gems.yml at master · cldwalker/dotfiles · GitHub
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.
p.developer ‘Eric H.’, ‘[email protected]’
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.