[ruby-talk:18080] [ANN]: RubyGems (was Re: Rubygarden Poll)

Bill Kelly wrote:
> From: "Euan Mee" <[e-mail]>
> >
> > I've only just joined the list, so didn't vote in the poll.  But as
> > an amateur philologist, I agree with David  (Alan Black, that is)
> >
> > Facet is a counterproductive name for a snippet of Ruby-code.
> >
> > Can I add my  vote post-facto?  :-)
> >
> > The obvious (to me) name for a snippet of Ruby-code would be
> > a 'gem' of Ruby-code.  But then, how many snippets will
> > actually turn out to be gems?  :-)  So snippet it is, I reckon
> 
> Hmm, maybe we can classify the non-gems as shards.  ;-)
> "This web site has 23 gems and 126 shards of Ruby-code."
> 
> (-: Bill

Speaking of the word gem, I suppose I should make a "pre-announcement" of a
Ruby project I'm working on, which I am currently calling RubyGems.  So far
only people in the #ruby-lang IRC channel on OpenNetworks has heard of this
project.

In my mind, a gem is a collection of Ruby code with a specified purpose put
together in a nice, easy to use package.  Now I suppose given this definition,
many of the tarballs on the RAA could be classified as gems.  But when I say
easy to use, I mean really, really easy to use.

Therefore I am working on RubyGems, which has the following goals (among
others):

1. Produce a file format that allows multiple pure-Ruby source files to be
packaged together will additional information embedded, such as a name,
description, author, version, category, etc.

2. Create a system to create, read, and, more importantly, transparently
access code within these gem files.  Therefore Ruby code within a gem file can
be used (i.e. required) without actually extracting the contents of the gem 
file.  True one-step installation.

3. Make the creation of gem files as easy as possible for developers.

4. Allow the sharing of these gem files through a peer-to-peer network (with
appropriate security checking, etc.)

5. Allow for easy management of gems through command-line and other
interfaces.

So far, 1-3 are in good shape, while 4 and 5 are in progress.  These are
really rough, high-level overviews of what I want RubyGems to do.  Maybe a
better explanation would how RubyGems 1.0 will make the use of Ruby easier:

1. See a reference to a Ruby class or source file in an email message,
newsgroup, wiki, etc. and immediately search for, find and download the gem
containing that class and test it or put it to use without even touching a web
browser.

2. Install all the gems related to a particular category with a single command
(i.e you want to do web development so you type 'rg-get --category www'.)

3. Get one gem and have all gems needed by that one installed automatically.

4. Create a new source file with a require statement referring to a file you
don't even have on your system and have the the gem containing that file
automatically downloaded and installed on the first invocation of that source
file.

5. Maintain your own collection of gems in your home directory without root
access.

6. Maintain distinct collections of gems that can be used separately with
ease.

7. Release a new version of a gem to the world with a single command.

8. Easily browse list of gems in multiple interfaces (command-line, web, GUI)
sorted by the criteria of your choice (category, release date, author, etc.)

And more...

So to conclude, this is my personal take on the RAA.succ issue.  One major
caveat: this will only be for PURE RUBY libraries.  I currently don't want to
have to deal with compiling and platform issues related to C code.  I plan to
release a 0.5 beta version of RubyGems within the next month or so.

Oh, and on the note of little pieces of Ruby code, I agree that 'facet' is
bad and personally voted for 'snippet' on the RubyGarden poll :)

-- 

= R y a n 
      L e a v e n g o o d =
[   [e-mail]   ]