RubyGems 1.0.0

drbrain | Thu, 20 Dec 2007 08:32:58 GMT

Posted in ,

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:

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

(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:

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

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

Thanks

Keep those gems coming!

comments

Comments RSS FEED

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 said about 5 hours later

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

Jason L Perry said about 7 hours later

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

Per said about 7 hours later

Great work, Eric!

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

Thanks!

Warren said about 9 hours later

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

gmarik said about 9 hours later

@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

Luis Lavena said about 10 hours later

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 said about 11 hours later

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 Lavena said about 11 hours later

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…

Warren said about 13 hours later

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?

mike said about 17 hours later

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 said about 17 hours later

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

Eric Hodel said about 18 hours later

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

Mark Wilden said about 18 hours later
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?

Kris Nuttycombe said 1 day later

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

Eric Hodel said 1 day later

Nothing about the problem I mentioned?

///ark

Mark Wilden said 3 days later

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

raggi said 3 days later

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 Wilden said 3 days later

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.

Eric Hodel said 4 days later

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

Mark Wilden said 4 days later

@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 said 8 days later

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

Eric Hodel said 9 days later

Comments are disabled