Hi Mauricio (and others too),
I know there are a lot of people who don't want to talk about RPA and
RubyGems, perhaps you included. Matz does seem to feel that there is
some benefit in combining the two, and I happen to agree. On the other
hand, they aren't my projects, and I don't even fully understand them.
Although they are different in a lot of ways, they do share enough that
it seems there is an unnecessary duplication of effort. I think it
would be really helpful if we could clear up some points that still
confuse people about the two projects.
If you'd prefer not to talk about it, please feel free to tell me to
STFU (though nicer language would of course be appreciated). If not,
please read on.
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 the RPA developers:
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
I think that's a great service, and something that was desperately
needed. Before RubyGems there were no common repositories, no common
package formats, no easy tools for installing them, etc. It's really
cool that there are now ways of installing programs via gems, and it
looks like the RubyGems people are really responsive to feature
requests, and are constantly trying to improve their offering. On the
other hand, some of the RPA goals (audited packages, documentation, a
good upstream format, etc.) seem to be things that are not major
concerns to the RubyGems developers.
I believe RPA has all of the above except number 4. As I've said, it
also seems to have a lot more besides. Could RPA also provide that?
I'm all for using the best tool for the job, but somebody had a tool to
hammer nails into wood, and somebody else had a tool to remove nails
from wood. Wouldn't it be amazing if those two tools could be combined
into one uber-tool?
http://www.dot.state.ia.us/natmodel/images/hammer.gif
Ben
P.S. if you've seen this message before, sorry. I sent it out this
morning but it didn't seem to arrive on the list.
I'm very interested in the outcome of that