Recommended way to install Rubygems

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?

On Tue, Mar 16, 2010 at 5:22 AM, Leslie V.
[email protected]wrote:

I suppose because it is packaged separately (perhaps wrongly?)


Windows is a fitting punishment for those who choose it - I just wish I
didn’t have to be punished along with them.

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

On Mar 16, 2010, at 03:22, Leslie V. wrote:

So what I have tried to do is install gems by running the setup.rb program
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?

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.

(Please Cc me when replying, I don’t follow [email protected] closely enough to
notice replies)

On 18/03/10 at 05:43 +0900, Eric H. wrote:

file-find (0.3.4) sys-admin (1.5.2) $ irb1.9.1 irb(main):001:0>
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.

On Mar 17, 2010, at 14:32, Lucas N. wrote:

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

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

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

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.

On 18/03/10 at 13:36 +0900, Nick B. wrote:

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.

On 18/03/10 at 10:31 +0900, Eric H. wrote:

Unfortunately I end up having to handle most of the issues that Debian
for what seems to boil down to policy reasons (Neil W.'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.

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.

On 18/03/10 at 16:43 +0900, gf wrote:

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.

On Mar 18, 2010, at 00:47 , Lucas N. wrote:

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.

On Thu, Mar 18, 2010 at 5:27 PM, Lucas N.
[email protected] wrote:

See why I don’t want to discuss this? :wink:

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

On 18/03/10 at 17:10 +0900, Ryan D. wrote:

On Mar 18, 2010, at 00:47 , Lucas N. wrote:

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.

See why I don’t want to discuss this? :wink:

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.

On 18/03/10 at 23:05 +0900, Nick B. wrote:

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.

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.

On Thu, Mar 18, 2010 at 10:21 AM, Lucas N.
[email protected] wrote:

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

On Mar 18, 2010, at 9:05 AM, Nick B. wrote:

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 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
“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 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 G. II

Lucas N. wrote:

OpenSSL doesn’t have a lot of fans

Citation Needed

(give me BSD-licensed code any day)

Lucas N. wrote:

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs