[Rubygems-developers] RubyGems 1.3.0 Upcoming

Chad Woolley thewoolleyman at gmail.com
Sun Aug 17 20:49:09 EDT 2008

On Sun, Aug 17, 2008 at 4:08 PM, Eric Hodel <drbrain at segment7.net> wrote:
> Please test out RubyGems trunk.

All of the GemInstaller integration/regression tests are passing.
Looks good there..

> Current Release notes for 1.3.0:

Um, you mean 1.2.0, right?  That's what rubygems_version.rb says in
trunk, anyway.  Wait, I already have that installed!  Can you _please_
start bumping the version as soon as you release?  In other words,
after this release, bump to 1.4.0 in trunk, and bump to 1.4.1 again
right before release.  Multiple people have asked for this to make
their lives easier when integrating against trunk versions of
rubygems.  It's necessary if you need to put backward-compatibility
version-conditional logic when calling the RubyGems API.  If you
don't, I have to manually edit the version in whenever I integrate or
install from trunk.  It doesn't hurt anything for the public releases
not to end in zero.  It's the right thing to do.  NOT to do so sets a
bad example for other gems.

> * RubyGems now installs into ~/.gem if GEM_HOME is not writable.  Use
> --no-user-install command-line switch to disable this behavior.

This sounds awesome, but there doesn't seem to be an easy way to
change to this approach if you already have rubygems installed as root
(in the standard system location).

If I run setup.rb without sudo, it tries to install over the existing
install and fails However, there is still no easy "uninstall" method
(which has been discussed in a couple of threads over the last couple
of years).

> Use --no-user-install command-line switch to disable this behavior.

Shouldn't these options be exposed on setup.rb as well?  If a system
admin (or installation automation script) wants to force a non-root
user install on a clean system with no ruby gems, you should be able
to say 'ruby setup.rb --user-install'  I'm assuming that just not
running it as sudo would accomplish the same thing, but it seems
strange to only be able to do it implicitly, not explicitly.

Finally, I'm not sure how to test this fully on my local box.  First,
running "rake gem" fails because I don't have
/.gem/gem-private_key.pem.  Even if I had the gem, how would I force
gem update --system --user-install to use a non-released local update
gem, rather than the latest one on rubyforge?

Overall, looks great though.  Good work.
-- Chad

More information about the Rubygems-developers mailing list