[ANN]: RubyGems 0.7.0 Released

ruby-talk
1

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).

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

2

* Jim Weirich <jim@weirichhouse.org> [0737 16:37]:

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 :slight_smile:

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

···

--
Silverman's Law:
  If Murphy's Law can go wrong, it will.
Rasputin :: Jack of All Trades - Master of Nuns

3

Jim Weirich wrote:

  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.

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

4

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.

···

On Sat, 10 Jul 2004 00:36:57 +0900, Jim Weirich <jim@weirichhouse.org> wrote:

* 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.

5

When is RubyGems becoming available as a gem?

6

It's not. It's part of the infrastructure.

Gavin

···

On Saturday, July 10, 2004, 12:37:33 PM, Dave wrote:

When is RubyGems becoming available as a gem?

7

Lyle Johnson wrote:

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.

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

8

I think what Dave B. is asking is if/when a gem installation could
update itself.

gem install gem

Gavin Sinclair wrote:

···

On Saturday, July 10, 2004, 12:37:33 PM, Dave wrote:

> When is RubyGems becoming available as a gem?

It's not. It's part of the infrastructure.

Gavin

9

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

···

il Sat, 10 Jul 2004 12:02:23 +0900, Gavin Sinclair <gsinclair@soyabean.com.au> ha scritto::

On Saturday, July 10, 2004, 12:37:33 PM, Dave wrote:

When is RubyGems becoming available as a gem?

It's not. It's part of the infrastructure.

10

Yes, that is quickly becoming evident. :wink:

···

On Sat, 10 Jul 2004 17:08:59 +0900, Jim Weirich <jim@weirichhouse.org> wrote:

Lyle Johnson wrote:
> 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.

11

gabriele renzi wrote:

When is RubyGems becoming available as a gem?

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?

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.

···

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

12

Jim Weirich wrote:

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

13

Comments below...

Jim Weirich wrote:

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

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

···

On 7/10/04 6:57 AM, "Charles Comstock" <cc1@cec.wustl.edu> wrote:

14

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

15

Fixed...thanks.

···

On 7/10/04 2:29 PM, "Carl Youngblood" <carl.youngblood@gmail.com> wrote:

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