>That is the primary goal of RPA, but it doesn't exclude packaging more
>libraries; in fact, some 150 libraries/applications have been packaged
>so far, and many are not "production-level".
>Quoting from http://rpa-base.rubyforge.org/wiki/wiki.cgi?Rpa_FAQ :
I see. Thanks for the clear-up. Haven't had a chance to play with RPA.
So which between rubygems and RPA is more popular?
RubyGems is more popular. The RubyGems team have made a great effort to
document and establish it as the Ruby standard for upstream releases.
Is there any indication of which one will be the "official" or
"preferred" packaging system for Ruby in the future?
One doesn't preclude the other. RubyGems' goal is expressed by its
RubyForge description:
"RubyGems is the Ruby standard for publishing and managing third party
libraries."
(AFAIK there is no other mission statement or declaration of purposes)
In other words, RubyGems should become the preferred system for upstream
releases. This is fine because the RubyGems team have often expressed
their commitment to making RubyGems packages easy to repackage, so
hopefully it will improve the current situation; this hasn't happened
yet but RubyGems is still young.
The goals of RPA are expressed in our manifesto:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
The RPA project is larger and more ambitious than RubyGems; it's not
primarily about making other people package using our technology, but
about having the RPA packager team create and maintain the packages.
The analogy would be automake/autoconf vs. FreeBSD.
RPA happens to use its own packaging technology (rpa-base) because
RubyGems' one doesn't satisfy our requirements and there is some gain
in being able to change simultaneously the port/package manager and the
ports/packages. You can find more information about rpa-base and its
features at http://rpa-base.rubyforge.org/ .
Which one will become (or will be the closest to) the Ruby equivalent
of CPAN? By that I mean I can find and install most Ruby libraries
with it.
Currently, there are more libraries/applications packaged in RPA than in
RubyGems' repository. This should change eventually, since mere package
count is not a goal in itself for RPA: the fact that it still has more
packages than RubyGems' repository is a rather anomalous situation.
Note that neither RubyGems nor RPA try to mimic CPAN. In the case of RPA,
the main sources of inspiration are FreeBSD and Debian. However the idea
of having a repository is more central to RPA than to RubyGems: after
all, it's the Ruby Production *Archive*.
Ruby library writers, which one do you prefer or do you find easier to
package your software with?
In general, they should package using RubyGems or Aoki's setup.rb.
RPA packages are created by the RPA crew: the upstream developer needs
not do anything.
So the comparison would be creating the gemspec vs. doing nothing 
If you're interested in RPA or its technology, feel free to join #RPA
at irc.freenode.net. A typical "rpafied install.rb" (most often the only
thing you need to create a RPA port) looks like
require 'rpa/install'
class Install_rcov < RPA::Install::FullInstaller
name "rcov"
version "0.0.2-2"
classification Application.Devel
description <<EOF
RPA's code coverage info and profiling overview generator
rcov allows the developer to identify unused regions of code. It is
especially useful when combined with unit tests, since it will indicate
which areas of the code can't possibly have been tested.
rcov can also gather some basic profiling information (how often a line
of code is run), allowing to locate the hotspots visually.
EOF
end
···
On Fri, Nov 19, 2004 at 08:55:28PM +0900, David Garamond wrote:
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/
Lets hope that more people will start using PostgreSQL instead of mySQL.