Recommended way to install Rubygems

[Leslie Viljoen]

[Note: parts of this message were removed to make it a legal post.]

Hi!

I am trying to install Ruby1.9.1 under Ubuntu 9.10 - with gems. I can
"apt-get install ruby1.9.1", but I have often had trouble
mixing package managers and installing rubygems using apt-get so I usually
download it. I also see warnings on the 'net
that installing rubygems using apt-get is not recommended.

Contrary to http://ryanbigg.com/2009/01/ruby-191-rubygems-rails/, rubygems
does not come included with ruby1.9.1 on Ubuntu,
I suppose because it is packaged separately (perhaps wrongly?)

So what I have tried to do is install gems by running the setup.rb program
using ruby1.9.1. This seems to work, and I then
get a gem1.9.1 which I can use to install gems. But when I try to require
those gems, they seem to be missing:


$ gem1.9.1 list

*** LOCAL GEMS ***

file-find (0.3.4)
sys-admin (1.5.2)
$ irb1.9.1
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'file/find'
LoadError: no such file to load -- file/find


so... should I be using apt-get?

 

[robb]

[Note: parts of this message were removed to make it a legal post.]

Hi!

I am trying to install Ruby1.9.1 under Ubuntu 9.10 - with gems. I can
"apt-get install ruby1.9.1", but I have often had trouble
mixing package managers and installing rubygems using apt-get so I usually
download it. I also see warnings on the 'net
that installing rubygems using apt-get is not recommended.

Contrary to http://ryanbigg.com/2009/01/ruby-191-rubygems-rails/, rubygems
does not come included with ruby1.9.1 on Ubuntu,
I suppose because it is packaged separately (perhaps wrongly?)

So what I have tried to do is install gems by running the setup.rb program
using ruby1.9.1. This seems to work, and I then
get a gem1.9.1 which I can use to install gems. But when I try to require
those gems, they seem to be missing:


$ gem1.9.1 list

*** LOCAL GEMS ***

file-find (0.3.4)
sys-admin (1.5.2)
$ irb1.9.1
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'file/find'
LoadError: no such file to load -- file/find


so... should I be using apt-get?

If you do choose to install via apt, here's the Ubuntu documentation on
RubyGems from the Rails page:

https://help.ubuntu.com/community/RubyOnRails#Installing RubyGems

 

[Eric Hodel]

I am trying to install Ruby1.9.1 under Ubuntu 9.10 - with gems. I can
"apt-get install ruby1.9.1", but I have often had trouble
mixing package managers and installing rubygems using apt-get so I = usually
download it. I also see warnings on the 'net
that installing rubygems using apt-get is not recommended.
=20
Contrary to http://ryanbigg.com/2009/01/ruby-191-rubygems-rails/, = rubygems
does not come included with ruby1.9.1 on Ubuntu,
I suppose because it is packaged separately (perhaps wrongly?)
=20
So what I have tried to do is install gems by running the setup.rb = program
using ruby1.9.1. This seems to work, and I then
get a gem1.9.1 which I can use to install gems. But when I try to = require
those gems, they seem to be missing:
=20
=20
$ gem1.9.1 list
=20
*** LOCAL GEMS ***
=20
file-find (0.3.4)
sys-admin (1.5.2)
$ irb1.9.1
irb(main):001:0> require 'rubygems'
=3D> true
irb(main):002:0> require 'file/find'
LoadError: no such file to load -- file/find
=20
=20
so... should I be using apt-get?

Maybe there's a package with all of ruby instead of just the pieces that =
ubuntu thinks constitutes ruby.

My recommendation is to install all of ruby by hand instead of using =
apt-get.=

 

[Lucas Nussbaum]

(Please Cc me when replying, I don't follow ruby-talk@ closely enough to
notice replies)

Maybe there's a package with all of ruby instead of just the pieces
that ubuntu thinks constitutes ruby.

My recommendation is to install all of ruby by hand instead of using
apt-get.

In the past, we (Debian Ruby maintainers, so de-facto Ubuntu Ruby
maintainers since Ubuntu just imports the Ruby packages from Debian) had
problems with the fact that rubygems was shipped with the Ruby
interpreter itself: some gems required a version of rubygems that was
more recent than the one provided by the interpreter.

So the decision was taken to get rubygems directly from upstream,
independantly of the version shipped in ruby 1.8.X or ruby 1.9.1.Y.

Now, on the fact that ruby is split out into several packages, it is
justified by the fact that some ruby apps don't require all the native
libraries normally built with the interpreter (readline, openssl, etc).
To cut off the number of other packages needed on a minimal system that
would just need a ruby interpreter without, say, readline, some of the
native libraries are packaged separately, in the following packages:
libdbm-ruby1.9.1, libgdbm-ruby1.9.1, libreadline-ruby1.9.1,
libtcltk-ruby1.9.1, libopenssl-ruby1.9.1.

For users who want to install "all of ruby", we also provide two
packages that only depend on all the other packages: ruby-full (for 1.8)
and ruby1.9.1-full (for 1.9.1, obviously).

I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
Also, it would be great if all the sarcasm and nasty comments on this
list each time someone brings up Ruby and Debian or Ubuntu could be
reduced a bit. I am working on providing Ruby packages in Debian and
Ubuntu as a volunteer, and don't really enjoy all the flames I get on
this list. Constructive criticism is welcomed (preferably as bug
reports), but is very rare here, unfortunately.

 

[Eric Hodel]

I hope this clarifies the status of Ruby in Debian and Ubuntu a bit.
Also, it would be great if all the sarcasm and nasty comments on this
list each time someone brings up Ruby and Debian or Ubuntu could be
reduced a bit. I am working on providing Ruby packages in Debian and
Ubuntu as a volunteer, and don't really enjoy all the flames I get on
this list. Constructive criticism is welcomed (preferably as bug
reports), but is very rare here, unfortunately.

Unfortunately I end up having to handle most of the issues that Debian =
creates due to their splitting up Ruby into multiple packages because of =
the way it affects Ruby and RubyGems. I can reduce my support load and =
increase my free time by saying "install all of Ruby and RubyGems by =
hand on Debian and Ubuntu". Once RubyGems is installed it's fairly =
smooth sailing on Debian unless you install a gem that needs to compile =
against missing headers.

It's especially frustrating when features are added to RubyGems that =
have the express goal of helping Debian and Ubuntu are either ignored =
(rubygems/defaults/operating_system, added in 1.2.0) or are rejected for =
what seems to boil down to policy reasons (Neil Wilson's work in =
http://bugs.debian.org/403407).

When you say things like:

The problem is that the upstream rubygems developers don't care, and =

that it's impossible to change that without their cooperation.

I don't see how we (that work on RubyGems) could possibly have ever =
cared if you're not subscribed to the mailing list where you would raise =
those concerns nor have you filed any bugs with any of these concerns.

We certainly can't cooperate when you don't bother to raise any issues =
in the places we're looking for them.

PS:

Not taking advantage of rubygems/defaults/operating_system is especially =
odd to me as it would allow upgrades of RubyGems to continue to work =
while maintaining Debian's customizations. Last I checked the only =
changes made to RubyGems by Debian could be encapsulated in this one =
file.

PPS:

Maybe you get so much sarcasm and nasty comments because people are =
genuinely frustrated with what Debian provides by default. Maybe =
installing ruby-full by default instead of the minimal ruby will reduce =
your frustrations.

Oftentimes people are following instructions they found on the web that =
were written for non-Debian/Ubuntu. On OS X, BSD, and most other Linux =
versions those instructions will work without modification, but since =
Debian is subtly different they end up coming here and we end up =
answering the same questions over and over, which will inevitably lead =
to us making sarcastic, nasty comments.

=46rom maintaining RubyGems I've learned that maintaining a large, =
popular open-source library requires a thick skin and the ability to say =
"yeah, what I'm doing is not what people want" sometimes.=

 

[Nick Brown]

Lucas: Thanks for maintaining the Ruby package in Ubuntu!

Might I suggest that the package called "ruby" install the standard
ruby, with everything? This would reduce confusion (and disapproving
comments) very much.

If you really think there is big demand for minimal ruby installs, go
ahead and have a ruby-minimal package, too. But you should know that
many people, especially newbies, are mislead by calling something "ruby"
which is actually "partial-ruby".

 

[gf]

I agree, Lucas, thank for maintaining the package. I understand you're
trying to hit a very elusive target, and often probably working from a
poor set of requirements as far as what we, the users, want.

I always wanted a current package of Ruby with rubygems installed, the
drivers for Postgres and MySQL, SSL support, and libxml2 and Nokogiri.
That would give me the ability to process XML and HTML, talk to the
two primary DBs I've used over the last five years, talk to secured
services on the internet, etc., as soon as the install finished. As
is, I've always had to do those things before I could start to use
Ruby on a box in our enterprise.

That's just my $0.02 wishlist.

 

[gf]

That is exactly what I ended up doing on all the Ubuntu-based machines
I had. It was easier to install from source so I had current revisions
of Ruby, and to manage all my gems by hand.

When rvm came out I switched to it and now it's my favorite way to go
on Mac OS and Ubuntu because it handles the grunt work of maintaining
multiple versions of Ruby, allows gem bundles, and makes it trivial to
switch from one version of Ruby to another when testing.

 

[Lucas Nussbaum]

Unfortunately I end up having to handle most of the issues that Debian
creates due to their splitting up Ruby into multiple packages because
of the way it affects Ruby and RubyGems. I can reduce my support load
and increase my free time by saying "install all of Ruby and RubyGems
by hand on Debian and Ubuntu". Once RubyGems is installed it's fairly
smooth sailing on Debian unless you install a gem that needs to
compile against missing headers.

It's especially frustrating when features are added to RubyGems that
have the express goal of helping Debian and Ubuntu are either ignored
(rubygems/defaults/operating_system, added in 1.2.0) or are rejected
for what seems to boil down to policy reasons (Neil Wilson's work in
http://bugs.debian.org/403407).

Are you aware of the tone you use in this discussion? "issues that
Debian creates" kind-of implies that we create issues on purpose.
"reject for what seems to boil down to policy reasons" implies that you
consider that what our policy might be should probably be ignored if it
fixed your problem.

When you say things like:


I don't see how we (that work on RubyGems) could possibly have ever
cared if you're not subscribed to the mailing list where you would
raise those concerns nor have you filed any bugs with any of these
concerns.

We certainly can't cooperate when you don't bother to raise any issues
in the places we're looking for them.

There was attempts (by me and others) to try to improve the situation.
Given how the rubygems tend to see the problem, I've given up, because
it's better for my mental health not to engage into discussions with
poisonous people that kill all the fun.

Not taking advantage of rubygems/defaults/operating_system is
especially odd to me as it would allow upgrades of RubyGems to
continue to work while maintaining Debian's customizations. Last I
checked the only changes made to RubyGems by Debian could be
encapsulated in this one file.

When did you last check? You didn't know about ruby-full/ruby1.9.1-full,
so I assume that must have been a long time ago.

Maybe you get so much sarcasm and nasty comments because people are
genuinely frustrated with what Debian provides by default. Maybe
installing ruby-full by default instead of the minimal ruby will
reduce your frustrations.

Well, people are also frustrated the other way around, because they are
required by some ruby developers to use rubygems instead of apt-get,
which they can use for all other scripting languages out there.

Oftentimes people are following instructions they found on the web
that were written for non-Debian/Ubuntu. On OS X, BSD, and most other
Linux versions those instructions will work without modification, but
since Debian is subtly different they end up coming here and we end up
answering the same questions over and over, which will inevitably lead
to us making sarcastic, nasty comments.

From maintaining RubyGems I've learned that maintaining a large,
popular open-source library requires a thick skin and the ability to
say "yeah, what I'm doing is not what people want" sometimes.

I actually think that the Rubygems situation in Debian is "OK". I don't
see how changing the way the packages are split would improve the
situation. Could you point to specific problems that people have? I'm
aware of two problems:
- the location of installed gems in Debian (in /var instead of /usr),
but that is dictated by policy. I *personally* would have preferred to
follow what rubygems does, but I was not directly in charge of that
decision.
- the fact that, when you try to install a gem, you might need to
install some other packages that are required to build that specific
gem (packages containing header files, compiler, etc). What is
currently done is that installing rubygems suggests (in the package
manager sense) to install the ruby header files, and a
"build-essential" package that depends on gcc, g++, etc. I can't see
what else we could do, given that:
+ some people might want to install only pure-ruby gems, so requiring
them to install a compiler and header files when installing rubygems
would be annoying.
+ we can't guess in advance which other header files will be needed by
the user (= the user installs rubygems just to install the
"ruby-foo" gem, that requires the headers for "libfoo" to be installed).
We provide tools in Debian that allow the user to know
which package contains a specific file. Of course we can't just
require the installation of all the packages containing header
files in Debian.

Are you aware of other issues?

Note that our position is rather accurately described in
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

We currently don't have any real problem with rubygems itself. Most of
our problems are caused by gem developers (those developing libraries,
not those developing rubygems itself) that ship libraries as .gem only
(so we need to repackage the source as a .tgz), or that ship code that
uses "require 'rubygems'", that we have to patch out before installing
with setup.rb. However, that recommended practice is changing slowing in
the good direction, which is great.

 

[Lucas Nussbaum]

Lucas: Thanks for maintaining the Ruby package in Ubuntu!

Might I suggest that the package called "ruby" install the standard
ruby, with everything? This would reduce confusion (and disapproving
comments) very much.

If you really think there is big demand for minimal ruby installs, go
ahead and have a ruby-minimal package, too. But you should know that
many people, especially newbies, are mislead by calling something "ruby"
which is actually "partial-ruby".

Which parts of ruby which are currently split out would you like to see
installed when the user installs ruby? For example, ruby ships a ruby
emacs mode. Installing that would require adding a dependency on emacs,
which doesn't sound reasonable.

Anyway, I've just added the following packages to the list of packages
that are "suggested" when someone installs ruby: irb, rdoc, ri,
libopenssl-ruby, ruby-dev.
That doesn't mean that they are installed automatically when the user
installs "ruby", but the package manager will suggest to install those
packages too.

 

[Lucas Nussbaum]

I agree, Lucas, thank for maintaining the package. I understand you're
trying to hit a very elusive target, and often probably working from a
poor set of requirements as far as what we, the users, want.

I always wanted a current package of Ruby with rubygems installed, the
drivers for Postgres and MySQL, SSL support, and libxml2 and Nokogiri.
That would give me the ability to process XML and HTML, talk to the
two primary DBs I've used over the last five years, talk to secured
services on the internet, etc., as soon as the install finished. As
is, I've always had to do those things before I could start to use
Ruby on a box in our enterprise.

Isn't that available if you apt-get install ruby rubygems libpgsql-ruby
libmysql-ruby libopenssl-ruby libxml-ruby libnokogiri-ruby?

I hope you understand that it is not reasonable to expect this to be
part of the default Debian install, or even to expect that installing
"ruby" would install "libpgsql-ruby libmysql-ruby libopenssl-ruby
libxml-ruby libnokogiri-ruby" too.

 

[Ryan Davis]

Which parts of ruby which are currently split out would you like to = see
installed when the user installs ruby? For example, ruby ships a ruby
emacs mode. Installing that would require adding a dependency on = emacs,
which doesn't sound reasonable.

That's a bullshit rationalization. All the other platforms install that =
file just fine. None of the installs fail if emacs isn't available.

Install everything. Make `ruby` work exactly as it works everywhere =
else. Anything less is a disservice to your own users.

 

[Lucas Nussbaum]

That's a bullshit rationalization.

See why I don't want to discuss this? ;-)

 

[botp]

See why I don't want to discuss this? ;-)

i am w Lucas here.
As to distros, i prefer debian/ubuntu when it comes to ruby. At least
they (deb) are least crappy when it comes to breakage.
Of course, if you want to have full control (specially in prodxn), i
install by source, and only what i need (not all).
Those who want all, there's a one-click i think, or anybody can just
script all those....

just my 2cents
kind regards -botp

ps: as for nubiness, .. who says developing is easy, yes ruby is, but... ;-)

 

[Nick Brown]

Which parts of ruby which are currently split out would you like to see
installed when the user installs ruby? For example, ruby ships a ruby
emacs mode. Installing that would require adding a dependency on emacs,
which doesn't sound reasonable.

Anyway, I've just added the following packages to the list of packages
that are "suggested" when someone installs ruby: irb, rdoc, ri,
libopenssl-ruby, ruby-dev.
That doesn't mean that they are installed automatically when the user
installs "ruby", but the package manager will suggest to install those
packages too.

Well, I don't know about emacs... I don't recall ever needing to install
emacs before installing ruby even from source, but on the other hand,
disk space and bandwidth are so cheap these days I wouldn't care one way
or the other.

But just yesterday I was trying to install mechanize (via rubygems) on
my 9.10 system, and it kept failing because 'net/https' was missing. And
I was scratching my head wonder why the heck a core piece of ruby like
that wouldn't be there... I thought perhaps my disk was going dead on
me... I eventually figured out what was up after some searching of the
net, but I think this illustrates the sort of confusion that can arise.

The easiest way to solve this problem would be to rename "ruby" to
"ruby-core" or something, then rename "ruby-full" to "ruby". This would
allow the few who want partial ruby installs to still do so, but the
great masses of users (and hosting providers!) who expect the package
called "ruby" to be all of ruby will be spared confusion and
frustration.

Also: don't let the unfriendly tone one often encounters on the internet
get ya down. The medium itself seems to encourage that sort of thing...
Your work IS appreciated! Keep in mind that it is Debian policy, not you
personally, that seems to be the true target of the frustrations.

 

[Brian Candler]

Which parts of ruby which are currently split out would you like to see

installed when the user installs ruby?

For me, the biggest surprise was discovering net/https.rb was missing
entirely, and wondering why on earth part of the ruby 'standard library'
had vanished. Eventually I found it had been separated out into
libopenssl-ruby.

It's also confusing that irb, ri, rdoc are missing by default.

I understand the logic, kind of. Maybe someone wants to build a tiny
system with ruby but without openssl (*).

Obviously it's not easy to know where to draw the line (should
installing ruby force installation of tcl/tk?), but I think the majority
of users are going to want net/https, readline and irb, and be surprised
if they are missing. There are few systems which won't have the openssl
and readline dependencies already present.

So I would also vote that 'ruby' be a meta-package to pull in the
complete set.

Regards,

Brian.

(*) A similar split exists in openwrt, which is explicitly targeted at
tiny systems. Indeed, they fragment it more so that you don't have to
install yaml or rexml if you don't want them.

 

[Lucas Nussbaum]

Well, I don't know about emacs... I don't recall ever needing to install
emacs before installing ruby even from source, but on the other hand,
disk space and bandwidth are so cheap these days I wouldn't care one way
or the other.

In Debian, we do not ship software without appropriately describing what
other packages are required (as dependencies) to use it. ruby1.8-elisp
is a separate package that depends on emacs, so that is fine. But if we
wanted to ship the content of ruby1.8-elisp inside an hypothetical
full-featured ruby package, the right thing to do would be to depend on
emacs. This could become an interesting issue on some of the
architecture debian supports.

But just yesterday I was trying to install mechanize (via rubygems) on
my 9.10 system, and it kept failing because 'net/https' was missing. And
I was scratching my head wonder why the heck a core piece of ruby like
that wouldn't be there... I thought perhaps my disk was going dead on
me... I eventually figured out what was up after some searching of the
net, but I think this illustrates the sort of confusion that can arise.

OpenSSL doesn't have a lot of fans, because of its licence that prevents
it from being linked to GPL software. Yes, it could be possible to ship
openssl.so and readline.so in the same package, but then it would be
harder to argue that Debian does enough to protect the linking of
readline (GPLv2) with openssl. The situation would be much simpler if
Ruby switched to GNU TLS, for example.

The easiest way to solve this problem would be to rename "ruby" to
"ruby-core" or something, then rename "ruby-full" to "ruby". This would
allow the few who want partial ruby installs to still do so, but the
great masses of users (and hosting providers!) who expect the package
called "ruby" to be all of ruby will be spared confusion and
frustration.

I really think that this problem is a minor one, and not worth all the
noise around it. I'll see with the other maintainers if there's a way we
can improve the situation slightly. But the licensing issues involved
make me fear that it is unlikely.

Also: don't let the unfriendly tone one often encounters on the internet
get ya down. The medium itself seems to encourage that sort of thing...

That's not a reason to consider it acceptable.

 

[Austin Ziegler]

OpenSSL doesn't have a lot of fans, because of its licence that prevents
it from being linked to GPL software. Yes, it could be possible to ship
openssl.so and readline.so in the same package, but then it would be
harder to argue that Debian does enough to protect the linking of
readline (GPLv2) with openssl. The situation would be much simpler if
Ruby switched to GNU TLS, for example.

Your first sentence is incorrect; OpenSSL is both better known and
more widely used in the real world than GNU TLS is likely to ever be.
GNU TLS is preferred by people who have subscribed to the GNU
philosophy, which doesn't include everyone in the Ruby world, and
those of us who prefer OpenSSL see GNU TLS as a zany outlier created
by people who have nothing better to do with their time than to worry
about the attribution clause (I believe that's the part that makes GNU
software incompatible with OpenSSL licensing, since GNU believes that
attribution isn't necessary).

That said, if someone were to make an SSL/TLS layer for Ruby that
could reasonably replace the OpenSSL namespace and that both "require
'openssl'" and "require 'gnutls'" would satisfy, then I think we'd see
traction. Since this is apparently a problem for people who prefer GNU
TLS, I suggest that it is in their interest to do so.

-austin
--=20
Austin Ziegler =95 (e-mail address removed) =95 (e-mail address removed)
http://www.halostatue.ca/ =95 http://twitter.com/halostatue

 

[James Edward Gray II]

But just yesterday I was trying to install mechanize (via rubygems) on=20=

my 9.10 system, and it kept failing because 'net/https' was missing. = And=20
I was scratching my head wonder why the heck a core piece of ruby like=20=

that wouldn't be there...

I completely agree that the split sucks. We run a Ruby service that =
requires our users to install a simple script on their servers. It does =
use net/https to communicate, so about 80% of our support issues on =
Debian systems are us explaining to users how to finish their Ruby =
install.

In my opinion, the problem is that the Debian maintainers have changed =
what it means to install Ruby. That's not OK to me, because it's not =
their call to make. The Ruby core team gets to decide what it means to =
install Ruby. All of the standard libraries are meant to be installed =
so you can count on having them. By changing that decision, Debian has =
made it so you can't count on having them and that changes the rules of =
what you can do with Ruby.

The easiest way to solve this problem would be to rename "ruby" to=20
"ruby-core" or something, then rename "ruby-full" to "ruby". This = would=20
allow the few who want partial ruby installs to still do so, but the=20=

great masses of users (and hosting providers!) who expect the package=20=

called "ruby" to be all of ruby will be spared confusion and=20
frustration.

I completely agree. It's fine for Debian to offer lighter installs, but =
installing Ruby should mean I get Ruby as it was meant to be. That has =
to be the default to be correct, in my opinion.

James Edward Gray II

 

[Brian Candler]

OpenSSL doesn't have a lot of fans

<wikipedia>Citation Needed</wikipedia>

(give me BSD-licensed code any day)