RubyGems 0.9.5

Ruby
1

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:

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::Platfor::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 B. for win32 support and testing
  • Luis L. for win32 support and testing
  • Tom C. for help testing and releasing the new indexer
  • Wilson B. 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)

2

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.

3

Eric H. wrote:

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.

4

On Nov 20, 2007 1:35 AM, Eric H. [email protected] wrote:

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

5

Chauk-Mean P. wrote:

Eric H. wrote:

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.

6

Rick Denatale wrote:

On Nov 20, 2007 12:53 AM, Michael G. [email protected] wrote:

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 H.'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.

7

On Nov 20, 2007 12:53 AM, Michael G. [email protected] wrote:

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 H.'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/

8

Chauk-Mean P. wrote:

Chauk-Mean P. wrote:

Eric H. wrote:

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.

9

Michael G. wrote:

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

On Nov 20, 2007, at 4:33 AM, Chauk-Mean P. wrote:

Eric H. wrote:

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 G. II

11

On Nov 20, 2007 10:30 AM, M. Edward (Ed) Borasky [email protected]
wrote:

  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.

  1. Complain and whine to busy people who will blow you off. :slight_smile:

–
Rick DeNatale

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

12

On 11/20/07, Michael G. [email protected] wrote:

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

13

Austin Z. wrote:

On 11/20/07, M. Edward (Ed) Borasky [email protected] wrote:

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

14

On 11/20/07, M. Edward (Ed) Borasky [email protected] wrote:

  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. :slight_smile:
  1. Complain to your distro manager to be more sensible when it comes
    to Ruby. Look closely at what Apple did for good suggestions.

-austin

15

On Nov 20, 2007, at 06:29 , Michael G. wrote:

The problems you’ve experienced, I think, come from trying to mix
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.

16

On 11/20/07, Michael G. [email protected] wrote:

Austin Z. wrote:

  1. Complain to your distro manager to be more sensible when it comes
    to Ruby. Look closely at what Apple did for good suggestions.
    I’m all ears if some one wants to fill me in on what Apple did…

Look to posts by Laurent S. 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 H.
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 H. 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

17

On Nov 19, 2007, at 21:53 , Michael G. wrote:

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.

18

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.

19

On Nov 20, 2007, at 02:33 , Chauk-Mean P. wrote:

Eric H. wrote:

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.

20

On Nov 20, 2007, at 08:18 , Michael G. wrote:

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.