[ANN] RubyGems 0.9.5

[Eric Hodel]

Eric Hodel wrote:
RubyGems 0.9.5 adds several new features and fixes several bugs.

RubyGems 0.9.5 looks great but I cannot installed the ruby-debug-ide
gem.

I just create an issue on the RubyForge tracker :

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

I tried forcing a local installation of ruby-debug-ide-0.1.9.gem and
this works :
gem install -l ruby-debug-ide

It's a bit strange as I have been able to install ruby-debug-base
(ruby-debug-base-0.9.3-mswin32.gem) without the local flag (-l).

I think that I have understood what's happening :
- rubygems 0.9.5 includes dependencies during installation by default
now
- when I first install ruby-debug-base locally (without -l), it
works as
this gem has no dependency on other gems
- then when I tried to install ruby-debug-ide locally (again without
-l), it fails as it seems that rubygems tries to install the required
dependency (ruby-debug-base) remotely and not locally.

Forcing the local installation with -l solves my problem.

This raises two issues :
1- rubygems seems to not take care of gems that are already installed
(during the dependency checking)

It does for me:

$ gem fetch ruby-debug-base
missing 9371 gems
Bulk updating Gem source index for: http://gems.rubyforge.org
Downloaded ruby-debug-base-0.9.3.gem
[ 15:15 drbrain@kaa:~/tmp ]
$ gem install -l ruby-debug-base -i gems
Installing gem ruby-debug-base-0.9.3
Using local gem /Users/drbrain/tmp/gems/cache/ruby-debug-base-0.9.3.gem
Building native extensions. This could take a while...
Successfully installed ruby-debug-base-0.9.3
1 gem installed
Installing ri documentation for ruby-debug-base-0.9.3...
Installing RDoc documentation for ruby-debug-base-0.9.3...
[ 15:16 drbrain@kaa:~/tmp ]
$ gem install ruby-debug-ide -i gems
Installing gem ruby-debug-ide-0.1.9
Downloading gem ruby-debug-ide-0.1.9.gem
Successfully installed ruby-debug-ide-0.1.9
1 gem installed

If you can reproduce your issue, please file a bug.

2- rubygems should try to install dependency gems locally before
remotely.

Yes, I think this is the core of #15759, so I updated the title.

 

[M. Edward (Ed) Borasky]

4. Complain to your distro manager to be more sensible when it comes
to Ruby. Look closely at what Apple did for good suggestions.

-austin

Apple Computer is a for-profit entity. Unless you're buying SuSE/Novell
or RHEL support, I wouldn't count on getting much sympathy from the
distro. I see people from Apple and Microsoft and Sun at RubyConf, but I
don't see people from Gentoo, Debian or Ubuntu, or even Red Hat. If you
were in Charlotte, please speak up and prove me wrong.

I personally think Gentoo is close to optimal in their interaction with
RubyGems, but it gets dicey if you want to use a gem that *isn't* in
Portage. I have multiple Ruby versions on my machines and simply tweak
the PATH and other environment variable settings to get the one I want.

 

[Austin Ziegler]

That actually made me laugh. Debian doesn't get package managment?
It's really quite the opposite. RubyGems started with a very poor
understanding of living in a package managed world.

Try responding to what was actually written. I said Debian maintainers
Don't Get Ruby. And, to be honest, I question whether they *do* get
package management sometimes. It works well, most of the time, but
they're completely wrong on a number of factors -- mostly because in a
C/C++ binary world, you *have* to do some things certain ways. They're
guilty of a lack of imagination.

In theory it currently has the necessary tools. If --prefix installs
and $GEM_HOME were properly respected there wouldn't be a problem, but
there not!

Yes, they are.

If they were my stupid 'update --system' mistake wouldn't have moved
ruby gems library from /usr to /usr/local and the gem_home from
/var/lib/rubygems to /usr/lib/ruby/gems.

Wrong. RubyGems can't predict when some dumbass maintainer is going to
make an idiotic hardcoded changes. It's certainly **never** going to
be accepted upstream that way.

Your "update --system" problem goes right back to the maintainers, not
RubyGems. At all.

RubyGems needs to work correctly no matter where Ruby is installed. It
needs to never modify files outside of --prefix (or installed defined
directories) and it needs to consistently respect $GEM_HOME.

Right. But you have to get it to know about those places -- and it
*does* consistently respect $GEM_HOME. Just because your maintainer
was stupid enough to MODIFY THE SOURCE rather than using, you know,
ENVIRONMENT VARIABLES doesn't make it RubyGems fault.

Your breakage was because through update --system you ended up putting
a non-bastardized version of RubyGems on your system (and it's not
going to bastardize itself for your broken packages) and moving things
around from the broken places that the dumbass maintainer placed them.

There's a right way and there's a wrong way. Debian -- and therefore
Ubuntu -- chose the wrong way. Apple, on the other hand, chose the
right way (*including* telling people how to update preinstalled gems
and RubyGems itself).

-austin

 

[Sylvain Joyeux]

Yes, it is regrettable that Debian didn't instead add GEM_HOME to
/etc/profile (or equivalent). In that case (other than the /usr/lib vs
/usr/local/lib problem) upgrading RubyGems would Just Work.

Maybe because they would have to do that for every conceivable shell
lying around ? It does not seem practicle to me. In my opinion, the
right solution would have been to make RubyGem read a global
configuration file in /etc which defines sensible GEM_HOME and GEM_PATH
values. Relying on environment variables is not doable system-wide.

My guess is that they did not want to spend time digging into RubyGems
code and writing the patch.

 

[Chauk-Mean P.]

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide

1- rubygems seems to not take care of gems that are already installed
(during the dependency checking)

It does for me:

$ gem fetch ruby-debug-base
missing 9371 gems
Bulk updating Gem source index for: http://gems.rubyforge.org
Downloaded ruby-debug-base-0.9.3.gem
[ 15:15 drbrain@kaa:~/tmp ]
$ gem install -l ruby-debug-base -i gems
Installing gem ruby-debug-base-0.9.3
Using local gem /Users/drbrain/tmp/gems/cache/ruby-debug-base-0.9.3.gem
Building native extensions. This could take a while...
Successfully installed ruby-debug-base-0.9.3
1 gem installed
Installing ri documentation for ruby-debug-base-0.9.3...
Installing RDoc documentation for ruby-debug-base-0.9.3...
[ 15:16 drbrain@kaa:~/tmp ]
$ gem install ruby-debug-ide -i gems
Installing gem ruby-debug-ide-0.1.9
Downloading gem ruby-debug-ide-0.1.9.gem
Successfully installed ruby-debug-ide-0.1.9
1 gem installed

If you can reproduce your issue, please file a bug.

What you did is installing ruby-debug-ide remotely.
Conversely, what I did is installing ruby-debug-ide locally (with the -l
flag).
In this case, ruby-debug-base is installed again.

I filed the following bug report with the precise steps.

[#15790] Rubygems 0.9.5 doesn't take care of already installed gems for
local installation

Yes, I think this is the core of #15759, so I updated the title.

OK.

Cheers.

Chauk-Mean.

 

[Austin Ziegler]

My guess is that they did not want to spend time digging into RubyGems
code and writing the patch.

Which, again, isn't RubyGems problem. It's a Debian problem. Ruby and
RubyGems installed from source work just fine.

-austin

 

[Laurent Sansonetti]

Maybe because they would have to do that for every conceivable shell
lying around ? It does not seem practicle to me. In my opinion, the
right solution would have been to make RubyGem read a global
configuration file in /etc which defines sensible GEM_HOME and GEM_PATH
values. Relying on environment variables is not doable system-wide.

I also agree with this, it would be nice if RubyGems was reading a
system-wide configuration file as well as environment variables.

Maybe the 1.9 integration will provide a way to set default values for
these variables at build time.

Laurent

 

[Eivind Eklund]

Right. But you have to get it to know about those places -- and it
*does* consistently respect $GEM_HOME. Just because your maintainer
was stupid enough to MODIFY THE SOURCE rather than using, you know,
ENVIRONMENT VARIABLES doesn't make it RubyGems fault.

The problem is that environment variables is a lousy way to keep
around configuration for programs, for a variety of reasons:
- They're hard to control generally (stuff remove them/limit to
specific sets of them, there's no generic place to set them)
- There is actually limited environment space and environment space,
and every environment variable eats space from the arguments allowed
to every process, no matter if it is related to Ruby or not.

The POSIX default number of bytes for arguments plus environment
variables (ARG_MAX) is actually 4096 bytes, so for POSIX minimal OS
this is a real problem. In practice modern operating systems mostly
set ARG_MAX in the range 64k to 256k. 64k still small enough that if
all manner of stuff played around with using environment variables as
their config, it would be a problem in practice for some. There are
side effects of increasing ARG_MAX, e.g. increased kernel virtual
memory use which goes at the expense of user space (unfortunate on
32-bit systems with large amounts of memory wanted for user space
apps) and I expect increased RAM use per program.

To my mind, the "right" way to deal with this particular issue would
probably be to have RubyGems automatically patch itself on update,
keeping the old paths around in the new "binary". Yeah, it's icky.
It seems less icky than the alternative, which is an application that
needs environment variables to work correctly, and (from a user's
perspective, as seen by the initial complaint) mess up in the absence
of them

Eivind.

 

[Sylvain Joyeux]

Which, again, isn't RubyGems problem. It's a Debian problem. Ruby and
RubyGems installed from source work just fine.

I think that's what people think when they say "you don't get anything
about package distribution". You don't care. Fine. Then just admit it
instead of saying that Debian people are messing RubyGems. They are
simply trying to cope with you not wanting to be distribution-friendly.

 

[Austin Ziegler]

To my mind, the "right" way to deal with this particular issue would
probably be to have RubyGems automatically patch itself on update,
keeping the old paths around in the new "binary". Yeah, it's icky.

It's completely wrong and completely *not* RubyGems responsibility.
RubyGems shouldn't be patching/diffing. Do you know of *any* program
that does that?

This problem isn't RubyGems problem. While I might agree that
environment variables aren't ideal (they're not), they are the way
that RubyGems works.

Don't like it and have a better idea? Provide patches. Patches that
would make RubyGems work around a patched version of RubyGems, though,
should be rejected with force.

It seems less icky than the alternative, which is an application that
needs environment variables to work correctly, and (from a user's
perspective, as seen by the initial complaint) mess up in the absence
of them

The problem is that Mr. Greenly did something that shouldn't have been
allowed. It's not RubyGems responsibility to prevent that; it's the
Debian maintainers responsibility to disallow it if they're going to
incompatibly (and stupidly) change a package that they're maintaining.

-austin

 

[Austin Ziegler]

I think that's what people think when they say "you don't get anything
about package distribution". You don't care. Fine. Then just admit it
instead of saying that Debian people are messing RubyGems. They are
simply trying to cope with you not wanting to be distribution-friendly.

Note: I'm *not* part of the RubyGems team. I haven't submitted a patch
for anything RubyGems as far as I know.

Why *should* RubyGems care? It isn't *for* Debian. It isn't *for*
Gentoo. It isn't *for* Mac OS X. It's for Ruby.

Fact set one: Apple (1) modified RubyGems; (2) submitted patches to
the RubyGems project based on what they did; and (3) provided
instructions on how to update the default RubyGems in a way that was
still compatible with how Apple installed Ruby.

Fact set two: Debian (1) modified RubyGems; (2) didn't submit any
patches; (3) made a particularly stupid modification; and (4) provided
nothing to help users upgrade RubyGems externally of the Debian
packages.

I personally don't want to see any changes to RubyGems that are *for*
one particular operating system (or worse, a mere Linux distribution).
Not all operating systems have /etc available (see Windows, still an
important target for Ruby).

I'd rather see RubyGems team spend its effort making sure that it
works well with MRI, XRuby, JRuby, Ruby.NET, IronRuby, etc. than
wasting their time trying to please Debian zealots who can't be
bothered to think beyond their noses.

-austin

 

[Luis Lavena]

I also agree with this, it would be nice if RubyGems was reading a
system-wide configuration file as well as environment variables.

System-wide? /etc/gemrc? That seems inpractical and forces another
check *if* you're in a *nix environment and the FHS layout exist
(which is not the case for distros like GoboLinux).

Maybe the 1.9 integration will provide a way to set default values for
these variables at build time.

RubyGems on 1.9 is like irb: they run out of the box with data stored
in lib/ruby/1.8

Why this should behave differently?

What I see that have potential is have the scripts installed by
rubygems and the gems itself relocatable (using GEM_HOME and
GEM_PATH), in that way you can replace your ruby+rubygems version and
still be able to use gems.

Like multi-ruby without duplicated files all over the place.

As example of best practices, I plan to test that for Ruby on Windows
and submit patches and documentation about the changes ;-)

--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

 

[ara.t.howard]

System-wide? /etc/gemrc? That seems inpractical and forces another
check *if* you're in a *nix environment and the FHS layout exist
(which is not the case for distros like GoboLinux).

why not simply allow for a site-wide gem configuration *within* the
top level rubylib dir?

/opt/local/lib/ruby/1.8/gem_config.rb # or maybe yml

that way it's per ruby and can be determined easily from each ruby

require 'rbconfig'

rubylibdir = Config::CONFIG['rubylibdir']

gem_site_config = File.join rubylibdir, 'gem_config.rb'

if test ?e, gem_site_config
load gem_site_config
end


etc.

a @ http://codeforpeople.com/

 

[Laurent Sansonetti]

System-wide? /etc/gemrc? That seems inpractical and forces another
check *if* you're in a *nix environment and the FHS layout exist
(which is not the case for distros like GoboLinux).


RubyGems on 1.9 is like irb: they run out of the box with data stored
in lib/ruby/1.8

Why this should behave differently?

What I see that have potential is have the scripts installed by
rubygems and the gems itself relocatable (using GEM_HOME and
GEM_PATH), in that way you can replace your ruby+rubygems version and
still be able to use gems.

Like multi-ruby without duplicated files all over the place.

As example of best practices, I plan to test that for Ruby on Windows
and submit patches and documentation about the changes ;-)

System-wide doesn't necessarily mean /etc, default values for GEM_*
could be stored for example in rbconfig.rb, as part of the 1.9 build.

Laurent

 

[ara.t.howard]

System-wide doesn't necessarily mean /etc, default values for GEM_*
could be stored for example in rbconfig.rb, as part of the 1.9 build.

bingo. that sounds like a great idea.

a @ http://codeforpeople.com/

 

[Eric Hodel]

bingo. that sounds like a great idea.

And this is how RubyGems works right now, *unless* you want to do
something different.

In that case you have two options:

a) use GEM_* environment variables
b) patch rbconfig.rb

If these options aren't good enough, I'll evaluate patches to add
some other way of finding defaults. I won't just implement it in a
vacuum since I don't use it, so I'm likely to make something that
can't solve the problem.

 

[Laurent Sansonetti]

bingo. that sounds like a great idea.

And this is how RubyGems works right now, *unless* you want to do
something different.

In that case you have two options:

a) use GEM_* environment variables
b) patch rbconfig.rb
[...]

Well, it's not easy to set up multiple gem repositories from
rbconfig.rb... unless you create ENV['GEM_PATH'] there, which should
work fine. But creating temporary environment variables from
rbconfig.rb seems a bit weird, to me.

Laurent

 

[Michael Greenly]

I'd rather see RubyGems team spend its effort making sure that it
works well with MRI, XRuby, JRuby, Ruby.NET, IronRuby, etc. than
wasting their time trying to please Debian zealots who can't be
bothered to think beyond their noses.

-austin

It's became very obvious to me who the anti-debian zealot is. You may
not use it or even care about it, personally I could care less if Ruby
was supported on Windows at all but that wouldn't cause me to lobby
against making allowances for it's support.

 

[Michael Greenly]

Michael Greenly wrote:

So this thread left me thinking about how I'd like to see RubyGems work
on Debian...

Using environment variables to override locations makes sense for end
users but not for base system configuration. Either using a file in
rubylibdir or a value in rbconfig both seem like excellent choices. Or
better yet using all these methods in an ordered evaluation seems the
best choice.

The one thing I keep sticking on is how do you handle 'gem update
--system'

Assuming that RubyGems is installed initially through a a distro package
it obviously can't update it's self in place. I think the ideal
solution here is that RubyGems (through load paths) allowed for two
levels of installation.

What I mean is if the Debian distributed RubyGems was initially
installed right along side Ruby but an 'update --system' caused it to
install the new version to some none-dpkg controlled directory (that had
load order precedence) everything would mostly work as expected.

It's not a perfect solution. There's the potential for users to get
confused about which RubyGems is getting used but they can check using
'gem environment'.

Is this at all what Apples patch did? or was that just for the gem
location?

 

[Luis Lavena]

Michael Greenly wrote:

So this thread left me thinking about how I'd like to see RubyGems work
on Debian...

Using environment variables to override locations makes sense for end
users but not for base system configuration. Either using a file in
rubylibdir or a value in rbconfig both seem like excellent choices. Or
better yet using all these methods in an ordered evaluation seems the
best choice.

The one thing I keep sticking on is how do you handle 'gem update
--system'

Assuming that RubyGems is installed initially through a a distro package
it obviously can't update it's self in place. I think the ideal
solution here is that RubyGems (through load paths) allowed for two
levels of installation.

What I mean is if the Debian distributed RubyGems was initially
installed right along side Ruby but an 'update --system' caused it to
install the new version to some none-dpkg controlled directory (that had
load order precedence) everything would mostly work as expected.

It's not a perfect solution. There's the potential for users to get
confused about which RubyGems is getting used but they can check using
'gem environment'.

Is this at all what Apples patch did? or was that just for the gem
location?

On any case, that wouldn't work. Doesn't packages contains a file
manifest bundled indicating which files are part of it? Also will
happen for ruby installed as package.

So, if you use gem system --update functionality, you brake your
package manager

How users would remove it later if "they don't like the updated
version"? what about duplication or you trying to find installed gems
in wrong places? (due the non-dpkg and dpkg'ed versions).

Hehehe, no intention to offend anyone, but I feel better manually
downloading and compiling ruby and installing rubygems than using apt-
get or whatever package managing solution the platform offer.

--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi