That's fantastic. Some other suggestions:
Use YAML as the control file instead of native Ruby. I think it would make
automating builds easier. Ruby is okay when you're hand-crafting, but it
makes automated build creation a little dicey. Not terribly, but a little.
Also, it would make it easier for third-parties to display information about
Gems. Right now, Rubyforge doesn't list much information about the Ruby Gems
available, it only lists file names. It could easily extract a YAML file and
print the gem title, description, etc.
I think Gems right now handles a little of the build process, but I have to
tell you from experience, it doesn't handle everything, so my Gems build
process is a hodge-podge of me partially creating the directory structure
with some scripts, and then Gems seems to do some work of its own, adding
directories according to the delete_if call. Perhaps Gems shouldn't do any
building at all; perhaps it should be more like Debian apt where all it does
is bundle what you tell it to using a control file with meta information.
Leaving the build process to the developers seems natural to me, and it would
make your (Gems developers) job easier and more clear. All you would have to
do it install what the control file tells you to. Let the developers create
their directories in the way they want, and generate the control file, Gems
could just bundle it all up and handle the distribution tasks (download,
install, uninstall, etc.).
I hope that made sense. It seems like a lot to ask for, but it should
eliminate a whole lot of code surrounding the gem build process. If what I'm
thinking came out right, it should amount to more control to the developers,
less work for you guys and good meta information for everyone.
Sean O'Dell
···
On Thursday 24 June 2004 10:48, Jim Weirich wrote:
Jim Weirich said:
<nothing!>
I hate it when I hit send by accident!
> Sean O'Dell said:
>> I didn't realize this either. Someone ought to write a definitive
>> tutorial on Gems and maintain it with each release. The examples
>> I found left a lot of things unexplained and it was a painful
>> session of trial-and-error to get my gems working properly, and
>> even then, I didn't know there was a way to bypass the "require_gem"
>> statement.
>>
>> If any more work is done on Gems, I strongly recommend it be on good
>> documentation, and then maintain those docs to update it for the changes
>> made in the future.We are currently reworking the command structure of the gem command. It
grew to be a confusing hodge-podge of options and suboptions. The new gem
command will follow the cvs model (e.g. gem install ...) and the options
will be clearly identified for each gem command. The internals will be
much cleaner as well.At that time we will revisit the documentation and make sure it gets
updated. Documentation is high on our priority list.Thanks for the feedback.