>
>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
do***ented 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 sup****t of rubyforge.net, and the
one-click
installer while rpa got neither so far.
If RPA's format was do***ented 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 sup****ting 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 do***entation. Without that, rubygems should really
not
have been released yet, in my opinion. Much more im****tant to me than any
silly windows gui installer or what not.
* As a package installer, rubygems currently seems like it does not
sup****t
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 do***entation for it, as ri getopt-declare will deal with
nothing.
Anyway, my $0.02 so far.
|
