[ANN] RubyGems 0.9.5

ruby-talk
21

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

···

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

--
Posted via http://www.ruby-forum.com/\.

22

Austin Ziegler 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:

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

I'm all ears if some one wants to fill me in on what Apple did...

but...

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a dozen
options to work around this. It's that it will never 'just' work until
RubyGems allows for these types of distribution requirements and there's
absolutely no reason it can't.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib and it moved it's
gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

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. Why would id decide to
install into /usr/local?

RubyGems has become a core part of Ruby. It needs to just work! As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.

···

On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

--
Posted via http://www.ruby-forum.com/\.

23

Austin Ziegler wrote:

Michael Greenly wrote:

Hardly... in all package managed systems /usr/lib belongs to the package
manager. No other application should ever be mucking around in there.
This is not something unique to Debian based systems. It's just that
Debian users tend to be more more vocal about these policies.

Let me emphasize what you just said. /usr/lib belongs to the package
manager on all distros! There's a *reason* the Ruby source and most
other upstream sources install to ("--prefix" in "configure")
*/usr/local* rather than */usr* by default. So ... your options are

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:

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

···

On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

24

Austin Ziegler wrote:
> 4. Complain to your distro manager to be more sensible when it comes
> to Ruby. Look closely at what Apple did for good suggestions.
I'm all ears if some one wants to fill me in on what Apple did...

Look to posts by Laurent Sansonetti on this list or the rubygems developer list.

but...

My issue is not with distribution packaging it's with the poor
assumptions that RubyGems makes. It's not that I don't have a dozen
options to work around this. It's that it will never 'just' work until
RubyGems allows for these types of distribution requirements and there's
absolutely no reason it can't.

There's also absolutely no reason it should. There are plenty of
options if you're having to update a system location, as Eric Hodel
has pointed out in the past.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib and it moved it's
gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Right. But you installed an *upstream* package (gem update --system)
over a *downstream* package. RubyGems is absolutely *correct* to
assume that I want RubyGems itself to be in the same location as Ruby.
If I want something different (which, frankly, *I* don't) then I have
options available through environment variables. Again, see recent
posts by Eric Hodel for sanctioned options, or Laurent's summary of
Leopard changes to see how you're advised to upgrade RubyGems on
Leopard. It's not "gem update --system", but it's not significantly
harder (I think it's SOME_ENV_VAR=other-location gem update --system).

RubyGems has become a core part of Ruby. It needs to just work!

Fact: it does.

As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.

I don't know why you can't. I'd have no problem using Ruby and
RubyGems on a production server at all.

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

-austin

···

On 11/20/07, Michael Greenly <mgreenly@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

25

Austin Ziegler 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:

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

I'm all ears if some one wants to fill me in on what Apple did...

Apple wanted to integrate RubyGems with Leopard in a manner that was as invasive as Debian's, but instead of demanding changes, provided patches with tests.

My issue is not with distribution packaging it's with the poor assumptions that RubyGems makes. It's not that I don't have a dozen options to work around this. It's that it will never 'just' work until RubyGems allows for these types of distribution requirements and there's absolutely no reason it can't.

RubyGems allows for this and has for a long time. GEM_PATH and GEM_HOME are not new. Even lower-level than that, you can override values in Config::CONFIG from Ruby to match what you desire and not need to set GEM_HOME at all.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib

My understanding of the FHS says that you are not allowed to install software into /usr/lib, only Debian is allowed to do that. So a hand-installed (even gem update --system) RubyGems must be installed in /usr/local.

and it moved it's gem cache from /var/lib/rubygems to /usr/lib/ruby/gems. Why?

Because Debian added a hard-coded hack RubyGems to use /var/lib instead of using GEM_PATH and GEM_HOME. I don't know why RubyGems is using /usr/lib/ruby/gems instead of /usr/local/lib/ruby/gems, but I suspect that Ruby's Config::CONFIG has been partially modified.

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.

Why would id decide to install into /usr/local?

My understanding of FHS says that RubyGems must be installed in /usr/local if you install it by hand.

RubyGems has become a core part of Ruby. It needs to just work! As it
is I still can't use it on production servers because I have no
confidence it's not going to going to go mucking around in folders that
don't belong to it.

Set GEM_HOME correctly, and RubyGems will only touch that directory on install or uninstall.

···

On Nov 20, 2007, at 08:18 , Michael Greenly wrote:

On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

26

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

-austin

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.

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!

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.

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.

···

--
Posted via http://www.ruby-forum.com/\.

27

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.

···

On Wed, Nov 21, 2007 at 08:09:18AM +0900, Eric Hodel 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.

--
Sylvain

28

Austin Ziegler 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:

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

What Debian is doing is sensible. Your decision to use non-debian methods
to upgrade RubyGems (instead of waiting for apt-get to have the new
version) is what broke things. This is true of all distributions with
package managers. If you upgrade outside the packaging system, it will
break things.

This latest update some how decided to install rubygems to /usr/local
even though it was previously installed in /usr/lib

My understanding of the FHS says that you are not allowed to install
software into /usr/lib, only Debian is allowed to do that. So a hand-
installed (even gem update --system) RubyGems must be installed in /
usr/local.

and it moved it's gem cache from /var/lib/rubygems to /usr/lib/
ruby/gems. Why?

This would probably happen if running gem update --system to go from
0.9.4 to 0.9.5 still used the 0.9.4 rules for determining the path. (Does
anyone know if this is the case?) An upgrade from 0.9.5 to 0.9.6 would
then work correctly. (Subject to the caveat that one should not use Gem's
upgrade methods to upgrade if they installed from the package manager
originally.)

Because Debian added a hard-coded hack RubyGems to use /var/lib instead
of using GEM_PATH and GEM_HOME. I don't know why RubyGems is using
/usr/lib/ruby/gems instead of /usr/local/lib/ruby/gems, but I suspect
that Ruby's Config::CONFIG has been partially modified.

See /usr/share/doc/libgems-ruby1.8/README.Debian which says that Debian's
rubygems package respects your GEM_HOME environment variable if you set
it yourself.

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.

Adding GEM_HOME in this way would be badly broken from the distribution's
perspective. See debian-devel Jun 1999 by thread
msg00561.html

--Ken

···

On Tue, 20 Nov 2007 18:09:18 -0500, Eric Hodel wrote:

On Nov 20, 2007, at 08:18 , Michael Greenly wrote:

On 11/20/07, M. Edward (Ed) Borasky <znmeb@cesmail.net> wrote:

--
Ken (Chanoch) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/

29

> 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

···

On 11/20/07, Michael Greenly <mgreenly@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

30

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

-austin

···

On 11/21/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote:

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

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

31

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

···

On Nov 21, 2007 10:12 AM, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote:

On Wed, Nov 21, 2007 at 08:09:18AM +0900, Eric Hodel 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.

32

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.

···

On Nov 21, 2007 6:31 AM, Austin Ziegler <halostatue@gmail.com> 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.

33

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.

···

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

On 11/21/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> 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.

--
Sylvain

34

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

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:

···

On Nov 21, 10:52 am, Laurent Sansonetti <laurent.sansone...@gmail.com> wrote:

On Nov 21, 2007 10:12 AM, Sylvain Joyeux > <sylvain.joy...@polytechnique.org> wrote:

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

35

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

···

On 11/21/07, Eivind Eklund <eeklund@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

36

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

···

On 11/21/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> wrote:

On Wed, Nov 21, 2007 at 10:52:39PM +0900, Austin Ziegler wrote:
> On 11/21/07, Sylvain Joyeux <sylvain.joyeux@polytechnique.org> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

37

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/

···

On Nov 21, 2007, at 10:31 AM, Luis Lavena 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).

--
we can deny everything, except that we have the possibility of being better. simply reflect on that.
h.h. the 14th dalai lama

38

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

···

On Nov 21, 2007 6:31 PM, Luis Lavena <luislavena@gmail.com> wrote:

On Nov 21, 10:52 am, Laurent Sansonetti <laurent.sansone...@gmail.com> > wrote:
> On Nov 21, 2007 10:12 AM, Sylvain Joyeux > > <sylvain.joy...@polytechnique.org> wrote:
> > 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.
>

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:

39

bingo. that sounds like a great idea.

a @ http://codeforpeople.com/

···

On Nov 21, 2007, at 11:07 AM, Laurent Sansonetti 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.

--
it is not enough to be compassionate. you must act.
h.h. the 14th dalai lama

40

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

···

--
Posted via http://www.ruby-forum.com/\.