I'm not sure what I would call myself as far as Ruby
experience goes. I know the language fairly decently,
done some work with Rails, IOWA, and even Arrow.
But one thing that I do not understand is what is the
difference between GEMs and RPAs? Most everything I
get right now is through GEMs. Does RPA have any
advantages? Should I be using both?
GEMs works well for me. It puts a nice stub in
site_ruby and pulls in the latest version
automatically. Does RPA do the same thing? Looking
at the examples, it appears so.
I'll answer basically the same as the last time this question came up:
RubyGems attempts to make it possible for authors to package their
software, giving a standard package environment. You can get more
information on RubyGems from http://rubygems.rubyforge.org/wiki/wiki.pl
RPA attempts to provide production quality packages for Ruby, working
towards quality, availability and maintenance guarantees for at least
the "core" package sets we provide. See http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto for our
manifesto.
The reason that RPA and RubyGems use different technology is that I
see providing a quality library of software with minimal author
interaction as enough of a challenge in itself, and wanted to avoid
the extra risk of having to have a long deployment cycle and
interfering requirements for the packaging software. By controlling
the entire toolchain and package set ourselves, we can optimize their
interaction to make the maintenance task as easy as possible.
The RubyGems and RPA authors cooperate, there is some code overlap,
and we hope to increase that overlap with time.
Eivind.
···
On Fri, 15 Oct 2004 01:47:28 +0900, Justin Rudd <the_pinestraw_man@yahoo.com> wrote:
But one thing that I do not understand is what is the
difference between GEMs and RPAs? Most everything I
get right now is through GEMs. Does RPA have any
advantages? Should I be using both?
Just to add a little to what others will say, I believe Gems have stopped using stubs in the recent versions. That feature defeated one of the strengths of Gems, multiple version management.
I also believe RPA installs things directly into Ruby's lib directory, so it has no need of stubs. RPA modules can be required normally, because of this.
James Edward Gray II
···
On Oct 14, 2004, at 11:47 AM, Justin Rudd wrote:
GEMs works well for me. It puts a nice stub in
site_ruby and pulls in the latest version
automatically. Does RPA do the same thing? Looking
at the examples, it appears so.
Well said, Eivind. The biggest difference is that RubyGems is a
package management system and RPA is an (eventually) QA'd archive of
Ruby libraries. RPA happens to have a package manager, but RPA is
_not_ a package manager in and of itself (nor is that its core focus).
Think of RubyGems as being the package management equivalent of RAA.
It and its repository are free and open to all developers that want to
contribute. There is no rigid QA process in place for this repository
in the same way that there is no QA process in place for the RAA. QA
and package selection will be done in the typical bazaar-mode
evolutionary style.
My hope is that not only will the two share code, but that the
existence of packages for one will eventually serve to make it _dead
simple_ to package for the other.
Also, RPA packages are generally made by the RPA team (Mauricio,
actually), whereas RubyGems are generally made by the actual developer
of a library or application and directly inserted to the repository by
them.
For a good intro to RubyGems usage and packaging, check out the new
Programming Ruby by Dave Thomas. The RubyGems chapter is available on
their website, though if you don't already have a copy of the book,
you need it
Chad
···
On Fri, 15 Oct 2004 02:10:54 +0900, Eivind Eklund <eeklund@gmail.com> wrote:
On Fri, 15 Oct 2004 01:47:28 +0900, Justin Rudd > <the_pinestraw_man@yahoo.com> wrote:
> But one thing that I do not understand is what is the
> difference between GEMs and RPAs? Most everything I
> get right now is through GEMs. Does RPA have any
> advantages? Should I be using both?
I'll answer basically the same as the last time this question came up:
RubyGems attempts to make it possible for authors to package their
software, giving a standard package environment. You can get more
information on RubyGems from http://rubygems.rubyforge.org/wiki/wiki.pl
RPA attempts to provide production quality packages for Ruby, working
towards quality, availability and maintenance guarantees for at least
the "core" package sets we provide. See http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto for our
manifesto.
The reason that RPA and RubyGems use different technology is that I
see providing a quality library of software with minimal author
interaction as enough of a challenge in itself, and wanted to avoid
the extra risk of having to have a long deployment cycle and
interfering requirements for the packaging software. By controlling
the entire toolchain and package set ourselves, we can optimize their
interaction to make the maintenance task as easy as possible.
The RubyGems and RPA authors cooperate, there is some code overlap,
and we hope to increase that overlap with time.
I haven't tried RPA yet, does RPA have uninstall command?
T.
···
On Thursday 14 October 2004 01:21 pm, James Edward Gray II wrote:
Just to add a little to what others will say, I believe Gems have
stopped using stubs in the recent versions. That feature defeated one
of the strengths of Gems, multiple version management.
I also believe RPA installs things directly into Ruby's lib directory,
so it has no need of stubs. RPA modules can be required normally,
because of this.
Just to add a little to what others will say, I believe Gems have
stopped using stubs in the recent versions. That feature defeated one
of the strengths of Gems, multiple version management.
I also believe RPA installs things directly into Ruby's lib directory,
so it has no need of stubs. RPA modules can be required normally,
because of this.
I haven't tried RPA yet, does RPA have uninstall command?
Commands:
install [port|port.rps]... Installs the given ports
remove [port]... Removes the given ports
dist-upgrade Upgrades all ports
build [port]... Builds the given ports
source [port]... Download the specified ports
query>search [port]... Query the repository
list List currently installed ports
info [port]... Gives info on installed ports
update Update repository data
rollback Recover from previous abort
check [port]... Check status of the given ports
clean Purges package and port caches.
help Displays help for commands
General options:
-h, --help Display usage
--[no-]proxy [PROXY] HTTP proxy to use
-q, --quiet Only output errors
-x, --extended Extended port display
--verbose LEVEL Verbosity level (4)
--debug Debug mode
-v, --version Version info
Install options:
-f, --force Force installation despite file conflicts
-p, --parallelize Parallelize operations
--no-tests Don't run unit tests on install
Query/info commands:
-r, --requires PORT[, ...] Port dependency
-c, --classification TYPE[, ...] Port classification
-e, --eval CODE Eval query
-D, --eval-display CODE Eval display
dross@dfbsd0:~>
--dross
···
On Thursday 14 October 2004 01:21 pm, James Edward Gray II wrote:
