Forum: Ruby how to make installing Ruby easier for amateurs

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tom C. (Guest)
on 2008-12-22 08:25
(Received via mailing list)
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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Saji N. Hameed (Guest)
on 2008-12-22 09:21
(Received via mailing list)
Hi Tom,

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

saji

* Tom C. <removed_email_address@domain.invalid> [2008-12-22 15:15:31 +0900]:

> 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
Bill K. (Guest)
on 2008-12-22 09:34
(Received via mailing list)
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
M. Edward (Ed) Borasky (Guest)
on 2008-12-22 10:03
(Received via mailing list)
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(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.
James B. (Guest)
on 2008-12-22 10:14
(Received via mailing list)
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/maste...

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
Robert H. (Guest)
on 2008-12-22 12:14
> 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.
Ezra Z. (Guest)
on 2008-12-22 19:16
(Received via mailing list)
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/maste...


  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
Chad W. (Guest)
on 2008-12-22 22:52
(Received via mailing list)
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/a58...

I had incorrectly assumed this was the default...

-- Chad
Aníbal Rojas (Guest)
on 2008-12-23 15:00
(Received via mailing list)
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
Jörg W Mittag (Guest)
on 2008-12-24 00:10
(Received via mailing list)
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
Tom C. (Guest)
on 2008-12-24 04:56
(Received via mailing list)
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)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Justin C. (Guest)
on 2008-12-24 07:56
(Received via mailing list)
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
Florian G. (Guest)
on 2008-12-26 10:35
(Received via mailing list)
-----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-----
Dave B. (Guest)
on 2008-12-26 14:04
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
Michael L. (Guest)
on 2008-12-26 18:02
(Received via mailing list)
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. ;)

> /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
James B. (Guest)
on 2008-12-26 20:10
(Received via mailing list)
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
M. Edward (Ed) Borasky (Guest)
on 2008-12-26 23:33
(Received via mailing list)
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(P), WOM

I've never met a happy clam. In fact, most of them were pretty steamed.
Saji N Hameed (Guest)
on 2008-12-28 01:50
(Received via mailing list)
> > 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
Shot (Piotr S.) (Guest)
on 2008-12-28 19:15
(Received via mailing list)
James B.:

> http://github.com/thewoolleyman/cinabox/tree/maste...

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
Shot (Piotr S.) (Guest)
on 2008-12-28 19:51
(Received via mailing list)
Ezra Z.:

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

Are you sure? ./configure scripts for all of ruby-1.8.6-p287,
ruby-1.8.7-p72 and ruby-1.9.1-preview2 say that --enable-pthread
is an optional feature. Both 1.8 versions sport this snippet:

# Check whether --enable-pthread was given.
if test "${enable_pthread+set}" = set; then
  enableval=$enable_pthread; enable_pthread=$enableval
else
  enable_pthread=no
fi

…and both their ChangeLog files mention that the default
for --enable-pthread was changed to ‘no’ in November 2003.

1.9’s configure does indeed sport

# Check whether --enable-pthread was given.
if test "${enable_pthread+set}" = set; then
  enableval=$enable_pthread; enable_pthread=$enableval
else
  enable_pthread=$enable_pthread_default
fi

…and enable_pthread_default is set to yes for non-MinGW builds, so
I guess the bottom line is: for future compatibility and just to be
sure, do indeed use --disable-pthread, but make sure it’s the singular
‘--disable-pthread’, not the plural ‘--disable-pthreads’.

-- Shot
Simon K. (Guest)
on 2009-01-02 10:17
(Received via mailing list)
* James B. <removed_email_address@domain.invalid> (2008-12-26) schrieb:

> 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
This topic is locked and can not be replied to.