Bill Kelly wrote: > From: "Euan Mee" <lucid / users.sourceforge.net> > > > > 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 = [ mrcode / adelphia.net ]