[ANN] RubyGems 1.3.1

[Eric Hodel]

= Announce: RubyGems Release 1.3.1

NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of
update
instructions if you see "Nothing to update".

Release 1.3.1 fixes some bugs.

Bugs fixed:

* Disregard ownership of ~ under Windows while creating ~/.gem. Fixes
issues related to no uid support under Windows.
* Fix requires for Gem::inflate, Gem::deflate, etc.
* Make Gem.dir respect :gemhome value from config. (Note: this
feature may be
removed since it is hard to implement on 1.9.)
* Kernel methods are now private. Patch #20801 by Stefan Rusterholz.
* Gem::location_of_caller now behaves on Windows. Patch by Daniel
Berger.
* Silence PATH warning.

Deprecation Notices:

* Gem::manage_gems will be removed on or after March 2009.

For a full list of changes to RubyGems and the contributor for each
change, see
the ChangeLog file.

Special thanks to Chad Wooley for backwards compatibility testing and
Luis
Lavena for continuing windows support.

== How can I get RubyGems?

NOTE: If you have installed RubyGems using a package system 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: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of
update
instructions if you see "Nothing to update".

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:

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

== To File Bugs

The RubyGems bug tracker can be found on RubyForge at:
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`.

== Thanks

Keep those gems coming!

-- Jim & Chad & Eric (for the RubyGems team)

 

[Pit Capitain]

= Announce: RubyGems Release 1.3.1

Thank you for the new version. Unfortunately, bug #19268 isn't
resolved yet, so a simple "gem update" still fails on many Windows
installations.

In the bug report, it is suggested to simply continue after an
installation error. A better solution would be to introduce an
additional option for the update command ("--native", "--precompiled",
or something else) to only use gem versions with a precompiled binary.

For example, if I have installed hpricot 0.5 and issue "gem update
hpricot --native", it should update to hpricot 0.6 but not to hpricot
0.6.161.

Regards,
Pit

 

[Bil Kleb]

= Announce: RubyGems Release 1.3.1

Thank you!

NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no
rubygems-update installed. You will need to follow the second set of
update instructions if you see "Nothing to update".

Or something like,

$ sudo gem update --system
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.1
ERROR: While executing gem ... (NameError)
undefined local variable or method `remote_gemspecs'
for #<Gem::Commands::UpdateCommand:0x1208504>

The second update method,

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

worked just fine (but bypassing the first step since it was already done).

Regards,

 

[Luis Lavena]

Thank you for the new version. Unfortunately, bug #19268 isn't
resolved yet, so a simple "gem update" still fails on many Windows
installations.

In the bug report, it is suggested to simply continue after an
installation error. A better solution would be to introduce an
additional option for the update command ("--native", "--precompiled",
or something else) to only use gem versions with a precompiled binary.

For example, if I have installed hpricot 0.5 and issue "gem update
hpricot --native", it should update to hpricot 0.6 but not to hpricot
0.6.161.

As your point may be valid, introducing a new command not only
requires testing but is too major to be something just for a y.z point
release.

I believe the priorities when installing gems should be 'platform-
specific-one' and then 'ruby', contrary to what we have now (ruby,
then-your-platform).

I invite you bring this discussion to rubygems-developer mailing list
so we can workout something for this.

On a side note, I believe we should directly blame gem maintainers for
neglecting the native builds for the platform. Hopefully when GCC-
based Ruby arrives (I know, too vaporware right now) we would rejoice.

Regards,
Pit

Regards,

 

[jason.lapier]

Thank you!


Or something like,

  $ sudo gem update --system
  Updating RubyGems
  Updating rubygems-update
  Successfully installed rubygems-update-1.3.1
  ERROR:  While executing gem ... (NameError)
      undefined local variable or method `remote_gemspecs'
      for #<Gem::Commands::UpdateCommand:0x1208504>

The second update method,


worked just fine (but bypassing the first step since it was already done)..

I had the same error on the update --system, but installing rubygems-
update and running that worked for me. I'm on Ubuntu 8.04.

When I tried doing a gem cleanup, my box chewed through it's 2GB of
system memory and started swapping hard. I remember this memory-eating
bug used to happen on gem update, but was cleared up in a previous
release.

- Jason L.

 

[Daniel Malcolm Webb [dbw]]

I've had a look for exception in here but nothing quite does the job.=20

(10264..10300).each do |i|
...

begin
question_text =3D res_q[0][1].gsub('"', "'")
rescue Exception=3D>g =20
end

...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?=20
At the moment it just comes out of=20
question_text =3D res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want=20

Kind Regards,
Dan

 

[Jesús Gabriel y Galán]

I've had a look for exception in here but nothing quite does the job.

(10264..10300).each do |i|
...

begin
question_text = res_q[0][1].gsub('"', "'")
rescue Exception=>g
end

...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?
At the moment it just comes out of
question_text = res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want

You want the "next" keyword, which directly jumps to the next iteration
in the loop. Take a look also at break, redo and retry for other cases.

irb(main):001:0> %w{a b c d e}.each do |w|
irb(main):002:1* next if w=="c"
irb(main):003:1> puts w
irb(main):004:1> end
a
b
d
e


Jesus.

 

[Charles Oliver Nutter]

As your point may be valid, introducing a new command not only
requires testing but is too major to be something just for a y.z point
release.

I believe the priorities when installing gems should be 'platform-
specific-one' and then 'ruby', contrary to what we have now (ruby,
then-your-platform).

*Strongly* agree...and I also believe any gem that depends on C
extensions which only work on MRI should not be the default "ruby"
platform, since they obviously don't work everywhere. Historical
reasons, I know...but we have to field at least a couple questions a
week from people accidentally trying to install a C extension on JRuby.

- Charlie

 

[Ryan Davis]

I've had a look for exception in here but nothing quite does the job.

do not thread hijack. it isn't hard to start a new mail from scratch.

 

[Daniel Malcolm Webb [dbw]]

Thanks Jesus that's worked a treat! I do love Ruby, just wish I knew =
more syntax.=20

Thanks,
Dan


-----Original Message-----
From: Jes=FAs Gabriel y Gal=E1n [mailto:[email protected]]=20
Sent: 30 October 2008 16:59
To: ruby-talk ML
Subject: Re: Exceptions & loops

I've had a look for exception in here but nothing quite does the job.

(10264..10300).each do |i|
...

begin
question_text =3D res_q[0][1].gsub('"', "'")
rescue Exception=3D>g
end

...
End

If this query throws and exception is there a way of aborting the
current loop i.e. the loop for record #10267 but then loop again for
#10268?
At the moment it just comes out of
question_text =3D res_q[0][1].gsub('"', "'")
and goes onto the next operation within the loop, which is fantastic,
but not quite what I want

You want the "next" keyword, which directly jumps to the next iteration
in the loop. Take a look also at break, redo and retry for other cases.

irb(main):001:0> %w{a b c d e}.each do |w|
irb(main):002:1* next if w=3D=3D"c"
irb(main):003:1> puts w
irb(main):004:1> end
a
b
d
e


Jesus.

 

[Luis Lavena]

*Strongly* agree...and I also believe any gem that depends on C
extensions which only work on MRI should not be the default "ruby"
platform, since they obviously don't work everywhere. Historical
reasons, I know...but we have to field at least a couple questions a
week from people accidentally trying to install a C extension on JRuby.

The problem with that is the _unpredictable_ nature of all the other
"no ruby" platforms.

I alone need to deal with two: i386-mswin32 and i386-mingw32, don't
get me started with x86_64 for 64 bits Windoze...

So I don't see gem developers releasing gems that are the same for all
the known platforms except for "ruby" since ruby will generate this
situation in JRuby.

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

 

[Charles Oliver Nutter]

There is no easy way for this since the gems can have different types
of bundled extensions (via mkrf or extconf).

My argument is that any Ruby impl requirement should be explicit in the
gemspec; i.e. it should be possible to install a gem that will only ever
work on MRI since it would say it only works on MRI. And likewise for
JRuby...there's already a couple non-platform gems that only work in
JRuby. Without adding "supported implementations" to the gemspec it will
only get worse.

- Charlie

 

[Charles Oliver Nutter]

My argument is that any Ruby impl requirement should be explicit in the
gemspec; i.e. it should be possible to install a gem that will only ever
work on MRI since it would say it only works on MRI.

Er, I meant "it should NOT be possible to install a gem...."

- Charlie