[ANN]: RubyGems 0.7.0 Released

J

Jim Weirich

Hello all,

RubyGems 0.7.0 is now available at: http://rubyforge.org/frs/?group_id=126

There has been a lot of work in RubyGems in the past month. Here is
what most users will notice:

* The command structure for the gem command has been reorganized so
that there is stronger distinction between commands and options.
The result is a very CVS-like command structure. For example, to
install a gem you now say:

cvs install GEMNAME

See http://rubygems.rubyforge.org/wiki/wiki.pl?GemReference for more
details.

* The built-in help for the gem command has been extensively updated.
A simple "gem help" will tell you the basics. In particular, the
"gem help examples" command should prove quite useful.

* The gem command now supports a local configuration file ".gemrc".
See http://rubygems.rubyforge.org/wiki/wiki.pl?ConfigurationFile for
details.

* Only the libraries needed to actually implement the require_gem
command are loaded when using 'require "rubygems"'. Any code that
does further manipulation of a gem must execute the Gem.manage_gems
command.

NOTE: This last point is important if you have made your gemspec
files executable to build the gem. You must add
"Gem.manage_gems" to gemspec files. If you use the
recommended "gem build" command to build your gem files, then
you don't have to worry about this.

In addition, the following changes are of interest to anyone writing
RubyGems add-ons:

* The gem library now uses Gem::ConsoleUI to communicate with the
user. This will make it easier for GUI front-ends to use the Gem
library by installing their own UI object.

* Internal error handling has been made more consistent.

A lot of work has been put into bringing the documentation up to date
with the current code base. You will find RubyGems documentation at
http://rubygems.rubyforge.org. Please take some time to review the
docs and feedback is always encouraged.

Thanks,
Jim Weirich
for the RubyGems Development Team

What is RubyGems?
-----------------
RubyGems (http://rubygems.rubyforge.org) is an advanced package
manager for Ruby libraries and applications, similar in many ways to
the Debian apt system and to Perl's CPAN module. It expands on these
systems in that it manages library versions and allows you to maintain
multiple versions of the same library (with automated dependency
resolution).
 
D

Dick Davies

* Jim Weirich said:
Hello all,

RubyGems 0.7.0 is now available at: http://rubyforge.org/frs/?group_id=126

There has been a lot of work in RubyGems in the past month. Here is
what most users will notice:

* The command structure for the gem command has been reorganized so
that there is stronger distinction between commands and options.
The result is a very CVS-like command structure. For example, to
install a gem you now say:

cvs install GEMNAME
^^^
???

Wow, that's VERY cvs like ^_^


Seriously, nice one Jim (and Chad, Gavin et al) - rubygems has really
evolved, and gets better with each release.
 
J

Jim Weirich

Jim said:
The result is a very CVS-like command structure. For example, to
install a gem you now say:

cvs install GEMNAME
^^^
As it has been pointed out, the command example should read ...

gem install GEMNAME

This announcement comes as a great relief to the maintainers of the CVS
software who were worried we actually updated the cvs source tree to
support gems.
 
L

Lyle Johnson

* The command structure for the gem command has been reorganized so
that there is stronger distinction between commands and options.
The result is a very CVS-like command structure. For example, to
install a gem you now say:

cvs install GEMNAME

See http://rubygems.rubyforge.org/wiki/wiki.pl?GemReference for more
details.

Is the command structure backwards-compatible, i.e. will "gem
--install GEMNAME" still work? If it's not that's no big deal; I just
want to be aware of it in case folks are (temporarily) using a mix of
the 0.6.1 release and this one.
 
G

gabriele renzi

il Sat, 10 Jul 2004 12:02:23 +0900, Gavin Sinclair
It's not. It's part of the infrastructure.
what does it mean?
urpmi/apt/emerge/pkgsrc/whatever all allows self upgrading, why would
this be impossible with rubygems?
 
J

Jim Weirich

gabriele said:
what does it mean?
urpmi/apt/emerge/pkgsrc/whatever all allows self upgrading, why would
this be impossible with rubygems?

RubyGems works by manipulating the list of directories searched for
required files. By managing this list, rubygems allows multiple
versions of a library stored on a system (although only one version at a
time can be used in a single ruby program).

In order for gems to be loaded, the software to manage the directory
list and resolve version conflicts must be available and in the standard
non-gem location. This bootstrap code can't be a gem, because it is
used to locate a gem.

It is conceivable that the non-bootstrap code could be made into a gem.
This would be mainly the "gem" command itself. But currently, there
is a fair degree of coupling between the bootstrap and non-bootstrap
portions of the code. Being able to update the "gem" command, but not
its supporting library would be of marginal value at the moment. If
this changes in the future, then anything is possible.
 
J

Jim Weirich

Lyle said:
Is the command structure backwards-compatible, i.e. will "gem
--install GEMNAME" still work? If it's not that's no big deal; I just
want to be aware of it in case folks are (temporarily) using a mix of
the 0.6.1 release and this one.

No, the command structure is not backward compatible.
 
C

Charles Comstock

Jim said:
RubyGems works by manipulating the list of directories searched for
required files. By managing this list, rubygems allows multiple
versions of a library stored on a system (although only one version at a
time can be used in a single ruby program).

In order for gems to be loaded, the software to manage the directory
list and resolve version conflicts must be available and in the standard
non-gem location. This bootstrap code can't be a gem, because it is
used to locate a gem.

It is conceivable that the non-bootstrap code could be made into a gem.
This would be mainly the "gem" command itself. But currently, there is
a fair degree of coupling between the bootstrap and non-bootstrap
portions of the code. Being able to update the "gem" command, but not
its supporting library would be of marginal value at the moment. If
this changes in the future, then anything is possible.

That's really unfortunate. I guess I don't follow why you can't have 2
or 3 basic pointer files that load in either gem, or the library and
still point into your gem repository. I really think the format
framework must be limited if it's not easy to boostrap itself. I
consider it a very important feature for rubygems to take off well.
Maybe it's dreaming but it would be awesome if you could get it so good
that it could update the source version of ruby as well, assuming of
course a reasonably useful version was already installed. I like the
concept of the gem, but it definitely seems like it would prove it's
worth as a package manager if it was capable of installing itself. That
gives the impression it could install anything if necessary, and that to
me means the framework is a success. When you could bridge off and use
it as a package manager for the associated binaries a library links
against, or you could trampoline ontop of it to act as the library
updating agent for a distributed processing system. If a framework
powerful enough then it makes itself a potential dependency for other
projects, then that is what makes it part of the standard install and a
proven useful product. Besides of course, how much it simplifies
administration if it boostraps itself.

Charles Comstock
 
R

Richard Kilmer

Comments below...

That's really unfortunate. I guess I don't follow why you can't have 2
or 3 basic pointer files that load in either gem, or the library and
still point into your gem repository. I really think the format
framework must be limited if it's not easy to boostrap itself. I

Its not a formatting issue. We could build into RubyGems the code to update
itself. Its possible. Having said that, we would like it to move into the
ruby core if/when it make sense to do so. If it did move into the core,
then it would not necessarily make sense to update just itself...and to use
it to fully update the ruby installation I think is beyond the scope of what
we created RubyGems for. It is not a generalized package manager like RPM,
its for managing Ruby libraries (assuming Ruby exists in the first place).
Matz version manages Ruby right now, and Gems would fall into that same
version/management policy.
consider it a very important feature for rubygems to take off well.

We do to, and the measure of that is not self-update, its the community
building a large repository of gems (apps/libraries) to install and keep
updated over time...and that it (hopefully) will be brought into the core if
its successfully adopted by the community.
<SNIP>
Charles Comstock

-rich
 
C

Carl Youngblood

By the way, I noticed that on rubyforge the 0.7.0 announcement still
says "cvs install GEMNAME".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top