Re: Core support for Gems, and namespace

On Tue, 27 Jul 2004, Austin Ziegler wrote:

> 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:
[SNIP]

Yeah, see, I exactly don't want to duplicate my work like that.  It's not 
that the process is that onerous, but I'd like there to be a single good 
solution.

> 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 a problem adding features that will make sense when the ruby 
community is more mature; my biggest problem was the idea of being forced 
to specify whether I wanted a gem or not, and the documentation on the 
rubygems page still claims (in all places I could find) that that is 
required.  The docs obviously need to be updated.

> 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 guess I don't really understand why it doesn't just add the gems 
directory to the ruby search path and be done with it.  That seems very 
easy:  It gets total control over a directory, and it just needs to make 
sure its directory is added to ruby's global search path, although I don't 
actually know if (like perl) ruby loads a config.rb file to get its search 
path.

>> 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.

This is the part that concerned me; I can't find any mention of this 
feature on the gems website.  And what's up with the difference in name 
between the gem and the library?  Is that going to be a common problem? 
Very strange.

> 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.

The problem with leaving it until later is that it will take much more 
effort to resolve now.  If we have namespace standards now, then we will 
already have a mechanism for resolving collisions when they do crop up. 
And my concern wasn't just for collisions:  I also don't want to be in a 
situation where 95% of my libraries are installed directly at the 
top-level of the library path.

>> 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.

I'm not saying that CPAN is the end-all and be-all, but everyone can use 
it in most cases, and it really is easy in perl to get the majority of the 
important libraries.  I definitely think that if it were being done again, 
CPAN would be done differently, but it's a great solution for what it is, 
and any attempt to one-up it should be specifically written for the users 
and not for the developers (although there is some concern that 'user' 
here often does mean 'developer').

If people try to install ruby scripts but they have to spend two hours 
hunting down libraries to make them work, then they'll just sit on their 
hands until a perl solution shows up (which isn't likely to happen with 
the stuff I'm working on).  Net::LDAP in perl is a good example -- I use 
that library in almost all of my perl coding, and it requires tons of 
other libraries, but I know that people can just use CPAN to install it 
and all of its prereqs and it'll just work.

As to perldoc sucking, I'm not convinced.  Like I said, every perl script 
I've written for the last 3 years or so has embedded documentation, and 
it's set up to both provide a usage statement and a full man page, 
including one that can be converted to a system man page.  It's a 
standard, and everything -- including CPAN -- supports it.

As to Ruby's "solution", I think you mean "solutions".  I forgot about 
'ri', but that gets added to 'rd' and 'RDoc', and all of them seem to be 
decent at documenting programming interfaces (although they also seem to 
all prefer html) and not good at documenting scripts themselves. 
Apparently 'man' pages are not popular anymore, but I love the fact that 
all of my perl libraries get their docs installed as man pages, and I can 
just say 'perldoc <lib>' and get the equivalent of a man page.

Is one of these three solutions now accepted as the 'standard'?  How do 
they relate?  I now see that RDoc and ri are both part of the same 
sourceforge project, which in some ways just confuses me more...  The 
project page doesn't have any documentation, so that doesn't really help.

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

See, that's the thing:  I don't know what I should do to package my 
libraries in order to make them simpler for other people to use them and 
keep them updated.  Yes, I can provide an install.rb, but that's not much 
better than the configure/make/make install cycle.

-- 
Get forgiveness now -- tomorrow you may no longer feel guilty.
---------------------------------------------------------------------
Luke Kanies | http://abstractive.org | http://reductiveconsulting.com