How to make installing Ruby easier for amateurs


#1

Greetings!

As an amateur, and intermittent, programmer, I often run right off the
edge of what I know. Sometimes this seems utterly needless. Here’s one
such case:

In the past year I’ve switched from WindowsXP to Kubuntu Linux. I’ve had
to reload the operating system maybe four times, plus two more due to
acquiring a USB hard drive (now my primary drive), and now setting my up
Kubuntu to run from a flash drive. I have to reinstall Ruby each time,
of course. And…EACH TIME I RUN INTO THE SAME STUPID PROBLEM, as
exemplified by my experience yesterday:

I install Ruby 1.8 (yesterday, it was 1.8.7, of course) using either
apt-get or the Adept package manager. Then I install Rubygems with
apt-get (it’s not in Adept’s sources, apparently).

Ready to GO? You would think so. Naively, I always do. But it’s not to
be. Now the madness starts, and this is what I want fixed.

It turns out that Rubygems has a hidden dependency (I think I’m using
the right term, but if not, correct me). It isn’t automatically
installed, and without it, gem installation simply crashes and burns,
without useful comment. For an amateur such as me, this isn’t helpful,
to put it mildly. Here’s what happens:

~$ sudo gem install RedCloth
Building native extensions. This could take a while…
ERROR: Error installing RedCloth:
ERROR: Failed to build gem native extension.

/usr/bin/ruby1.8 extconf.rb install RedCloth
extconf.rb:1:in `require’: no such file to load – mkmf (LoadError)
from extconf.rb:1

Gem files will remain installed in /var/lib/gems/1.8/gems/RedCloth-4.1.1
for inspection.
Results logged to
/var/lib/gems/1.8/gems/RedCloth-4.1.1/ext/redcloth_scan/gem_make.out
ubuntu@ubuntu:~$

The solution? Install the ruby1.8-dev library or package or whatever the
heck it is. It’s in the Adept package manager.

I’m sure many on this list know all about this, but it’s not reasonable
to expect amateurs like to know such things, and there no sign on the
side of the road advertising the fact. It’s simply “secret knowledge”. I
hate secret knowledge.

I’ve been “had” by this problem at least 6 times. It always happens
about 5 weeks past the time I’ve forgotten about it. I DO have a full
life aside from my Ruby adventures.

So…if Rubygems needs this library or whatever, why cannot it check to
see that it’s present, and then complain if it’s not? The error msg it
does report means nothing to me at all. Personally, I think the Ruby
package from Adept should include this, but that’s another story.

Basic idea: don’t leave tiger traps lying about when you know that
children will be coming down the path.

Is this possible? Am I asking too much?

(Update: the only reason by I ran into this problem at all was that I
was reluctant to do on the flash drive OS what I do now regularly:
compile and install from source. This is the best idea of all, of
course, as documented recently by the fellow who issues the “Zen of
Ruby” blog newsletter, since it produces an executable which is about
twice as fast as that distributed by the package managers.)

t.

Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< removed_email_address@domain.invalid >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)

#2

Hi Tom,

It is likely an (K|X)Ubuntu issue than a ruby-gem issue.

saji

of course. And…EACH TIME I RUN INTO THE SAME STUPID PROBLEM, as
the right term, but if not, correct me). It isn’t automatically
extconf.rb:1:in `require’: no such file to load – mkmf (LoadError)
heck it is. It’s in the Adept package manager.
So…if Rubygems needs this library or whatever, why cannot it check to
was reluctant to do on the flash drive OS what I do now regularly:
Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< removed_email_address@domain.invalid >> (email)
<< TomCloyd.com >> (website) << sleightmind.wordpress.com >> (mental
health weblog)





Saji N. Hameed

APEC Climate Center +82 51 668 7470
National Pension Corporation Busan Building 12F
Yeonsan 2-dong, Yeonje-gu, BUSAN 611705 removed_email_address@domain.invalid
KOREA


#3

From: “Tom C.” removed_email_address@domain.invalid

[…]

extconf.rb:1:in `require’: no such file to load – mkmf (LoadError)
from extconf.rb:1

[…]

The solution? Install the ruby1.8-dev library or package or whatever the
heck it is. It’s in the Adept package manager.

This appears to be partly a manifestation of the eternal clash
between ruby vs. the Debian packaging philosophy.

It is the Debian package maintainers who carve up the Ruby
standard library into fragmented packages.

This is described as beneficial for persons attempting to
install software on systems with extremely minimal storage
resources.

On the other hand, year after year it results in confusion for
individuals who had done “apt-get install ruby” with the
expectation that this would result in a complete ruby
installation.

So there are trade-offs…

However in this case it does also sound like there may simply
be a missing dependency for rubygems on the ruby*-dev package.

If so, we should alert the Debian ruby package maintainers.

Regards,

Bill


#4

Bill K. wrote:

the heck it is. It’s in the Adept package manager.

Regards,

Bill

You also need “make”, “gcc” and sometimes other libraries / header files
to build some gems from source. Even if the whole Ruby shootin’ match is
installed, you may still get errors like this. Some of the distros, for
example Gentoo, have built many of the Ruby dependencies into their own
packaging system. So, for example, on Gentoo, you can say “emerge
rubygems” and it will install Ruby if that isn’t there. And you can say,
“emerge rails” and it will bring in rake, rubygems, activerecord, etc.


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§, WOM

I’ve never met a happy clam. In fact, most of them were pretty steamed.


#5

Forget apt-get for Ruby. Maybe one day that will work as most people
expect it should. But today is not that day.

I do not think it ever will. How many years have gone by now since the
first user had the problem with this concerning ruby on debian at least?
3 years?

Debian Users will continue to have split-up packages, and as a result
continue to have all these problems which reoccur every some months on
the list here, or on a forum somewhere else. This is a fundamental flaw
in philosophy concerning packaging on Linux boxes altogether in fact.

The only thing I do not quite understand is why debian developers do not
tell the users loudly that these problems are because of debian, and not
because of the ruby python etc… guys.


#6

Tom C. wrote:

of course. And…EACH TIME I RUN INTO THE SAME STUPID PROBLEM, as
exemplified by my experience yesterday:

I install Ruby 1.8 (yesterday, it was 1.8.7, of course) using either
apt-get or the Adept package manager. Then I install Rubygems with
apt-get (it’s not in Adept’s sources, apparently).

Ready to GO? You would think so. Naively, I always do. But it’s not to
be. Now the madness starts, and this is what I want fixed.

http://github.com/thewoolleyman/cinabox/tree/master/bootstrap_ruby.sh

Forget apt-get for Ruby. Maybe one day that will work as most people
expect it should. But today is not that day.

Big thanks to Chad W. for that script.


James B.

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff


#7

On Mon, Dec 22, 2008 at 10:06 AM, Ezra Z. removed_email_address@domain.invalid
wrote:

   If you use this script you should change line 27 to add the

–disable-pthreads flag

./configure --disable-pthreads

   This can cause a 20-100% speed up on the interpreter  as long as you

don’t need to use tk.

Thanks Ezra, committed:

http://github.com/thewoolleyman/cinabox/commit/a584281d510b03ff91261531f17a2247fe6e97df

I had incorrectly assumed this was the default…

– Chad


#8

On Dec 22, 2008, at 12:05 AM, James B. wrote:

THE SAME STUPID PROBLEM, as exemplified by my experience yesterday:
I install Ruby 1.8 (yesterday, it was 1.8.7, of course) using
either apt-get or the Adept package manager. Then I install
Rubygems with apt-get (it’s not in Adept’s sources, apparently).
Ready to GO? You would think so. Naively, I always do. But it’s not
to be. Now the madness starts, and this is what I want fixed.

http://github.com/thewoolleyman/cinabox/tree/master/bootstrap_ruby.sh

If you use this script you should change line 27 to add the --disable-
pthreads flag

./configure --disable-pthreads

This can cause a 20-100% speed up on the interpreter as long as you
don’t need to use tk.

Cheers-

Ezra Z.
removed_email_address@domain.invalid


#9

Tom,

Yes, it is frustating, to make it a little bit simple install the
package: ruby-full which should give you everything that is ruby
related. But you will still need to install build-essential to be able
to compile native dependencies if you require them.

And yes, the differences between the Ruby community and the Debian
packagers always arise, and there are good points at both side about
how to do the things.


Aníbal Rojas
http://hasmanydevelopers.com
http://rubycorner.com
http://anibal.rojas.com.ve


#10

Jörg W Mittag wrote:

continue to have all these problems which reoccur every some months on
native C extensions. Most were not created with Linux package managers
jwm

Interesting comment. I have to say that I don’t see it as a flaw in
Linux packaging either. I began this thread by objecting to “secret
knowledge” - the knowledge that Rubygems, once you install it, cannot
function with something else which it never names and which I’ve never
heard of. There’s always secret knowledge, of course, BUT, dammit, if
program X cannot do its thing without dependency Z, then I expect X to
take care of itself. I don’t expect to have to do it myself. As an
ignorant amateur, that asking too much of me.

I see LOTS of things in Ruby taking care of themselves. But…when I go
to install Ruby, it comes WITHOUT RubyGems. Does that actually make
sense to anyone at all? If RubyGems is optional, why is it more optional
than all those exotic libraries that automatically come with Ruby. I’m
FAR more likely to need RubyGems, as a learner, than some library that
parses HTML header files or whatever (just making this UP!), or messes
with obscure aspects of networks. Priorities seem misplaced here.

The other side of it is this: if Ruby isn’t going to come alive with
Rubygems (and, of course, all that IT needs to function), then it looks
like Rubygems needs to look out for itself. Otherwise, I have to it,
and I haven’t a clue (well, I sure do now, of course - but why did I
have to run off the cliff 6 times to get this sorted out?). I protest
about this because I deeply love and respect Ruby. I want to push others
to try it. I don’t want them to have some of these crazy problems I’ve
had. It doesn’t seem necessary.

So, I’m back where I started. This particular problem just needs to be
fixed. I can’t do it - I don’t know enough. I’m in favor of making
things work. How about you?

t.

Tom C., MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< removed_email_address@domain.invalid >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)

#11

Marc H. wrote:

Forget apt-get for Ruby. Maybe one day that will work as most people
expect it should. But today is not that day.
I do not think it ever will. How many years have gone by now since the
first user had the problem with this concerning ruby on debian at least?
3 years?

Debian Users will continue to have split-up packages, and as a result
continue to have all these problems which reoccur every some months on
the list here, or on a forum somewhere else. This is a fundamental flaw
in philosophy concerning packaging on Linux boxes altogether in fact.

Can you explain how this is a fundamental flaw in Linux packaging?
TeX, Emacs, Perl, PHP, Python, Java, they all share most if not all of
Ruby’s challenges: all have their own directory layouts, their own
search paths, their own library paths, their own versioning schemes,
their own package managers, their own distribution formats, multiple
different implementations, multiple different versions. Most have
native C extensions. Most were not created with Linux package managers
in mind – heck, most were created before Linux package managers even
existed.

And yet, all of them work perfectly fine. All except Ruby.

This reminds me of the guy on the freeway listening to the traffic
channel and thinking to himself: “What are they talking about, a car
driving the wrong way on the freeway? It’s not a car, it’s hundreds
of them!”

jwm


#12

Tom C. wrote:

Debian Users will continue to have split-up packages, and as a
their own package managers, their own distribution formats, multiple
of them!"
program X cannot do its thing without dependency Z, then I expect X to
misplaced here.
So, I’m back where I started. This particular problem just needs to be
fixed. I can’t do it - I don’t know enough. I’m in favor of making
things work. How about you?

t.

The next version of Ruby will/does come with RubyGems.
But how a Linux distro packages it all up is not something with the
developers of Ruby have control over (or very little, at least). One
alternative is for people to contribute packages for various systems,
but then you would have the “official” version (via your package
manager’s sources) and the external version. Plus, somebody has to
maintain all that.
Now, installing via your particular Linux distro’s packaging system is
just one way of installing Ruby. The Windows One-Click version, for
example, comes with RubyGems and a lot of other things that the regular
Ruby package does not. On the other hand, if you install straight from
source you never have to work about installing ruby-devel packages, but
then that comes with its own challenges.

-Justin


#13

Justin C. wrote:

But how a Linux distro packages it all up is not something with the
developers of Ruby have control over (or very little, at least).

Surely Ruby people should be talking to distro people, pointing out the
problems and suggesting fixes. It’s in everyone’s interest that Ruby be
easy to install.

I too have run into problems trying to install Ruby on Ubuntu. I don’t
care whose fault it is, or what the problem is, I just want it to work
first time like other packages do. Is that really too much to ask?

David


#14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Dec 24, 2008, at 3:46 AM, Tom C. wrote:

I think the problem is that Ubuntu relies on the Debian packages.
While Debian aims to be the system where an experienced user can
install exactly the installation parts he wants, Ubuntu tries to be
accessible and problem-free.

So, the packaging for Debian is perfectly fine for expert uses but
totally bad in the Ubuntu context. Thats exactly the reason why I’m
not an Ubuntu user. When it comes to usage beyond the standard
installation, it gets horrible because of the mismatch between the
ease of standard use and the true hassle of slightly more advanced use.

Regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAklUlzEACgkQyLKU2FMxSOKKxQCfcAFRl04fxL7RHJdl1zIzhFPG
N8IAoIkPvde0tyW3a7vtvyZCdJcMviVk
=O+TY
-----END PGP SIGNATURE-----


#15

On Mon, Dec 22, 2008 at 12:15 AM, Tom C. removed_email_address@domain.invalid
wrote:

or the Adept package manager. Then I install Rubygems with apt-get (it’s not
in Adept’s sources, apparently).

Adept, in my extremely limited experience, is not there yet.

sudo apt-get install synaptic

Ready to GO? You would think so. Naively, I always do. But it’s not to be.
Now the madness starts, and this is what I want fixed.

Most of this “madness” had nothing to do with Ruby and everything to
do with the decisions made by Debian and Ubuntu about how to package
Ruby.

It turns out that Rubygems has a hidden dependency (I think I’m using the
right term, but if not, correct me).

Well, it’s not hidden if you use the Debian packaging system as
designed. I don’t know the command-line interface for it, but in
Synaptic you can see a list of recommended and suggested packages that
go with any given package. In the case of Rubygems, build-essential
and ruby-dev are the dependencies you are looking for here, and both
of them are suggested.

It isn’t automatically installed, and
without it, gem installation simply crashes and burns, without useful
comment. For an amateur such as me, this isn’t helpful, to put it mildly.
Here’s what happens:

~$ sudo gem install RedCloth
Building native extensions. This could take a while…
ERROR: Error installing RedCloth:
ERROR: Failed to build gem native extension.

For a lot of gems that don’t need C compilers to be installed there
won’t be any crashing or burning. As an aside, these same gems that
need C compilers on Ubuntu may be hard to install on some other
operating systems. If you think the Ubuntu package system isn’t very
helpful, you should see the one included with Windows. :wink:

/usr/bin/ruby1.8 extconf.rb install RedCloth
extconf.rb:1:in `require’: no such file to load – mkmf (LoadError)
from extconf.rb:1

Did you try this first?

sudo apt-get install libredcloth-ruby\

So…if Rubygems needs this library or whatever, why cannot it check to see
that it’s present, and then complain if it’s not? The error msg it does
report means nothing to me at all. Personally, I think the Ruby package from
Adept should include this, but that’s another story.

Adept is just an interface to the Debian/Ubuntu package system.

You might be happier with Synaptic. It makes finding packages a cinch,
and then makes it relatively easy to discover what the “optional”
dependencies might be.

-Michael


#16

Michael L. wrote:

Adept is just an interface to the Debian/Ubuntu package system.

You might be happier with Synaptic. It makes finding packages a cinch,
and then makes it relatively easy to discover what the “optional”
dependencies might be.

+1

First thing do on new (K)ubuntu install is add synaptic, and then use
that for adding packages.


James B.

www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff


#17

Ready to GO? You would think so. Naively, I always do. But it’s not to be.
Now the madness starts, and this is what I want fixed.

Most of this “madness” had nothing to do with Ruby and everything to
do with the decisions made by Debian and Ubuntu about how to package
Ruby.

I would very much agree with this. I had been using ArchLinux for some
time and never faced any such problems. Recently I tried Ubuntu on
another
machine and the situation is quite different - you need to know some
background stuff to get rubygems installed packages working properly!

saji


#18

Dave B. wrote:

first time like other packages do. Is that really too much to ask?

David

Every distro has a collection of Ruby-specific developers / packagers,
and there are some Rubyists who are members of one or more distro
communities as well. But … I’d be extremely surprised if just “talking
to distro people” is going to have any major effect on a community as
large and as “religious” as Debian’s, and by inheritance, all those
distros that depend on the Debian repositories.

On top of that, there are three major packaging systems: RPM, Debian and
source tarballs plus scripts (Gentoo and Slackware, maybe others). The
organization that defined the “Linux Standard Base” now has a subgroup
that’s concerned with unifying the whole package management area. It’s
not just Ruby, by the way … distros have to also define the way they
interact with the packaging subsystems and repositories of Perl, Python,
R, TeX/LaTex, Tcl/Tk and some others I know little about.

Of all the ones I’ve used, Gentoo’s seems to be the easiest to work with
as far as Ruby is concerned. For one thing, all the development tools –
gcc, make, automake, kernel source, etc. – are part of the base
install. You don’t have to install them if you want to do something more
involved than running existing applications. And second, building from
source with scripts means it’s easier to put a wrapper on a Ruby gem, or
a CPAN package / bundle, etc. and put the Ruby or Perl or Python
dependencies into the distro’s dependency structure. And third, when
they build from source, they install all the headers – there’s no
separate “-devel” package you need to install!


M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC§, WOM

I’ve never met a happy clam. In fact, most of them were pretty steamed.


#19

James B.:

http://github.com/thewoolleyman/cinabox/tree/master/bootstrap_ruby.sh

Thanks for sharing! I build all my Ruby versions by hand, and
I wasn’t aware about the trick with commenting out the Win stuff.

I’m thinking about a similar script, but one that would a) enable the
installation of Ruby 1.8.6, Ruby 1.8.7, Ruby 1.9.1 and JRuby 1.1.6 in
~/opt and with the binaries distinguished by name, and b) verify the
MD5 hashes of the tarballs (just in case).

As for the general Debian vs. RubyGems discussion, being both a Ruby
developer and a sysadmin I actually fully understand both sides
– and don’t think there’s a sane solution at the moment.

As for the rubygems package’s relation with libruby-dev, it currently
suggests it. I’m partial of the sentiment that rubygems should keep
suggesting libruby-dev in Debian, but actually recommend it (and
build-essentials) in Ubuntu (and so this way both these packages
would get auto-installed alongside rubygems on Ubuntu, but not on
Debian).

The relevant issues are http://bugs.debian.org/466189
and https://bugs.launchpad.net/ubuntu/+bug/244742

– Shot


#20

First thing do on new (K)ubuntu install is add synaptic, and then use
that for adding packages.

Is there no Aptitude on Ubuntu?

mfg, simon … l