cannot access gems

T

Tom Cloyd

I seem to have run right into my ignorance again.

Working on Kubuntu Linux 8.04.1, I've a fresh compile of ruby 1.8.6. Irb
runs. I have installed rubygems from the adept package manager - the
install produced no errors of any kind. I've installed a number of gems,
including the marvelous webby, which I'm now trying to use it (I have
considerable experience with it). I'm not getting anywhere. To wit:

$ webby
bash: webby: command not found
$


On a hunch, I did this:

irb(main):001:0> require 'rubygems'
LoadError: no such file to load -- rubygems
from (irb):1:in `require'
from (irb):1
irb(main):002:0> require 'webby'
LoadError: no such file to load -- webby
from (irb):2:in `require'
from (irb):2
irb(main):003:0> require 'activerecord'
LoadError: no such file to load -- activerecord
from (irb):3:in `require'
from (irb):3
irb(main):004:0>

I don't understand what's happening. Is this a path problem? If so, how
do I fix it? I've change my path before, so that's not an issue. I just
don't know what is needed here, if anything.

Finally, if one needs to modify the path, manually, after any of these
things I've just done (installation of ruby, rubygems, and a bunch of
gems), why isn't that stated somewhere so perpetual amateurs like me can
get a clue? I'm not born knowing this stuff.

I'd be really grateful for any help offered.

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
S

Stefano Crocco

Alle Thursday 18 September 2008, Tom Cloyd ha scritto:
I've a fresh compile of ruby 1.8.6

This is the issue. The ruby you compiled is in a different location than the
one installed by the package manager. I don't use Kubntu, but I guess the one
installed using the package manager is in /usr, while the one you installed
manually is in /usr/local (that is the predefined path where the configure
script wants to install it, of course you can have changed it). When you
install rubygems using the package manager, the files are put somewhere in the
/usr/lib/ruby/ directory. The ruby you installed manually (which, I guess,
comes before the other in your PATH) expects to find its libraries in
/usr/local/lib/ruby, but rubygems hasn't been installed there.

I can think of two ways you can take:
1) manually install rubygems using your custom install of ruby. This should be
quite easy to do. This is the easiest and cleanest option.
2) remove the ruby you installed manually, then reinstall it passing the --
prefix=/usr option to configure. This will overwrite the version of ruby
installed by the package manager, but allow you to use gems and other ruby
libraries installed with it. This is a very messy solution, and you shouldn't
use it unless you have a reason not to use option 1.

I hope this helps

Stefano
 
T

Tom Cloyd

Stefano said:
Alle Thursday 18 September 2008, Tom Cloyd ha scritto:


This is the issue. The ruby you compiled is in a different location than the
one installed by the package manager. I don't use Kubntu, but I guess the one
installed using the package manager is in /usr, while the one you installed
manually is in /usr/local (that is the predefined path where the configure
script wants to install it, of course you can have changed it). When you
install rubygems using the package manager, the files are put somewhere in the
/usr/lib/ruby/ directory. The ruby you installed manually (which, I guess,
comes before the other in your PATH) expects to find its libraries in
/usr/local/lib/ruby, but rubygems hasn't been installed there.

I can think of two ways you can take:
1) manually install rubygems using your custom install of ruby. This should be
quite easy to do. This is the easiest and cleanest option.
2) remove the ruby you installed manually, then reinstall it passing the --
prefix=/usr option to configure. This will overwrite the version of ruby
installed by the package manager, but allow you to use gems and other ruby
libraries installed with it. This is a very messy solution, and you shouldn't
use it unless you have a reason not to use option 1.

I hope this helps

Stefano
Arrrgh! THIS makes tons of sense.

I don't know much about this, but why don't these installs establish and
reference symlinks. I.e., ruby gets installed and established a symlink
which anything can access to find it, and likewise with rubygems. That
would keep this sort of crap from happening. This mess is the result of
someone who should know better not thinking things through. For compiled
ruby to go one place and package manager ruby another??? This is a
thoughtful solution to anything at all? The guy behind this surely has a
career in investment banking waiting for him somewhere.

I compiled my ruby from source because I was having some problems with
the package manager version. But then rubygems wouldn't install. Kept
insisting that some libraries which WERE there were not. An expert I had
look at the mess couldn't make sense of it. I then installed rubygems
from the package manager. No problems. Except ruby cannot find the gems.

I will try try to use your idea to fix this mess when I have a little
more time this evening.

Thanks so much for your thoughts.

Tom

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
M

Marc Heiler

I don't know much about this, but why don't these installs establish and
reference symlinks.

Because UNIX tradition means that often things grow chaotically up to
the point where it needs to be fixed. But if it does not need to be
fixed yet, it will continue that way.

That is the power of UNIX design - grow and grow and grow.
Never think before you grow. Thinking delays growing.

Bad design can be fixed later - is a mantra. That not many fix it later,
because it would be a lot of work, is another issue ...
ruby gets installed and established a symlink
which anything can access to find it, and likewise with rubygems.

But you are only applying a cosmetic surface to the underlying problem
:)
The distribution will probably demand of you to "keep" to its way.

I remember the debian "philosophy" applied to ruby and splitting the
packages in many individual yet arbitrary components which means it is
in a way sometimes crippled. I remember an old plea from python devs
to stop doing this, as users who install python via package manager
(and more importantly the devs who code something) cannot rely that
all the "required" things in python are actually there. I.e. if one
went and compiled python from source he would have less trouble.
This mess is the result of someone who should know better not
thinking things through.

Typical UNIX evolution. Things like Udev or Fontconfig XML files was the
result (not to forget the many different config file formats)
For compiled ruby to go one place and package manager ruby another???

This is the old design principle in Unix - if you can make it
complicated, why make it simple? Your package manager by default will
probably dominate the /usr hierarchy whereas your self compiled programs
should be default populate /usr/local (unless you have given --prefix).
Some distributions think that is not enough and populate /opt for
reasons unknown to mankind, and almost no distribution is applying
AppDirs/PackageDirs (what belongs to a program, belongs to the same
directory).

But wait a second! If you already decided to go on your own, i.e.
compile ruby from source, why not compile it into a specific directory?
I compile into /Programs/Ruby/Version and symlinks will then be used.
There may be nicer approaches, the best one would be to work without any
symlinks - but it worked for me since a long time and I like it. It is
simple and easy and I dont have the time nore knowledge to try something
more "beautifully" for now.

The unix way is a big mess and will never be fixed due to legacy
reasons. After all these years applications which you compile from
source will behave differently - i.e. not everyone uses GNU
autoconfigure, not everyone honours --prefix or some other important
directives etc...
The guy behind this surely has a career in investment banking
waiting for him somewhere.

The power of UNIX, as long as it works, it's fine. And the more
important
a piece of software is, the more annoying these guys are ;)
But it was more historic growth. Unix is a patchwork, it was never
designed with a grand vision in place. And Linus, as smart as he may be
and as brilliant the work he can pull off with the kernel and git, is
restricted to exactly this - the rest does not interest him that much.

And modular xorg was modern about 50 years ago...
I compiled my ruby from source because I was having some problems with
the package manager version.

Doesn't it start all so often exactly like that :)
But then rubygems wouldn't install. Kept insisting that
some libraries which WERE there were not. An expert I
had look at the mess couldn't make sense of it.
I then installed rubygems from the package manager.
No problems. Except ruby cannot find the gems.

Well, all I know is that i think the whole rubygems situation should be
rethought. I compile rubygems from source but it all seems to bring up
stupid and wrong dependencies. Requires "rubyforge", "hoe" and loads of
others. Rake refuses to compile it. If i copy setup.rb though and go via
the setup.rb route, THE INSTALLATION WORKS NICELY.

Myself, I dont need rubygems because I keep track of all the packages on
my own (as said, it is a lot of work in total, but when a version
changes, all I have to do is change a single line in my "database" and I
can compile it.)

I wish you the best luck to solve your problem!
Maybe it is better to stick to your package manager. I never managed and
I have entirely given up about it, but I often regret that I invest time
into something others get for "free" (provided that they learned about
it in the first place. I found package managers so insanely boring that
I am too lazy to learn and read boring man pages until I am "expert")
 
T

Tom Cloyd

Marc said:
Because UNIX tradition means that often things grow chaotically up to
the point where it needs to be fixed. But if it does not need to be
fixed yet, it will continue that way.

That is the power of UNIX design - grow and grow and grow.
Never think before you grow. Thinking delays growing.

Bad design can be fixed later - is a mantra. That not many fix it later,
because it would be a lot of work, is another issue ...



But you are only applying a cosmetic surface to the underlying problem
:)
The distribution will probably demand of you to "keep" to its way.

I remember the debian "philosophy" applied to ruby and splitting the
packages in many individual yet arbitrary components which means it is
in a way sometimes crippled. I remember an old plea from python devs
to stop doing this, as users who install python via package manager
(and more importantly the devs who code something) cannot rely that
all the "required" things in python are actually there. I.e. if one
went and compiled python from source he would have less trouble.



Typical UNIX evolution. Things like Udev or Fontconfig XML files was the
result (not to forget the many different config file formats)



This is the old design principle in Unix - if you can make it
complicated, why make it simple? Your package manager by default will
probably dominate the /usr hierarchy whereas your self compiled programs
should be default populate /usr/local (unless you have given --prefix).
Some distributions think that is not enough and populate /opt for
reasons unknown to mankind, and almost no distribution is applying
AppDirs/PackageDirs (what belongs to a program, belongs to the same
directory).

But wait a second! If you already decided to go on your own, i.e.
compile ruby from source, why not compile it into a specific directory?
I compile into /Programs/Ruby/Version and symlinks will then be used.
There may be nicer approaches, the best one would be to work without any
symlinks - but it worked for me since a long time and I like it. It is
simple and easy and I dont have the time nore knowledge to try something
more "beautifully" for now.

The unix way is a big mess and will never be fixed due to legacy
reasons. After all these years applications which you compile from
source will behave differently - i.e. not everyone uses GNU
autoconfigure, not everyone honours --prefix or some other important
directives etc...



The power of UNIX, as long as it works, it's fine. And the more
important
a piece of software is, the more annoying these guys are ;)
But it was more historic growth. Unix is a patchwork, it was never
designed with a grand vision in place. And Linus, as smart as he may be
and as brilliant the work he can pull off with the kernel and git, is
restricted to exactly this - the rest does not interest him that much.

And modular xorg was modern about 50 years ago...



Doesn't it start all so often exactly like that :)



Well, all I know is that i think the whole rubygems situation should be
rethought. I compile rubygems from source but it all seems to bring up
stupid and wrong dependencies. Requires "rubyforge", "hoe" and loads of
others. Rake refuses to compile it. If i copy setup.rb though and go via
the setup.rb route, THE INSTALLATION WORKS NICELY.

Myself, I dont need rubygems because I keep track of all the packages on
my own (as said, it is a lot of work in total, but when a version
changes, all I have to do is change a single line in my "database" and I
can compile it.)

I wish you the best luck to solve your problem!
Maybe it is better to stick to your package manager. I never managed and
I have entirely given up about it, but I often regret that I invest time
into something others get for "free" (provided that they learned about
it in the first place. I found package managers so insanely boring that
I am too lazy to learn and read boring man pages until I am "expert")
Marc -

Wow! Thanks for validation, as we say in my trade.

I'm VERY committed to Kubuntu Linux, after converting from WinXP earlier
this year. So many things to like. BUT I still vividly recall the first
time installed a program and watched it disappear with a trace. Not in
the launch menu. Not on the desktop. It took me hours to find out that
sometimes they get put...uh...now where was it? Unless it goes here, or
maybe there. I'm still incredulous about this crap. Just plain dumb.

But then there's a lot of that because there are lost of people in the
Linux world with what I call "secret knowledge" - defined as that stuff
which, though I spend DAYS working through Linux, Ruby, HTML, CSS and
god knows what else problems, I never seem to learn. Like where DO
installed programs go?

And thanks for validating my concerns about Rubygems. Why is this thing,
nice as it is, such a ... (uh "rhymes with witch") to install?

All I can say is that more people ought to be yelling. Just because
we're grateful for the wonder that is ruby (and other, associated
wonders) - and I certainly am - doesn't mean that it's acceptable that
how to compile it is such a mystery that it actually makes sense for
"Compiling Ruby, RubyGems and Rails on Ubuntu" to be a blog entry at the
FiveRuns website -
http://blog.fiveruns.com/2008/3/3/compiling-ruby-rubygems-and-rails-on-ubuntu/comments/5614.

It's a very nice entry, but why in blazes isn't it at the ruby-lang
website? And one like for the other major OS's, as well? Does the ruby
community (not to mention the Ubuntu, etc., communities) want broader
acceptance or not? If so, then get this basic information out where we
can find it. I'd be utterly dead in the water without Google and the
enormous mercies of this list.

Well, I still don't have a functioning rubygems. Or rather, I do, but it
cannot be found by my also-functional ruby install. Gotta go wrestle
them alligators.

t.

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< (e-mail address removed) >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
R

Rick DeNatale

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

Wow! Thanks for validation, as we say in my trade.

I'm VERY committed to Kubuntu Linux, after converting from WinXP earlier
this year. So many things to like. BUT I still vividly recall the first time
installed a program and watched it disappear with a trace. Not in the launch
menu. Not on the desktop. It took me hours to find out that sometimes they
get put...uh...now where was it? Unless it goes here, or maybe there. I'm
still incredulous about this crap. Just plain dumb.

But then there's a lot of that because there are lost of people in the
Linux world with what I call "secret knowledge" - defined as that stuff
which, though I spend DAYS working through Linux, Ruby, HTML, CSS and god
knows what else problems, I never seem to learn. Like where DO installed
programs go?


The biggest secret is knowing how to do good google searches. said:
And thanks for validating my concerns about Rubygems. Why is this thing,
nice as it is, such a ... (uh "rhymes with witch") to install?

All I can say is that more people ought to be yelling. Just because we're
grateful for the wonder that is ruby (and other, associated wonders) - and I
certainly am - doesn't mean that it's acceptable that how to compile it is
such a mystery that it actually makes sense for "Compiling Ruby, RubyGems
and Rails on Ubuntu" to be a blog entry at the FiveRuns website -
http://blog.fiveruns.com/2008/3/3/compiling-ruby-rubygems-and-rails-on-ubuntu/comments/5614
.

It's a very nice entry, but why in blazes isn't it at the ruby-lang
website? And one like for the other major OS's, as well? Does the ruby
community (not to mention the Ubuntu, etc., communities) want broader
acceptance or not? If so, then get this basic information out where we can
find it. I'd be utterly dead in the water without Google and the enormous
mercies of this list.


There is lots of info on the issues with installing Ruby, rubygems, rails
etc. on Ubuntu and other Debian based distros.
Much of this is in the context of folks trying to install Rails, since 1)
it's probably the most popular reason to install ruby, and 2) it pre-reqs
ruby and ruby gems. Searches with various combinations of ubuntu/debian,
and rubygems/rails will uncover lots of such info.

http://wiki.rubyonrails.org/rails/pages/RailsOnUbuntu
https://help.ubuntu.com/community/RubyOnRails
Note that this recommends installing rubygems directly, going around
apt-get

Well, I still don't have a functioning rubygems. Or rather, I do, but it
cannot be found by my also-functional ruby install. Gotta go wrestle them
alligators.

Much as I LOVE Ubuntu, and i's parent Debian, sometimes the debian
philosophy results in problems when the Debian maintainers think they know
better than the upstream developers and make changes without understanding
the reasons for why things are done in a way that are outside of their ken.

One recent very visible example was the discovery that the debian maintainer
of ssh-keygen had fixed a 'bug', and the bug resulted in removing almost all
of the entropy from keys generated on Debian based systems, leading to a mad
scramble to recover from a rather widespread security exposure.

And rubygems is, IMHO, another example. The Debian maintainers decided that
rubygems packaging didn't really fit with debian packaging, the debian
community's 'position' on rubygems is here:

http://pkg-ruby-extras.alioth.debian.org/rubygems.html

They pretty much reject the notion that a package management system should
allow the client of a package(gem) to specify a versioned dependency in the
source code, or to have multiple versions of a package/gem which can by
dynamically required. This is a crucial feature of rubygems which allows
flexibility in deployment. Not everyone might need it but when you do you
really do.

As I said there is a lot of good in Ubuntu/Debian, and I use Ubuntu for my
server, although I've moved on to using a MacBook for development.

On a less technical level, using the debian packaged versions of
ruby/gems/... means that you are dependent on the maintainers to provide new
versions, and even if they do, you might need to update to a new release of
the distro to get them unless someone has done a backport.

When I first started playing with Ruby, it was on an Ubuntu system, and I
ran into these issues. I got some good advice from Andy Hunt to install
both Ruby and Rubygems from source rather than using apt-get.

That's what I recommend when asked, but that's just my advice.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,780
Messages
2,569,608
Members
45,244
Latest member
cryptotaxsoftware12

Latest Threads

Top