[ANN] RubyGems 0.9.5

[Eric Hodel]

RubyGems 0.9.5 adds several new features and fixes several bugs.

To upgrade to the latest RubyGems:

gem update --system

To upgrade to the latest RubyGems by hand:

* Download RubyGems from http://rubyforge.org/frs/?
group_id=126&release_id=16500
* `gem install rubygems-update-0.9.5.gem`
* `update_rubygems`

To install RubyGems from scratch:

* Download RubyGems source .tgz or .zip file from
http://rubyforge.org/frs/?group_id=126&release_id=16500
* Unpack the source .tgz or .zip
* `ruby setup.rb`

To install RubyGems on Ruby 1.9 update your ruby trunk checkout and
reinstall.

To file bugs:

http://rubyforge.org/tracker/?func=add&group_id=126&atid=575

When filing a bug, `gem env` output will be helpful in diagnosing the
issue.

If you find a bug where RubyGems crashes, please provide debug
output. You can do that with `gem --debug the_command`. For example:

$ gem --debug unknown_command
Exception `RuntimeError' at [...]/rubygems/command_manager.rb:114
- Unknown command unknown_command
ERROR: While executing gem ... (RuntimeError)
Unknown command unknown_command
[...]/rubygems/command_manager.rb:114:in `find_command'
[...]/rubygems/command_manager.rb:103:in `process_args'
[...]/rubygems/command_manager.rb:74:in `run'
[...]/rubygems/gem_runner.rb:39:in `run'
/usr/local/bin/gem:22

=== Changes

Select new features include:

* Automatic installation of platform gems
* New bandwidth and memory friendlier index file format
* "Offline" mode (--no-update-sources)
* Bulk update threshold can be specified (-B, --bulk-threshold)
* New `gem fetch` command
* `gem` now has "really verbose" output when you specify -v
* Ruby 1.9 compatible

Other changes include:

* Time::today is deprecated and will be removed at a future date
* `gem install --include-dependencies` (-y) is now deprecated since
it is the
default, use --ignore-dependencies to turn off automatic dependency
installation
* `gem.bat` and bin stubs on mswin platforms are improved and
compatible with
the One-Click Installer
* Multi-version diamond dependencies only are installed once
* Bulk index updates take less memory
* -V now enables verbose instead of -v to avoid collision with --
version's -v
* `gem install -i` makes sure all depenencies are installed
* `gem update --system` reinstalls into the prefix it was originally
installe in
* `gem update --system` respects --no-rdoc and --no-ri flags
* HTTP basic authentication support for proxies
* Gem::Specification#platforms should no longer be a String, use
Gem:latfor::CURRENT when building binary gems instead
* `gem env` has more diagnostic information
* require 'rubygems' loads less code
* sources.gem is gone, RubyGems now uses built-in defaults
* `gem install --source` will no longer add --source by default, use
`gem souces --add` to make it a permanent extra source
* `gem query` (list) no longer prints details by default
* Exact gem names are matched in various places
* mkrf extensions are now supported
* A gem can depend on a specific RubyGems version
* `gem_server` is now `gem server`
* `gemlock` is now `gem lock`
* `gem_mirror` is now `gem mirror`
* `gemwhich` is now `gem which`
* `gemri` is no longer included with RubyGems
* `index_gem_repository.rb` is now `gem generate_index`
* `gem` performs more validation of parameters
* Removed gem* commands are now replaced with stubs that warn
* Custom rdoc styles are now supported
* Gem indexer no longer removes quick index during index creation
* Kernel#require only rescues a LoadError for the file being required
now
* `gem dependencies` can now display some information for remote gems

=== Special Thanks

* Daniel Berger for win32 support and testing
* Luis Lavena for win32 support and testing
* Tom Copeland for help testing and releasing the new indexer
* Wilson Bilkovich for the new Marshal index format
* To the rest of the RubyGems bug reporters and patch contributors

The full set of changes including contributors is included in the
ChangeLog.

=== Platforms

RubyGems now automatically handles platform gems. This means that
`gem install` will no longer prompt for gem selection. RubyGems uses
Ruby's built-in configuration to match the running ruby's platform to
choose the correct gem to install. The automatically chosen platform
may be overridden with the --platform option.

The dependency, fetch, install, outdated, specification, uninstall
and update commands all respond to --platform.

For more information, see `gem help platforms`

=== Thanks

Keep those gems coming!

-- Jim & Chad & Eric (for the RubyGems team)

 

[Michael Greenly]

I got caught by some "tired at the end of the day" stupidity...

I was using the Ubuntu (apt-get installed) package of RubyGems. Go
figure if you do a 'gem update --system' in this situation it makes a
mess of things.

I choose to try gems out this way because every time I've installed Gems
from source to some prefix other than /usr/lib it's managed to find
some way to not work or be otherwise inconvenient.

RubyGems has really become the one thing about Ruby I dislike.

 

[Chauk-Mean P.]

RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

Cheers.

Chauk-Mean.

 

[Laurent Sansonetti]

RubyGems 0.9.5 adds several new features and fixes several bugs.
[...]

Just a quick note to mention that Mac OS X 10.5 is now fully supported
by this release. Updating to it should not break Leopard's Ruby
configuration.

Laurent

 

[Chauk-Mean P.]

RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

I forgot to mention that I only use local installation of gems that I
already have downloaded (offline installation).

I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
this works :
gem install -l ruby-debug-ide

It's a bit strange as I have been able to install ruby-debug-base
(ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).

Cheers.

Chauk-Mean.

 

[Rick DeNatale]

I got caught by some "tired at the end of the day" stupidity...

I was using the Ubuntu (apt-get installed) package of RubyGems. Go
figure if you do a 'gem update --system' in this situation it makes a
mess of things.

I choose to try gems out this way because every time I've installed Gems
from source to some prefix other than /usr/lib it's managed to find
some way to not work or be otherwise inconvenient.

RubyGems has really become the one thing about Ruby I dislike.

My way of looking a this is the brain-dead packaging of Ruby on debian
is the one thing about Ubuntu (and Debian based distros) that *I*
dislike.

The problems you've experienced, I think, come from trying to mix
debian packaged ruby with source installed gems.

When I first started using Ruby on Ubuntu I ran into problems like
this. At Andy Hunt's suggestion I installed both Ruby and rubygems
from source and haven't looked back.

 

[Michael Greenly]

My way of looking a this is the brain-dead packaging of Ruby on debian
is the one thing about Ubuntu (and Debian based distros) that *I*
dislike.

The problems you've experienced, I think, come from trying to mix
debian packaged ruby with source installed gems.

When I first started using Ruby on Ubuntu I ran into problems like
this. At Andy Hunt's suggestion I installed both Ruby and rubygems
from source and haven't looked back.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

The system package currently in Ubuntu for RubyGems just about gets it
right. They most likely should of disabled the 'system' update feature
so that it wasn't possible to do what I did.

On the other hand if the upstream RubyGems would actually allow for the
concept that it may live in /usr/lib but not be allowed to manipulate
anything there it would make life a lot easier.

Now that (according to the release notes) it correctly updates when
installed to different prefixes I guess I'll try source a source install
to /usr/local again.

 

[James Edward Gray II]

RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

I just ran into a new RubyGems 0.9.5 issue this morning as well:

$ sudo gem install rmagick
Password:
Bulk updating Gem source index for: http://gems.rubyforge.org
Building native extensions. This could take a while...
Successfully installed rmagick-1.15.10
1 gem installed
Firefly:~/Documents/weddingbook james$ ruby -rubygems -e 'require
"RMagick"'
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- RMagick.so (LoadError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:27:in `require'
from /usr/local/lib/ruby/site_ruby/1.8/RMagick.rb:11
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:
27:in `gem_original_require'
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/
custom_require.rb:27:in `require'
from -e:1

I'll go file a bug.

James Edward Gray II

 

[Chauk-Mean P.]

RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
this works :
gem install -l ruby-debug-ide

It's a bit strange as I have been able to install ruby-debug-base
(ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).

I think that I have understood what's happening :
- rubygems 0.9.5 includes dependencies during installation by default
now
- when I first install ruby-debug-base locally (without -l), it works as
this gem has no dependency on other gems
- then when I tried to install ruby-debug-ide locally (again without
-l), it fails as it seems that rubygems tries to install the required
dependency (ruby-debug-base) remotely and not locally.

Forcing the local installation with -l solves my problem.

This raises two issues :
1- rubygems seems to not take care of gems that are already installed
(during the dependency checking)
2- rubygems should try to install dependency gems locally before
remotely.

Cheers.

Chauk-Mean.

 

[M. Edward (Ed) Borasky]

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

Let me emphasize what you just said. /usr/lib belongs to the package
manager on all distros! There's a *reason* the Ruby source and most
other upstream sources install to ("--prefix" in "configure")
*/usr/local* rather than */usr* by default. So ... your options are

1. Work with the packages as supplied by your distro.
2. *Don't* install the packages supplied by your distro -- use upstream
source and put things in /usr/local.
3. Complain and whine to busy people who will blow you off.

 

[Austin Ziegler]

I got caught by some "tired at the end of the day" stupidity...

I was using the Ubuntu (apt-get installed) package of RubyGems. Go
figure if you do a 'gem update --system' in this situation it makes a
mess of things.

That doesn't surprise me. I don't use the Ubuntu or Debian versions of
Ruby; they're too broken by nonsensical policies to use.

I choose to try gems out this way because every time I've installed Gems
from source to some prefix other than /usr/lib it's managed to find
some way to not work or be otherwise inconvenient.

It's not /usr/lib. I have RubyGems installed in /usr/local/lib,
because I have *Ruby* in /usr/local. If you're not going to put
RubyGems in the same place as Ruby, you're going to have to go to a
little extra effort.

RubyGems has really become the one thing about Ruby I dislike.

It's probably because you're not using it the easy way.

-austin

 

[Rick DeNatale]

Let me emphasize what you just said. /usr/lib belongs to the package
manager on all distros! There's a *reason* the Ruby source and most
other upstream sources install to ("--prefix" in "configure")
*/usr/local* rather than */usr* by default. So ... your options are

1. Work with the packages as supplied by your distro.
2. *Don't* install the packages supplied by your distro -- use upstream
source and put things in /usr/local.

Which is what I did on ubuntu, I just wasn't explicit about where I
installed in my post.

3. Complain and whine to busy people who will blow you off.

<G>

 

[Austin Ziegler]

Let me emphasize what you just said. /usr/lib belongs to the package
manager on all distros! There's a *reason* the Ruby source and most
other upstream sources install to ("--prefix" in "configure")
*/usr/local* rather than */usr* by default. So ... your options are

1. Work with the packages as supplied by your distro.
2. *Don't* install the packages supplied by your distro -- use upstream
source and put things in /usr/local.
3. Complain and whine to busy people who will blow you off.

4. Complain to your distro manager to be more sensible when it comes
to Ruby. Look closely at what Apple did for good suggestions.

-austin

 

[Michael Greenly]

4. Complain to your distro manager to be more sensible when it comes
to Ruby. Look closely at what Apple did for good suggestions.

-austin

I'm all ears if some one wants to fill me in on what Apple did...

but...

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a dozen
options to work around this. It's that it will never 'just' work until
RubyGems allows for these types of distribution requirements and there's
absolutely no reason it can't.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib and it moved it's
gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Now I realize the paticular oddities of this are not necessarily
RubyGems problems. I was using the Ubuntu patched version, but I've
looked at that patch and all it did was hardcode the GEM_HOME
environment variable to be /var/lib/rubygems. Why would id decide to
install into /usr/local?

RubyGems has become a core part of Ruby. It needs to just work! As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.

 

[Eric Hodel]

I got caught by some "tired at the end of the day" stupidity...

I was using the Ubuntu (apt-get installed) package of RubyGems. Go
figure if you do a 'gem update --system' in this situation it makes a
mess of things.

I choose to try gems out this way because every time I've installed
Gems
from source to some prefix other than /usr/lib it's managed to find
some way to not work or be otherwise inconvenient.

RubyGems has really become the one thing about Ruby I dislike.

Rather than using features provided by RubyGems (GEM_PATH), Debian
(and I guess also Ubuntu since it also uses apt) instead chose to
hack RubyGems.

If this causes breakage, I'm sorry, but it is impossible for the
RubyGems team to support a hacked RubyGems.

 

[Austin Ziegler]

I'm all ears if some one wants to fill me in on what Apple did...

Look to posts by Laurent Sansonetti on this list or the rubygems developer list.

but...

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a dozen
options to work around this. It's that it will never 'just' work until
RubyGems allows for these types of distribution requirements and there's
absolutely no reason it can't.

There's also absolutely no reason it should. There are plenty of
options if you're having to update a system location, as Eric Hodel
has pointed out in the past.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib and it moved it's
gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Right. But you installed an *upstream* package (gem update --system)
over a *downstream* package. RubyGems is absolutely *correct* to
assume that I want RubyGems itself to be in the same location as Ruby.
If I want something different (which, frankly, *I* don't) then I have
options available through environment variables. Again, see recent
posts by Eric Hodel for sanctioned options, or Laurent's summary of
Leopard changes to see how you're advised to upgrade RubyGems on
Leopard. It's not "gem update --system", but it's not significantly
harder (I think it's SOME_ENV_VAR=other-location gem update --system).

RubyGems has become a core part of Ruby. It needs to just work!

Fact: it does.

As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.

I don't know why you can't. I'd have no problem using Ruby and
RubyGems on a production server at all.

I'd just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
The upstream maintainers at Debian Don't Get Ruby. While the situation
is better than it has been, it's still a freaking nightmare.)

-austin

 

[Eric Hodel]

Hardly... in all package managed systems /usr/lib belongs to the
package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

Maybe for Linux distributions. RubyGems works on more than just Linux.

On the other hand if the upstream RubyGems would actually allow for
the
concept that it may live in /usr/lib but not be allowed to manipulate
anything there it would make life a lot easier.

RubyGems allows this via the GEM_PATH and GEM_HOME environment
variables.

It is not the fault of RubyGems if Debian, instead of using the
provided features, partially disables them with hard-coded paths to
get what they want.

 

[Michael Greenly]

I'd just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
The upstream maintainers at Debian Don't Get Ruby. While the situation
is better than it has been, it's still a freaking nightmare.)

-austin

That actually made me laugh. Debian doesn't get package managment?
It's really quite the opposite. RubyGems started with a very poor
understanding of living in a package managed world.

In theory it currently has the necessary tools. If --prefix installs
and $GEM_HOME were properly respected there wouldn't be a problem, but
there not!

If they were my stupid 'update --system' mistake wouldn't have moved
ruby gems library from /usr to /usr/local and the gem_home from
/var/lib/rubygems to /usr/lib/ruby/gems.

RubyGems needs to work correctly no matter where Ruby is installed. It
needs to never modify files outside of --prefix (or installed defined
directories) and it needs to consistently respect $GEM_HOME.

 

[Eric Hodel]

I'm all ears if some one wants to fill me in on what Apple did...

Apple wanted to integrate RubyGems with Leopard in a manner that was
as invasive as Debian's, but instead of demanding changes, provided
patches with tests.

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a
dozen options to work around this. It's that it will never 'just'
work until RubyGems allows for these types of distribution
requirements and there's absolutely no reason it can't.

RubyGems allows for this and has for a long time. GEM_PATH and
GEM_HOME are not new. Even lower-level than that, you can override
values in Config::CONFIG from Ruby to match what you desire and not
need to set GEM_HOME at all.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib

My understanding of the FHS says that you are not allowed to install
software into /usr/lib, only Debian is allowed to do that. So a hand-
installed (even gem update --system) RubyGems must be installed in /
usr/local.

and it moved it's gem cache from /var/lib/rubygems to /usr/lib/
ruby/gems. Why?

Because Debian added a hard-coded hack RubyGems to use /var/lib
instead of using GEM_PATH and GEM_HOME. I don't know why RubyGems is
using /usr/lib/ruby/gems instead of /usr/local/lib/ruby/gems, but I
suspect that Ruby's Config::CONFIG has been partially modified.

Now I realize the paticular oddities of this are not necessarily
RubyGems problems. I was using the Ubuntu patched version, but I've
looked at that patch and all it did was hardcode the GEM_HOME
environment variable to be /var/lib/rubygems.

Yes, it is regrettable that Debian didn't instead add GEM_HOME to /
etc/profile (or equivalent). In that case (other than the /usr/lib
vs /usr/local/lib problem) upgrading RubyGems would Just Work.

Why would id decide to install into /usr/local?

My understanding of FHS says that RubyGems must be installed in /usr/
local if you install it by hand.

RubyGems has become a core part of Ruby. It needs to just work!
As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders
that
don't belong to it.

Set GEM_HOME correctly, and RubyGems will only touch that directory
on install or uninstall.

 

[Eric Hodel]

RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

Thanks.