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!

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

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

Great work, Eric!

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

Thanks!

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

@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

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?

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.

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…

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?

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

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

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

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?

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

Nothing about the problem I mentioned?

///ark

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

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

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.

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

@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”.

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