Re: Core support for Gems, and namespace

On Tue, 27 Jul 2004 11:39:08 +0900, Luke A. Kanies <[e-mail]> wrote:
> I'm getting to the point where my ruby libraries are sophisticated
> enough that I'd like to start packaging them, which means that 1)
> it's important that the packaging be as close as possible to a
> standard, and 2) it needs to be easy for others to install my
> packaged libraries. For instance, I've got some Nagios libraries
> that I would very much like to be easy for people to use.

Here's what I do: I package both as a gem and as a .tar.gz file. I
have taken the installation script written by Dave Thomas for an old
version of RDoc and made significant changes. I have a standard
library format:

  bin/	    # contains binary directories
  lib/	    # contains my actual library
  tests/	# contains my unit tests

I create a gemspec. When I'm ready to release, I do a CVS export
into a version-numbered directory (e.g., diff-lcs-1.0.2). I touch
everything (including the directory) to the date/time that I've
decided the release will be marked as (I use a Windows tool for
this, but it's no different than "find . | xargs touch
[time-format-I-can't-remember]"). I then run "gem build
<gemspec-name>". After the gem has been built, I touch the gem to
the release time/date and then move it to the directory above. I
remove the gemspec from the directory. I create a tar file from the
directory (e.g., diff-lcs-1.0.2.tar), touch that, and then gzip it
and touch that.

I could -- should! -- automate this; I would if I knew of a pure
Ruby tar and gzip library or mechanism. :) There might be one, but I
haven't paid attention. But this is how I do it.

That said, I'm not sold on gems. They're convenient, certainly, but
it is still definitely in flux. The last released version (0.6.1)
screwed up the binary installation for me -- a CVS version near to
0.7.0 fixed it; I can't tell it that I have particular binary
versions available, either, that it can use instead of creating a
binary stub. There is currently no real authentication/verification
mechanism. I personally don't think that the ability to require
particular versions will be used much, if at all -- at least for the
forseeable future. There are some good things about RubyGEMs, but I
think that there are some real questions about overengineering here.

I don't have anything really specific, but there is a part of me
that finds certain parts of RubyGems uncomfortable, and I'm not
really sure what it is. The metadata is nice, and that it's a
packaged format is also nice.

> I'm looking at the Gems stuff, and it seems that all scripts will
> have to clearly differentiate between libraries installed with gem
> vs. those installed by hand. Is it true that I, as a script
> writer, will have to know whether my eventual user installed
> libraries as Gems? Even worse, is it true that all scripts are
> likely to import the gems libraries? Why is not possible to just
> put all gems in a specific directory, and add that directory to
> the library search path? Does anyone know why this feature set was
> chosen?

I'm not sure what you're saying here. The way that RubyGems works is
that it is a library/package management system with versioning.
Thus, I could have Diff::LCS 1.0.1, 1.0.2, and 1.1.0 installed --
and choose to require the appropriate version (e.g., require_gem
'diff-lcs', '>= 1.0.2'). However, recognising that people don't
really want to have to do:

    require 'gems'
    require_gem 'diff-lcs'

The folks behind RubyGems made it so that you can simply do:

    require 'diff/lcs'

This is a stub that does the appropriate 'require "gems"' magic for
you.

> On a related note, one of the things that CPAN spends a
> significant amount of effort on is managing name space, but as far
> as I can tell, there is no such effort in the Ruby community. This
> is definitely related to Gems, as that is really the only place
> you can manage namespace. While I know that filing libraries is
> seldom completely straightforward, I also know that having a
> completely flat namespace will be totally unmanageable in a few
> years, and it's best to solve this problem while it's small.

I think that the namespace issue is something best left for a later
day, to be quite honest. In the two years that I've been using Ruby,
there have been two namespace collisions that I've seen. One is
surrounding Algorithm::Diff; the author of the original library
appears to have dropped off the face of the earth (he never
responded to an email that I sent him) and the author of the second
seems to have just used the same namespace for something that
doesn't work *quite* the same way. There are other diff libraries
out there -- Docdiff (which appears quite good and excessively
complete) and Diff::LCS (my library), neither of which collided.

The other was the subject of a discussion on ruby-talk and
represents a problem with single-level names/namespaces more than
anything else.

> And like I said, even though these are actually meta-problems for
> Ruby, and not part of the language itself, I think that in terms
> of the user community they lie squarely in the heart of the
> language as a tool. When I discuss ruby vs. perl with people,
> everyone wants to know:  Is there CPAN? Is there perldoc? My
> answer is still no, because I can't see how gems can provide the
> seamless simplicity of CPAN. Every perl script I've written for
> the last 3 years or so has embedded documentation and a --help
> command that behaves just like 'man <script> ', but as far as I
> can tell, I still can't get that functionality in ruby.

No, there's no CPAN, but that's being worked on in fits and starts.
There are libraries out there for Perl that aren't in CPAN, and CPAN
has a "competitor" in the form of PPM (it seems to support binary
packages better), so CPAN isn't the be-all and end-all of
everything. Beyond that, perldoc sucks. Ruby's solution, I think,
while still "new", is going to be better overall (ri). The better
place to watch for this stuff is in ruby-talk.

If you want a copy of my install.rb, you can grab it from the
Diff::LCS package or CVS.

-austin
--
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]