GEMs and RPAs

[Justin Rudd]

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.

So what are the advantages of one over the other?

Links are fine.

--
Justin Rudd
http://seagecko.org/thoughts/



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

 

[Eivind Eklund]

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.

Eivind.

 

[James Edward Gray II]

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.

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

 

[Cameron McBride]

Just as an outside lurker, I wanted to briefly comment:

The RubyGems and RPA authors cooperate, there is some code overlap,
and we hope to increase that overlap with time.

I find the above fact very awesome. Kudos to both groups!
(which I mean as above and beyond providing great package management
software

Cameron

 

[Chad Fowler]

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.

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

http://www.pragmaticprogrammer.com/titles/ruby/

Chad

 

[trans. (T. Onoma)]

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.

I haven't tried RPA yet, does RPA have uninstall command?

T.

 

[David Ross]

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.

I haven't tried RPA yet, does RPA have uninstall command?

T.

dross@dfbsd0:~> rpa
Usage: rpa [options] [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

 

[Mohammad Khan]

What is the latest stable version of RubyGems?


Thanks
Mohammad

 

[David Ross]

What is the latest stable version of RubyGems?


Thanks
Mohammad

http://rubyforge.org/projects/rubygems/

0.8.1

David Ross

 

[Brian Wisti]

I haven't tried RPA yet, does RPA have uninstall command?

T.

dross@dfbsd0:~> rpa
Usage: rpa [options] [command]

[ ... ]

Or, alternately, the answer "yes" is good too ;-)

-- Brian Wisti

 

[David Ross]

trans. (T. Onoma) wrote:

I haven't tried RPA yet, does RPA have uninstall command?

T.

dross@dfbsd0:~> rpa
Usage: rpa [options] [command]

[ ... ]

Or, alternately, the answer "yes" is good too ;-)

-- Brian Wisti

I forgot to add the word yes. I just wanted to show what other commands
rpa has because the fact that T. might ask what else it has in the commands.

"yes"

--dross

David Ross