Segment7: RubyGems 1.0.0

RubyGems 1.0.0

drbrain@segment7.net (Eric Hodel) — Thu, 20 Dec 2007 00:32:58 -0800

Release 1.0.0 fixes several bugs.

NOTE: There is a bug installing on Ruby 1.8.5 and earlier. I will fix this tomorrow.

Major New Features Include:

RubyGems warns about various problems with gemspecs during gem building
More-consistent versioning for the RubyGems software

Other Changes Include:

Fixed various bugs and problems with installing gems on Windows
Fixed using gem server for installing gems
Various operations are even more verbose with—verbose
Built gems are now backwards compatible with 0.9.4
Improved detection of RUBYOPT loading rubygems
ruby setup.rb now has a—help option
Gem::Specification#bindir is now respected on installation
Executable stubs can now be installed to match ruby’s name, so if ruby is installed as ‘ruby18’, foo_exec will be installed as ‘foo_exec18’
gem unpack can now unpack into a specific directory with—target
OpenSSL is no longer required by default

Deprecations and Deletions:

Kernel#require_gem has been removed
Executables without a shebang will not be wrapped in a future version, this may cause such executables to fail to operate on installation
Gem::Platform constants other than RUBY and CURRENT have been removed
Gem::RemoteInstaller was removed
Gem::Specification#test_suite_file and #test_suite_file= are deprecated in favor of #test_file and #test_file=
Gem::Specification#autorequire= has been deprecated
Time::today will be removed in a future version

How can I get RubyGems?

NOTE: If you have installed RubyGems using a package you may want to install a new RubyGems through the same packaging system.

If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is:

gem update --system   (you might need to be admin/root)

(Note: You may have to run the command twice if you have any previosly installed rubygems-update gems).

If you have an older version of RubyGems installed, then you can still do it in two steps:

gem install rubygems-update  (again, might need to be admin/root)
update_rubygems              (... here too)

If you don’t have any gems install, there is still the pre-gem approach to getting software … doing it manually:

DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126
UNPACK INTO A DIRECTORY AND CD THERE
INSTALL WITH: ruby setup.rb (you may need admin/root privilege)

Thanks

Keep those gems coming!

"RubyGems 1.0.0" by Eric Hodel

Sat, 29 Dec 2007 00:30:21 -0800

@DGM: Kernel#require_gem has been deprecated for 17 or 18 months now, which is certainly plenty of time. It’s not my fault if authors fail to heed the warnings given them.

There would still be complainers if I removed it six or even 12 months from now.

It’s not a “major pain” to switch away from Kernel#require_gem. Deleting the line and replacing it with regular Kernel#require of the appropriate file or files is all it takes.

If you want to continue to use Kernel#require_gem, use RubyGems 0.9.5, which is hardly different, or RubyGems 0.9.4.

"RubyGems 1.0.0" by DGM

Fri, 28 Dec 2007 09:02:56 -0800

@Eric: “Kernel#require_gem was never aliased to Kernel#gem. The two methods did different things. Kernel#require_gem has been complaining about deprecation for 11 months. There’s been plenty of time for authors to fix their code.”

Ahem. That is, only if you have been doing any development for the last year. I just came back to work on a project that was completed a year ago – and now it won’t run. This is going to be a major pain just to get everything updated to work again, much less add the features I was hired to do. :/

11 months is not really “plenty of time”.

"RubyGems 1.0.0" by Mark Wilden

Mon, 24 Dec 2007 10:28:19 -0800

Thanks, Eric. I noticed other folks talking about issues, so I thought I’d sneak mine in.

My ruby has been in Program Files for a few months, without problem. In the process of updating to 2.0.2, however, I ran across other problems with the space in the folder name, so I bit the bullet and went back to c:\ruby.

It’s too bad. I’ve been using “advanced” file names for 12 years. Currently, ruby (or parts thereof) is the only software I have that can’t handle them.

///ark

"RubyGems 1.0.0" by Eric Hodel

Sun, 23 Dec 2007 17:46:11 -0800

Mark: The proper place to file bugs or patches is on the tracker, but you won’t get very far fixing this one. Many gems don’t like paths with spaces on Windows.

Don’t let that discourage you though, I’d welcome such a patch.

"RubyGems 1.0.0" by Mark Wilden

Sat, 22 Dec 2007 20:15:44 -0800

Yes, I know what the problem is, raggi – I was just wondering if/when it was going to get fixed. Of course, I plan to look at it myself when I get a chance – it’s gotta be an easy fix.

///ark

"RubyGems 1.0.0" by raggi

Sat, 22 Dec 2007 18:23:01 -0800

Mark Wilden – That’s a command being spawned in a subshell, that hasn’t been escaped properly. On windows, all commands with paths or names containing spaces, require escaping by surrounding them with quotation marks. Double quotes at that. Neither backslash, nor single quotes will work reliably.

In my experience, there are a lot of libraries which do not do this properly, as such I really can’t recommend running ruby in a directory that contains spaces, at least for the time being.

Makefiles and subshell called commands become even more of a nightmare in this regard, as can installing on a different drive (due to the often poor choice of handling of ’/’ in the MSVCRT and other libs (or the incorrect perception that this is an absolute path)).

For the record, it is also worth noting that when executing binaries in this manner, an unescaped command will actually search each of the possibilities, and if one is found, it will then pass the remaining portion of the command as arguments to the command. This was previously abused by malware in order to intercept poorly written command line calls. (I only point this out, as essentially, not dealing with command line calls properly, is in fact a security issue on Windows).

"RubyGems 1.0.0" by Mark Wilden

Sat, 22 Dec 2007 14:20:40 -0800

Nothing about the problem I mentioned?

///ark

"RubyGems 1.0.0" by Eric Hodel

Fri, 21 Dec 2007 13:29:32 -0800

Just require the file you need. You only need to use Kernel#gem when you need a specific version of a gem.

"RubyGems 1.0.0" by Kris Nuttycombe

Fri, 21 Dec 2007 10:46:26 -0800

Kernel#require_gem was never aliased to Kernel#gem. The two methods did different things. Kernel#require_gem has been complaining about deprecation for 11 months. There’s been plenty of time for authors to fix their code.

The problem with this is that there are lots of Rails plugins and such that are older than 11 months that are unmaintained but still in use. From experience, just changing “require_gem” to “gem” in these often results in them not working at all. Can you suggest a migration path?

"RubyGems 1.0.0" by Mark Wilden

Thu, 20 Dec 2007 18:56:01 -0800

gem update—system seems to be working, but then errors with

'c:/Program' is not recognized as an internal or external command

I’m on Windows and yes, my ruby folder is under \Program Files.

> NOTE: If you have installed RubyGems using a package > you may want to install a new RubyGems through the > same packaging system.

I never know what to do when I see a message like this. :) The message doesn’t give me any information that would help me choose one way or another.

///ark

"RubyGems 1.0.0" by Eric Hodel

Thu, 20 Dec 2007 18:29:42 -0800

@Eric Beland: The release announcement above, before all of the installation/update instructions, has the following:

NOTE: If you have installed RubyGems using a package you may want to install a new RubyGems through the same packaging system.

@gmarik: Kernel#require_gem was never aliased to Kernel#gem. The two methods did different things. Kernel#require_gem has been complaining about deprecation for 11 months. There’s been plenty of time for authors to fix their code.

@mike: See the note at the top of this post.

"RubyGems 1.0.0" by Eric Beland

Thu, 20 Dec 2007 17:33:55 -0800

Hi Luis,

I did the update via gem update—system initially not knowing this would cause problems. For people starting with a packaged image, it’s not always clear how the image was “made.” Also, I was unaware of this mysterious limitation which was apparently addressed in an irc chat room somewhere. I hope the Vogon construction plans for a space-bypass through planet earth are not also on Display in ruby-talk (Hitchhiker’s Guide reference). It was only after trying to update via rubygems that I got the error and then tried other install/uninstall methods (apt-get) in an effort to repair things. It’s strange to not be able to upgrade via gem update—system when it seems the only thing needed to make it work was to change one file. Anyhow, I will avoid “mixing methods” (and mixing liquor and beer) in the future. If it could be detected whether the version is from a package, a warning would have been nice rather than blaming the victim.

Eric

"RubyGems 1.0.0" by mike

Thu, 20 Dec 2007 17:25:14 -0800

When update on a win32 ruby 1.8.4, the update_rubygems fires the following exception.

Installing RubyGems 1.0.0 ./lib/rubygems.rb:77: uninitialized constant Gem::RbConfig (NameError) from setup.rb:19

Due to some file corrupt on rubyforge?

"RubyGems 1.0.0" by Warren

Thu, 20 Dec 2007 13:50:51 -0800

Luis,

Thanks for the confirmation, that’s Excellent! I must have done something wrong this morning when I upgraded to 1.0.0, as my mongrel server wouldn’t fire up… I’ll clear out the gems and reinstall them…

"RubyGems 1.0.0" by Luis Lavena

Thu, 20 Dec 2007 11:23:32 -0800

Eric Beland: you mixed installation meachinism. Then you broke it.

apt-get is a packaging method of Debian, gem update will try to update itself, which end breaking your ‘apt’ environment.

This was longly discussed in ruby-talk. If you installed rubygems using apt-get, stick to it and wait for debian guys package the new version.

Any other case, apt-get remove and manually install it using ruby setup.rb install

I cannot help you more than that, sorry.

"RubyGems 1.0.0" by Eric Beland

Thu, 20 Dec 2007 11:14:53 -0800

On my Debian box I upgraded rubygems… Suddenly gem -v wouldn’t work and threw uninitialized constant Gem::GemRunner.

Thinking the install may have been half-baked, I uninstalled, reinstalled, using apt-get. Kept getting v1.0 of RubyGems and the same error. Gave up and used nano to toss the line below into /usr/bin/gem

require ‘rubygems/gem_runner’

Haven’t seen anyone else complaining about this so far. Works for me now… Thoughts?

"RubyGems 1.0.0" by Luis Lavena

Thu, 20 Dec 2007 10:41:12 -0800

@Per: Yes, you will no longer request to install mswin32 gems on any other platform that is not mswin32 (unless you force it).

@Warren: Yes, Eric solved the issues with gems that uses mswin32 as platform (mongrel, hpricot, sqlite3-ruby, and many others).

So 1.0.0 is the best RubyGems you can upgrade to! :-)

HTH,

Luis

"RubyGems 1.0.0" by gmarik

Thu, 20 Dec 2007 09:44:17 -0800

2Jason: Yes, I’d like to have it everywhere, all the time for now…

"RubyGems 1.0.0" by Warren

Thu, 20 Dec 2007 09:04:50 -0800

Great work, Eric!

Does this release address the problems that 0.9.5 had with running mongrel on win32?

Thanks!

"RubyGems 1.0.0" by Per

Thu, 20 Dec 2007 07:57:16 -0800

Congratulations! But does it still ask if I want to install the win32 versions on Linux and Mac?

"RubyGems 1.0.0" by Jason L Perry

Thu, 20 Dec 2007 07:17:57 -0800

gmarik, Can you alias it in your code yourself? Or, do you need it everywhere all the time?

"RubyGems 1.0.0" by gmarik

Thu, 20 Dec 2007 05:32:53 -0800

Cool! I updated but then downgraded back to 0.9.5 as i have old code which uses Kernel#require_gem. Is there a way to upgrade to 1.0 but still have Kernel#require_gem aliased to Kernel#gem ?(say to have autoloaded legacy.rb with ruby which does the aliasing? )

Thanks!