RubyGems 0.9.5

Ruby
21

Austin Z. wrote:

  1. Work with the packages as supplied by your distro.
  2. Don’t install the packages supplied by your distro – use upstream
    source and put things in /usr/local.
  3. Complain and whine to busy people who will blow you off. :slight_smile:
  1. 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. :slight_smile:

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.

22

On Mon, 19 Nov 2007 19:35:27 -0500, Eric H. wrote:

RubyGems 0.9.5 adds several new features and fixes several bugs.

Congratulations! I know this is a major step for the Gems team as they
merge their codebase with 1.9… cool beans.

23

On Nov 20, 2007, at 07:14 , Chauk-Mean P. wrote:

[#15759] rubygems 0.9.5 cannot install ruby-debug-ide
now
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.

24

Eric H. wrote:

On Nov 20, 2007, at 07:14 , Chauk-Mean P. wrote:

[#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

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.

OK.

Cheers.

Chauk-Mean.

25

On 11/20/07, Michael G. [email protected] wrote:

I’d just never use an Ubuntu package for Ruby or RubyGems. Ever. (Why?
The upstream maintainers at Debian Don’t Get Ruby. While the situation
is better than it has been, it’s still a freaking nightmare.)
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

26

On Wed, Nov 21, 2007 at 08:09:18AM +0900, Eric H. wrote:

Now I realize the paticular oddities of this are not necessarily
RubyGems problems. I was using the Ubuntu patched version, but I’ve
looked at that patch and all it did was hardcode the GEM_HOME
environment variable to be /var/lib/rubygems.

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.

27

On Nov 21, 2007 10:12 AM, Sylvain J.
[email protected] wrote:

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

28

On 11/21/07, Sylvain J. [email protected] wrote:

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

29

On Wed, Nov 21, 2007 at 10:52:39PM +0900, Austin Z. wrote:

On 11/21/07, Sylvain J. [email protected] wrote:

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.

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.

30

On Nov 21, 2007 6:31 AM, Austin Z. [email protected] wrote:

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.

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.

31

On 11/21/07, Eivind E. [email protected] wrote:

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

32

On 11/21/07, Sylvain J. [email protected] wrote:

On Wed, Nov 21, 2007 at 10:52:39PM +0900, Austin Z. wrote:

On 11/21/07, Sylvain J. [email protected] wrote:

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

33

On Nov 21, 2007, at 10:31 AM, Luis L. wrote:

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

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/

34

On Nov 21, 2007 6:31 PM, Luis L. [email protected] wrote:

I also agree with this, it would be nice if RubyGems was reading a
RubyGems on 1.9 is like irb: they run out of the box with data stored

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

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

35

On Nov 21, 10:52 am, Laurent S. [email protected]
wrote:

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

–
Luis L.
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

36

On Nov 21, 2007, at 11:07 AM, Laurent S. wrote:

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/

37

On Nov 21, 2007, at 10:24 , ara.t.howard wrote:

On Nov 21, 2007, at 11:07 AM, Laurent S. wrote:

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.

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.

38

Austin Z. wrote:

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.

39

Michael G. 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?

40

On Nov 21, 2007 9:35 PM, Eric H. [email protected] wrote:

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