[I write this reluctantly, such a déjà vu]
> Regarding (1), some things like proper DATADIR support,
> installation into sitelibdir, transparent operation, compatibility
> with native tools, etc. are hardly doable in RubyGems due to some
> fundamental implementation choices.
Sorry, Mauricio, but I disagree. Nothing about RubyGems *prevents*
any of the above. Nothing.
It makes these things more difficult ("hardly doable", maybe I should
have phrased it as "hard to do"), to the point that we would have to
work around some of RubyGems' limitations, relative to the problem we
are trying to solve. This is one of the reasons why there's no net gain
for us in using RubyGems.
I must say that I do not really understand why so much pressure is put
on us to dump a custom-made tool, crafted to suit our needs, which does
not compete against RubyGems, in favor of the latter. In global terms,
the existence of rpa-base is positive for RubyGems to the extend that
the latter has reused code from the former.
I don't know why the very existence of RPA's technology, which is not
being imposed on anyone, and is there to fit a particular role, must be
constantly justified. There are reasons to have it; the code works for
us and will work better.
The gemspec can be translated into "native" tools, and the RPA-base
layer could be implemented on top of RubyGems as a platform (e.g.,
making the sitelibdir and DATADIR support work)
That would involve bypassing the services provided by the RubyGems
sublayer and operating directly on the destination FS. The primitives
offered by RubyGems are not sufficient. It wouldn't make that much sense
to have the fundamental operations performed by such a rpa-base layer
far exceed those offered by the "platform" the latter is built on.
As for the conversion of the gemspec, note that this requires access
to the pristine sources. The gemification process is not idempotent,
which is quite unfortunate since RubyGems is meant to be the standard
*upstream* format. Besides, RubyGems packages cannot be converted into
satisfactory native packages in general; there's too much variance and
the modifications upstream has to do to make software work with RubyGems
get in the way.
and since Matz seems to have indicated that RubyGems
will become part of the core when it's ready, then it will work
transparently.
Some things (DATADIR, etc) wouldn't work transparently as of today even
if RubyGems were integrated into the std. library.
AFAIK matz's latest take on this is
I'd happy to merge the packaging system (with
which both teams can agree) in the standard Ruby.
That's fine; maybe some of our ideas can help make RubyGems better.
But what gets into the standard library is not really relevant for the
issue being discussed. I think it is not excessive to claim the right
to use the best tool for the goals we have decided to strive for.
Not surprisingly, we think that the best tool can be one designed
specifically to satisfy those needs.
The alternative would be pestering the RubyGems team until RubyGems
does things the way RPA needs them done. I believe that wouldn't be any
better, and I think most people would agree.
I have further indicated in several places how RPA "version-sets"
could be done with RubyGems -- and the latest version of RubyGems
appears to include something that supports this, although it does
require some additional code at the moment.
I had that idea ~ 1 year ago (it was considered while evaluating
RubyGems, before the development of rpa-base began) but rejected it
because several problems would still remain.
> As for (2), it is hard to tell which are exactly RubyGems' goals
> because AFAIK there is no public manifesto comparable to
> http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
Again, this isn't really true. There isn't anything currently
available aside from the project description:
RubyGems is the Ruby standard for publishing and managing third
party libraries.
How is that equivalent to a manifesto? 
> I would really appreciate if Chad, Jim, Gavin, ..., clarified the
> situation. Especially since there have been some talks as of late
> about RubyGems replacing RAA altogether, RubyGems being the only
> repository for Ruby software, etc.
Um. No. RAA isn't going away. That HAS been made very clear.
RubyGems may become the preferred way of packaging projects, with a
RubyGems site and/or RubyForge becoming a preferred location for
distribution -- but not precluding alternative distribution sites.
Austin, I know RubyGems quite well, better than most of its users actually
(better than some of the developers too, there's more code of mine in
RubyGems after all hehe :). *I* know that RAA is not going away.
But I think the RubyGems team could prevent further pointless discussion
in ruby-talk by specifying their goals in something comparable to the RPA
manifesto (which the above one-sentence description is *not*).
The talks about RubyGems replacing RAA, etc, didn't originate in the
RubyGems team but rather in groups of users. So it's up to the RubyGems
team to make sure that people understand what RubyGems is and what it is
not meant to be.
I'm asking them to write a manifesto so we have something to point at
instead of having to write lengthy explanations on ruby-talk every time
somebody starts such a "RubyGems vs RPA" or "Combining RubyGems and RPA"
or "Dump RAA, use Rubyforge, dump RPA, use RubyGems" thread.
···
On Tue, Mar 15, 2005 at 01:15:17PM +0900, Austin Ziegler wrote:
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/