Ruby under Cygwin problems

Whatever Ruby module I want to install under Cygwin I always get the same
error: ruby: No such file to load -- ubygems (LoadError)

I've tried install rubygem, rubyfcgi etc. After "ruby config.rb config" or
"ruby config.rb install" I get error: "ruby: No such file to load --
ubygems (LoadError)" It looks strange. I am using last cygwin installation
with ruby 1.8.2 ()ruby 1.8.2 (2004-12-25) [i386-cygwin])

···

--
JZ

JZ <usenet@zabiello.com> writes:

Whatever Ruby module I want to install under Cygwin I always get the
same error: ruby: No such file to load -- ubygems (LoadError)

Sounds like someone is using `-rubygems' instead of `-rrubygems'.
(Sorry for stating the obvious.)

···

--
Daniel Brockman <daniel@brockman.se>

Except that in a RubyGems installation, there's an ubygems.rb that
simply loads rubygems.rb.

The problem, I suspect, is that JZ has both the cygwin Ruby and the
One-Click Ruby installed. The native Windows Ruby includes RubyGems.
The cygwin Ruby does not.

-austin

···

On 7/4/05, Daniel Brockman <daniel@brockman.se> wrote:

JZ <usenet@zabiello.com> writes:
> Whatever Ruby module I want to install under Cygwin I always get the
> same error: ruby: No such file to load -- ubygems (LoadError)
Sounds like someone is using `-rubygems' instead of `-rrubygems'.
(Sorry for stating the obvious.)

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

Hello Daniel,

JZ <usenet@zabiello.com> writes:

Whatever Ruby module I want to install under Cygwin I always get the
same error: ruby: No such file to load -- ubygems (LoadError)

Sounds like someone is using `-rubygems' instead of `-rrubygems'.
(Sorry for stating the obvious.)

No this is not the problem, it's just one more of this quick and
dirty hacks (that i don't like in ruby). To make it more readable
someone had to the great idea to write a "ubygems.rb" file that
contains only one line "require 'rubygems'". The 'ubygems.rb' is
included by default in the one-click-installer and the rubygems
package.

And setting RUBYOPT by default is IMHO another quick and dirty hack.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Lothar Scholz <mailinglists@scriptolutions.com> writes:

To make it more readable someone had to the great idea to write a
"ubygems.rb" file that contains only one line "require 'rubygems'".

I see... Sort of clever. Kind of cute.
And ultimately more confusing than useful.

···

--
Daniel Brockman <daniel@brockman.se>

Yes, I have. After unseting RUBYOPT variable I can install gem.

···

Dnia Tue, 5 Jul 2005 12:37:17 +0900, Austin Ziegler napisał(a):

The problem, I suspect, is that JZ has both the cygwin Ruby and the
One-Click Ruby installed.

--
JZ

No this is not the problem, it's just one more of this quick and dirty hacks (that i don't like in ruby).

I agree whole-heartedly that this is a silly hack. In introducing
others to Ruby I've had them complain about how unclear the -r ubygems
thing is. One of my coworkers swore he would never use rubygems
because of this, I had a hard time convincing him otherwise. Cygwin
ruby and the one-click installer should work better together, and
RUBYOPT and ubygems are the first problems to solve towards this goal,
IMHO. I think ubygems critically violates the least-surprise principle!

karlin.fox@gmail.com said:

I agree whole-heartedly that this is a silly hack. In introducing
others to Ruby I've had them complain about how unclear the -r ubygems
thing is. One of my coworkers swore he would never use rubygems
because of this, I had a hard time convincing him otherwise. Cygwin
ruby and the one-click installer should work better together, and
RUBYOPT and ubygems are the first problems to solve towards this goal,
IMHO. I think ubygems critically violates the least-surprise principle!

I personally haven't noticed any problems with this "hack" as you guys
like to call it, and having seen the issues involved with something like
RubyGems (in doing the original prototype) I think it is the best
solution.

I'd really like to hear alternatives. Keep in mind I'm not a developer on
the current RubyGems, so it's not like I'm defending any work of my own.
But I know the RubyGems developers have put a lot of hard work into it,
and to complain as you have without any suggestions for alternatives isn't
particularly constructive.

The issue is that to use libraries that are packaged as gems, you must
require 'rubygems' first. To do this as a gem user in all your scripts is
a bit of a pain, and should you want to distribute your scripts you run
into issues of people possibly not having RubyGems installed. So then
maybe you change that line to "require 'rubygems' rescue nil", which I
think is a bit worse of a hack than the RUBYOPT "hack."

Maybe a nice option would be for the One-Click Installer to prompt on
whether the user wants RUBYOPT set up with "rubygems" or not, with an
explanation of what it is for, and what it means (including what ubygems
is.) That should be the best of both worlds, eh?

Ryan

Ryan Leavengood wrote:

Maybe a nice option would be for the One-Click Installer to prompt on
whether the user wants RUBYOPT set up with "rubygems" or not, with an
explanation of what it is for, and what it means (including what ubygems
is.) That should be the best of both worlds, eh?

You can tell the One-Click Installer not to prepend "rubygems" to the RUBYOPT environment variable.

When you get to the "Choose Components" screen, the component "RubyGems Package Manager" can be unchecked to completely omit RubyGems or, alternatively, You can click on the plus to expand the subitems and just uncheck "Enable RubyGems" (this will still install RubyGems but not set RUBYOPT).

Curt

Hello Ryan,

I'd really like to hear alternatives. Keep in mind I'm not a developer on
the current RubyGems, so it's not like I'm defending any work of my own.
But I know the RubyGems developers have put a lot of hard work into it,
and to complain as you have without any suggestions for alternatives isn't
particularly constructive.

RubyGems is still a hack, or lets say it politely a prototype.
A lot of things are simply not working or implemented in a bad way. While
developing a frontend for ArachnoRuby i run into so much problems with
the core rubygems system that i think a lot of work needs to be put
into the 0.9.X series before it comes alive (bad C/S design, does not
support C-extensions, can't handle the platform indicator, can't see
install notes before trying to install a ruby gem - but additional parameters
must be passed to some libraries during the "gem install xxx" command,
no way to get list of remote specifications, braindead has_rdoc
feature from DHH, ....)

For the "require 'rubygems'" problem the best solution is easy to find
and obvious, integrate it into the ruby kernel. When done right
(fixing the previously mentioned bugs), this is an essential core
technology that should work out of the box. Until this happens
i don't have a problem with writing "require 'rubygems'" on the first
line. I wouldn't add a rescue clause as i think it's a valid option to
force a user to have rubygems installed as some of the requirements of
your library.

And -rubygems looks like an option, so explain somebody that (it's not
done in the help) that -rubygems and -rfoobar are the some and
influence each other (order of command line options). So it's not
newbie friendly and this should be the primarily goal of rubygems.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Curt Hibbs said:

You can tell the One-Click Installer not to prepend "rubygems" to the
RUBYOPT environment variable.

When you get to the "Choose Components" screen, the component "RubyGems
Package Manager" can be unchecked to completely omit RubyGems or,
alternatively, You can click on the plus to expand the subitems and just
uncheck "Enable RubyGems" (this will still install RubyGems but not set
RUBYOPT).

Cool. Then I guess the main problem is most people are not aware of this,
and they get bit by it being on by default. Again, I think this is fine,
but maybe this option needs to be made more explicit for those who don't
want it.

Ryan

Lothar Scholz <mailinglists@scriptolutions.com> writes:

i don't have a problem with writing "require 'rubygems'" on the first
line. I wouldn't add a rescue clause as i think it's a valid option to
force a user to have rubygems installed as some of the requirements of
your library.

If you decide to go this way, please make sure you also publish your
software as a gem only, so they won't even have the slightest chance
to have a look at the code and determine whether it would be
reasonable to dig it out.

Sorry,

···

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

I ran into this problem at work. I was trying to do some ruby programs to
help automate some version control stuff. I tried to convince people how
easy Ruby is, but then when I spent a few hours tracking this problem down,
I couldn't really argue that I wasn't going to run into more problems down
the road. With each gotcha, I lost more support. We now use perl for all of
our stuff. It is OK for a ruby programmer to have to deal with these
annoying issues at each major release, but these problems also effect the
end users who are not ruby programmers and not computer savvy.

I know that a lot of work and good code goes into these projects on a
volunteer basis, so I don't want to disparage the great effort, but, in my
opinion, this work would shine that much brighter if there was just a small
amount of effort put into ensuring that beginner users did not run into
basic problems during new releases and installs. Just ensuring that new
installs work on a minimum of platforms like Linux, windows, and cygwin,
would go a long way.

Imagine when someone makes the big step to try using ruby for the first
time. They install with the one click editor, use the included Scite editor,
and try one of the basic sample programs in the IRB window. They immediately
notice that every character they type shows up twice in the window.
Realizing that that isn't working they try to cut and past a small program
from the editor window to the irb window, and irb gets all confused with the
carriage returns. If they are not completely discouraged by this point they
might try to run an existing program in a cygwin shell, and get the ubygems
error. That is about as far as anyone will go in trying something new, and
we have just lost another ruby convert.

"Ryan Leavengood" <mrcode@netrox.net> wrote in message
news:44059.206.157.248.34.1120600225.squirrel@www.netrox.net...
Curt Hibbs said:

You can tell the One-Click Installer not to prepend "rubygems" to the
RUBYOPT environment variable.

When you get to the "Choose Components" screen, the component "RubyGems
Package Manager" can be unchecked to completely omit RubyGems or,
alternatively, You can click on the plus to expand the subitems and just
uncheck "Enable RubyGems" (this will still install RubyGems but not set
RUBYOPT).

Cool. Then I guess the main problem is most people are not aware of this,
and they get bit by it being on by default. Again, I think this is fine,
but maybe this option needs to be made more explicit for those who don't
want it.

Ryan

Heartily, heartily seconded. That way, if someone who works on a linux
distro like Fedora, PLD or Debian should want to package software that
uses your library, or to package your library, so that it "Just works"
for their users, they'll give up. That way nobody accidentally makes it
easy to install.

</snark>

Seriously, gems are really hard to package into an RPM. Really, really
hard. I end up un-packing them as tarballs, then patching them out to
remove the require_gem lines, require 'rubygems', and then correcting
the assumptions about the location of data files.

And before you say "... just use gems", let me point out something:

To run, say, Rails, with gems:

  1) manually install ruby
  2) manually install rubygems
  3) gem install rails

To install rails under the distro I work on:

  1) poldek -i rails

I'll let you draw your own conclusions.

Ari

···

On Wed, 2005-07-06 at 23:18 +0900, Christian Neukirchen wrote:

Lothar Scholz <mailinglists@scriptolutions.com> writes:

> i don't have a problem with writing "require 'rubygems'" on the first
> line. I wouldn't add a rescue clause as i think it's a valid option to
> force a user to have rubygems installed as some of the requirements of
> your library.

If you decide to go this way, please make sure you also publish your
software as a gem only, so they won't even have the slightest chance
to have a look at the code and determine whether it would be
reasonable to dig it out.

Hello Christian,

Lothar Scholz <mailinglists@scriptolutions.com> writes:

i don't have a problem with writing "require 'rubygems'" on the first
line. I wouldn't add a rescue clause as i think it's a valid option to
force a user to have rubygems installed as some of the requirements of
your library.

If you decide to go this way, please make sure you also publish your
software as a gem only, so they won't even have the slightest chance
to have a look at the code and determine whether it would be
reasonable to dig it out.

Sorry i don't understand your argument. If gems are not installed
you get a brief description from the remote source and if they are
installed you can simply browse the source code.

If you have a decent frontend (like my customers) for this then it
shouldn't be a problem. If not you must indeed do a "chdir" and "ls
-la".

The only problem comes when the install of a gem terminates with an
error, like not being able to compile a binary extension. But as i
pointed out before binary extensions are still a general problem for
rubygems.

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Hi --

And before you say "... just use gems", let me point out something:

To run, say, Rails, with gems:

1) manually install ruby
2) manually install rubygems
3) gem install rails

To install rails under the distro I work on:

1) poldek -i rails

Well, that's a little misleading, since the first two steps for gems
are one-time setup steps. For your poldek scenario, we could say:

   1) Format hard drive
   2) Burn or buy CD with distro on it
   3) Install distro

etc., and that would make installing Rails seems like a much more
monumental task. In any case, it wouldn't be hard to write an
installation script that took account of gems.

Also, keep in mind that Rubygems is conceived as eventually becoming
part of the Ruby core, in which case it would come with Ruby and the
manual installation would not have to happen. That's been the
"Catch-22" in many discussions of gems: the things people find
cumbersome about it are things that would disappear (mostly, perhaps
entirely after some tweaking) if gems were in the core; but until it's
in the core, people will continue to find those things cumbersome.
Hopefully Matz will break us out of the cycle by 2.0 or even earlier.

David

···

On Wed, 6 Jul 2005, Aredridel wrote:

--
David A. Black
dblack@wobblini.net

What is your _suggestion_? Does anyone have anything productive to add?

···

On 7/6/05, Aredridel <aredridel@nbtsc.org> wrote:

On Wed, 2005-07-06 at 23:18 +0900, Christian Neukirchen wrote:
> Lothar Scholz <mailinglists@scriptolutions.com> writes:
>
> > i don't have a problem with writing "require 'rubygems'" on the first
> > line. I wouldn't add a rescue clause as i think it's a valid option to
> > force a user to have rubygems installed as some of the requirements of
> > your library.
>
> If you decide to go this way, please make sure you also publish your
> software as a gem only, so they won't even have the slightest chance
> to have a look at the code and determine whether it would be
> reasonable to dig it out.

Heartily, heartily seconded. That way, if someone who works on a linux
distro like Fedora, PLD or Debian should want to package software that
uses your library, or to package your library, so that it "Just works"
for their users, they'll give up. That way nobody accidentally makes it
easy to install.

</snark>

--
Chad Fowler
http://chadfowler.com

http://rubygems.rubyforge.org (over 500,000 gems served!)

Hello Aredridel,

Lothar Scholz <mailinglists@scriptolutions.com> writes:

> i don't have a problem with writing "require 'rubygems'" on the first
> line. I wouldn't add a rescue clause as i think it's a valid option to
> force a user to have rubygems installed as some of the requirements of
> your library.

If you decide to go this way, please make sure you also publish your
software as a gem only, so they won't even have the slightest chance
to have a look at the code and determine whether it would be
reasonable to dig it out.

Heartily, heartily seconded. That way, if someone who works on a linux
distro like Fedora, PLD or Debian should want to package software that
uses your library, or to package your library, so that it "Just works"
for their users, they'll give up. That way nobody accidentally makes it
easy to install.

</snark>

Seriously, gems are really hard to package into an RPM. Really, really
hard. I end up un-packing them as tarballs, then patching them out to
remove the require_gem lines, require 'rubygems', and then correcting
the assumptions about the location of data files.

Sorry where is the problem ?

You just need to untar files into different places in the local gems
repository. As all data is in independent files under
"C:\ruby\lib\ruby\gems\1.8\gems" (on windows, don't now the
corresponding linux path) there is no problem to extract gems.

But RubyGems is a packaging and distribution framework. So it works
independent of RPM and this is a good thing. So please don't
distribute ruby gems with your Linux distribution, this sucks. If you
want to do this then offer a package and initial configuration that sets
up a local repository from there "gem install rails" fetches its gem
file.

···

On Wed, 2005-07-06 at 23:18 +0900, Christian Neukirchen wrote:

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's

Aredridel said:

Heartily, heartily seconded. That way, if someone who works on a linux
distro like Fedora, PLD or Debian should want to package software that
uses your library, or to package your library, so that it "Just works"
for their users, they'll give up. That way nobody accidentally makes it
easy to install.

I set up Ruby, RubyGems and Rails on my new Gentoo box without any
difficulty. I'm not some Linux expert either.

Seriously, gems are really hard to package into an RPM. Really, really
hard. I end up un-packing them as tarballs, then patching them out to
remove the require_gem lines, require 'rubygems', and then correcting
the assumptions about the location of data files.

RubyGems are Ruby's package manager. If you want to install a gem, use
RubyGems. Trying to twist and turn and stuff the square peg into the round
hole to turn a gem into an RPM is outside the scope of the design of
RubyGems. If you and a sufficiently large number of other end users feel
that it should be easy to turn gems into RPMs or one of the other Linux
package formats then that should become a new requirement of the system.
But I imagine it would require a lot of work and probably negative
compromises, so there had better be a lot of good reasons to do it beyond
"it allows me to install rails with one command."

And before you say "... just use gems", let me point out something:

To run, say, Rails, with gems:

  1) manually install ruby
  2) manually install rubygems
  3) gem install rails

As others have said, steps 1 and 2 only have to be done once for you to
use any current gem. To use RPMs you need RedHat or SuSE or one of the
other RPM distros, yet you left that out of your second shorter example.

Ryan

Lothar Scholz <mailinglists@scriptolutions.com> writes:

Hello Christian,

Hi Lothar. :slight_smile:

> Lothar Scholz <mailinglists@scriptolutions.com> writes:

i don't have a problem with writing "require 'rubygems'" on the first
line. I wouldn't add a rescue clause as i think it's a valid option to
force a user to have rubygems installed as some of the requirements of
your library.

> If you decide to go this way, please make sure you also publish your
> software as a gem only, so they won't even have the slightest chance
> to have a look at the code and determine whether it would be
> reasonable to dig it out.

Sorry i don't understand your argument. If gems are not installed
you get a brief description from the remote source and if they are
installed you can simply browse the source code.

And if there was a tar.gz not depending rubygems, I could just grab it
and look into it. If you automate your builds and shipping anyway,
come on, *this* can't be that hard to do.

In case not everyone has noticed: There are people that don't want to
use Rubygems and therefore don't have it installed.

The only problem comes when the install of a gem terminates with an
error, like not being able to compile a binary extension. But as i
pointed out before binary extensions are still a general problem for
rubygems.

And not the only one, unfortunately...

···

Lothar Scholz

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org