Hi Mauricio,

I'm not sure I completely understand the analogy comparing RubyGems and 
RPA to rpm vs. FreeBSD.  I understand the basics however.  RPA doesn't 
care too much about the package format, it's more focused on the 
process, and making sure that there are consistent, documented libraries 
that are production-ready (that's what your manifesto says anyhow). 
This is like how the FreeBSD ports system works (or so I understand). 
The packages are audited, repositories are maintained, etc.  RubyGems on 
the other hand *seems* to be an attempt to create a package format, a 
repository and a basic package manager, with new features added as they 
become necessary.  This is like the rpm package format and the rpm 
commandline tool.  On the other hand, there's no attempt made to see if 
a given foo.rpm is any good.

There are certainly areas of overlap -- the package management tool, the 
repository, and the specific packaging requirements.  These are the 
things that an end-user would interact with.  Given that, it's 
completely understandable that people see them as competing projects. 
It just seems like RPA has a lot more depth in what it's trying to achieve.

I think the reason that RubyGems has a bigger "head of steam" is that 
it's easier for people to wrap their heads around it.  All you have to 
do is convert your package to a Gem and get it in the repository.  For 
RPA there seems to be a much higher barrier to entry, and (speaking as a 
developer) I don't exactly understand what I need to do.

I may be wrong, but it seems to me that there's something missing from 
*both* projects: stable vs. unstable.

In RPA it seems like *everything* is stable.  That's good, but it's also 
limiting.  I haven't used FreeBSD but I use Gentoo and Debian, and 
although the "stable" branches of both of those distributions are full 
of qualified, stable packages, they also have an unstable area, where 
the packages are in the appropriate format, but other than that, no real 
checking is done.  I don't know about other people, but if I could only 
use the stable packages, I'd have a lot of trouble.

RubyGems is almost the opposite.  In RubyGems *nothing* is stable, 
because there is no concept of stability.  As DHH mentioned, you can use 
different gem repository URLs to have stable vs. unstable gems, however 
that's not a real solution.  Once a gem is installed, as far as I know 
the system has no way of knowing whether it was tagged as stable or 
unstable.  As far as I know, you can't track the 'stable' and 'unstable' 
gems separately.

The more I understand about RPA, the more useful I think it could be.  I 
regret not understanding it better before.  If the RPA and RubyGems 
efforts were combined, I could see RPA adding features to support 
RubyGems... but at this point I don't see how the opposite would work. 
It seems that because RubyGems was never planned as a system with 
audited packages, guaranteed-good documentation, multiple package 
formats, etc. it would be really hard to modify it to include those things.

It is much easier for me to see RPA being able to deliver packages to 
various distributions as .debs .rpms .tar.gzs, ebuilds and even gems.  I 
think that's a really important feature of a packaging system.

So here's a question for you:

As I understand it, RubyGems is:

1) a package format
2) a repository
3) a package management tool

and essentially

4) a relatively easy way for developers to throw together a possibly 
unstable, but possibly really useful library and put it somewhere where 
people can get to it

RPA has all of the above except number 4, I believe.  Could RPA also 
provide that?

Ben