From: ggarramuno@... (GGarramuno)
Date: 2004-10-29T14:48:59+09:00
Subject: Re: Gems as key? Re: The real Ruby vs. Python.

>
>Then it sounds like that RubyGems needs to adopt the framework of RPA, and 
>help improve/adapt it to its needs, e.g. versionsing.
>
>I like RPA. I want to use RPA. But I can't. I have to say "pretty please" 
>package this for me. I understand the QA. I think that's great. But I also 
>think there needs be a way for beta wares to "get on the line". Gems allows 
>that. So I'll just use Gems.

Amen, brother.  

From trying both, my impression so far (which does not yet include evaluation
of how C modules are handled) is that rpa is clearly superior for my needs.

But, as well intentioned as rpa's team may be, not having a well documented and
clean way to distribute your own packages, I see it never catching on.
Mauricio, that web page explaining things really does not explain anything.  I
could not make head or tails of it.  Having perhaps the rpa "gemspec" available
for the modules of rpa would be a better approach.

The rubygems team seems to have a somewhat "unfair" advantage as they seem to
have better "contacts" among the ruby community as they got the benefit of a
full chapter in the PickAxe and the support of rubyforge.net, and the one-click
installer while rpa got neither so far.

If RPA's format was documented and was as simple to use as a gemspec (or,
better yet, use gemspec itself as it stands, as it is popular enough already),
I really would not bother with rubygems, imo.

Having tried rubygems, I really did not like it much, except for the feature of
being in control of packaging my own stuff.  
But even then, as it stands, I saw a lot of problems with it (if I'm wrong
about any of the things below, please let me know).

Things that, imo, rubygems got wrong so far include:

* Lack of atomic installs.  For a system that is supporting multiple versions
of libraries in different directories, perhaps this is not as dangerous.

* The whole versioning thing of installing in separate subdirectories
   This *seems* like a good idea.  But I consider this one of rubygems biggest
misfeatures. 
  After working at one of python's largest shops in the world for 3 years and
seeing python code written in the span of 5+ years and having dealt with perl
for as many years, I can state with some certaintity that the conflict among
libraries (particularly popular ones) is few and far between.  And in the rare
cases it arises, it is much easier to just change the library path as needed or
not upgrade until the libraries you need work nicely together, without having
to change any code.  If you absolutely need to use a new version of a library,
naming it, say "library2.0" and using it like that is easier (and much simpler
as a symbolic link solves all issues without changing a single line of code).
   As having this feature also encourages libraries to not be mantained or
upgraded, since you can always "use require_gem gem version number to work
around it", I have to say I feel very, very, very strongly against having this.
   Finally, it isn't clear to me if this feature is compatible with having
installs of platform-indepent modules in a single location.  As I usually have
to deal with mantaining scripting languages across multiple platforms, I like
the idea of having a single location where libraries are dumped (usually a unix
box).  With rubygems, my impression is that it seems like libraries for
multiple platforms would need to be installed repeatedly multiple times and in
separate locations.

* rubygems adds the whole require_gem which is silly.  It completely breaks
code written before its appearance and gives sysadmins/coders, at least for
now, the headache of mantaining two systems.  It also can lead to the same
module being installed normally in different versions, meaning require_gem
returns one version while require returns another.  If rubygems becomes
popular, this may not be an issue.  But there's a lot to say about keeping any
new system backwards compatible.

* rubygems lacks ri documentation.  Without that, rubygems should really not
have been released yet, in my opinion.  Much more important to me than any
silly windows gui installer or what not.

* As a package installer, rubygems currently seems like it does not support
installing gems that have nested directory constructs.  Again, this is a huge
problem.  For my Getopt/Declare module, it became just getopt-declare/.  This
difficults maintaining any complex project with it.  It also difficults users'
looking up documentation for it, as ri getopt-declare will deal with nothing.

Anyway, my $0.02 so far.