Gems error concerning yaml

I'm trying to install rails using gems. It chokes on yaml.
# gem18 install yaml --include-dependencies
INFO: `gem install -y` is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
Bulk updating Gem source index for: http://gems.rubyforge.org/
ERROR: could not find yaml locally or in a repository

advice?
Michael Litchard

eh, AFAIK yaml comes with the base ruby install.

···

On Jun 9, 1:52 am, Michael Litchard <mich...@schmong.org> wrote:

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

I'm trying to install rails using gems. It chokes on yaml.
# gem18 install yaml --include-dependencies
INFO: `gem install -y` is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
Bulk updating Gem source index for:http://gems.rubyforge.org/
ERROR: could not find yaml locally or in a repository

advice?
Michael Litchard

Then why would gems break on a yaml install when I tried to install rails?
The text I posted was my attempt to install yaml directly, in the hopes
of getting useful error messages. Originally, I just did this.

# gem18 install yaml --include-dependencies
INFO: `gem install -y` is now default and will be removed
INFO: use --ignore-dependencies to install only the gems you list
Bulk updating Gem source index for: http://gems.rubyforge.org/
ERROR: could not find yaml locally or in a repository

It seems to me, if yaml is part of the base install, then gems should not
try to install it. If it isn't, then it should install successfully. Either
way, it seems like
a little problem.

···

On Sun, Jun 8, 2008 at 11:13 PM, jemminger <jemminger@gmail.com> wrote:

On Jun 9, 1:52 am, Michael Litchard <mich...@schmong.org> wrote:
> [Note: parts of this message were removed to make it a legal post.]
>
> I'm trying to install rails using gems. It chokes on yaml.
> # gem18 install yaml --include-dependencies
> INFO: `gem install -y` is now default and will be removed
> INFO: use --ignore-dependencies to install only the gems you list
> Bulk updating Gem source index for:http://gems.rubyforge.org/
> ERROR: could not find yaml locally or in a repository
>
> advice?
> Michael Litchard

eh, AFAIK yaml comes with the base ruby install.

Then why would gems break on a yaml install when I tried to install rails?

I don't know. Why would you try to install yaml directly? I don't see it as a
requirement for Rails anymore -- try "gem install rails" and see what
happens.

# gem18 install yaml --include-dependencies

...

ERROR: could not find yaml locally or in a repository

That pretty clearly tells you that "yaml" does not exist as a library, and
that you should look for it elsewhere.

It seems to me, if yaml is part of the base install, then gems should not
try to install it.

There isn't any way, right now, for a gem to be part of the base install.
There isn't even a one-to-one mapping between gems (as in gem install foo)
and libraries (as in require 'foo').

I'm not convinced that's an ideal architecture, but that's how it is.

So are you suggesting that there should be a list of keywords for which
Rubygems will say "I think you mean something that's now part of core"?

···

On Monday 09 June 2008 02:03:39 Michael Litchard wrote:

no no. but when I did a gems install ruby, it choked on one of the
dependencies. It was yaml.
I ended up using netbsd's pkgsrc to install rails. It's working now. But I
don't understand why gems would think I needed to download yaml, and then
choke when it couldn't find it. Other package managers I have used don't do
this. Anyway, I was very excited to see rails working right away with hardly
any effort on my part, now I'm going to get to work on my project
to learn Ruby (building a blog engine).

···

On Mon, Jun 9, 2008 at 12:58 AM, David Masover <ninja@slaphack.com> wrote:

So are you suggesting that there should be a list of keywords for which
Rubygems will say "I think you mean something that's now part of core"?

So are you suggesting that there should be a list of keywords for which
Rubygems will say "I think you mean something that's now part of core"?

no no. but when I did a gems install ruby, it choked on one of the
dependencies. It was yaml.

There is no yaml gem, so it couldn't fail to be installed as a dependency, as no gem lists it as a dependency.

Can you paste the exact text of this failure? Maybe the actual error message you got can be reworded in order to prevent confusion.

I ended up using netbsd's pkgsrc to install rails. It's working now. But I
don't understand why gems would think I needed to download yaml, and then
choke when it couldn't find it. Other package managers I have used don't do
this.

Since there's no yaml gem, of course RubyGems will "choke" it.

Other package managers "choke" on things that don't exist:

MacPorts:

$ port install nosuchport
Error: Port nosuchport not found

FreeBSD's pkg_add:

$ pkg_add -r nosuchpackage
Error: FTP Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/nosuchpackage.tbz: File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-6.2-release/Latest/nosuchpackage.tbz' by URL

FreeBSD's portupgrade:

$ portupgrade -N nosuchport
** No such installed package or port: nosuchport

RubyGems:

$ gem install nosuchgem
ERROR: could not find gem nosuchgem locally or in a repository

···

On Jun 9, 2008, at 09:57 AM, Michael Litchard wrote:

On Mon, Jun 9, 2008 at 12:58 AM, David Masover <ninja@slaphack.com> > wrote:

The problem is that rubygems' error messages, frankly put, suck bowling
balls through garden hoses. They're basically the raised exception
without any attempt whatsoever to actually report the conditions that
led to the exception. (This, to me, defeats the whole point of
exception-handling -- exception raised at the point of detection,
exception rescued at the point of knowing what went wrong, error message
produced that explains situation -- but this is neither here nor there.)

What I'm guessing is this: at some point in the gems update (which
always happens no matter how many times it caches the gem metadata --
read any number of a dozen other threads commenting on this by now) a
YAML file is being processed. And it's failing for some reason. And
this failure gets reported in a confusing fashion that makes it look
like the error is caused by a missing YAML component.

···

On Wed, 2008-06-11 at 03:16 +0900, Eric Hodel wrote:

Since there's no yaml gem, of course RubyGems will "choke" it.

Other package managers "choke" on things that don't exist:

--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
A well-designed and humane interface does not need to be split into
beginner and expert subsystems. (Jef Raskin)

Since there's no yaml gem, of course RubyGems will "choke" it.

Other package managers "choke" on things that don't exist:

The problem is that rubygems' error messages, frankly put, suck bowling balls through garden hoses. They're basically the raised exception without any attempt whatsoever to actually report the conditions that led to the exception. (This, to me, defeats the whole point of exception-handling -- exception raised at the point of detection, exception rescued at the point of knowing what went wrong, error message produced that explains situation -- but this is neither here nor there.)

I would like to make RubyGems super awesome, but if the actual output from which error messages you think "suck bowling balls through a garden hose" are not posted, they cannot be improved.

There are 148 lines featuring "raise" in RubyGems at present, and 89 featuring "rescue". I can't psychically determine which of these raises and resuces failed you, so to improve things I'm going to need your help.

Remember, people volunteer to work on RubyGems. Complaining about the imperfections of a volunteer, open source effort without offering a helping hand does not encourage the volunteers that brought it to where it is today to continue devoting their valuable free time towards improving it.

What I'm guessing is this: at some point in the gems update (which always happens no matter how many times it caches the gem metadata -- read any number of a dozen other threads commenting on this by now) a YAML file is being processed. And it's failing for some reason. And this failure gets reported in a confusing fashion that makes it look like the error is caused by a missing YAML component.

The metadata update problem has been fixed (read rubygems-developers for details, or the ChangeLog in trunk) with a new metadata updater that does not perform updates the same way. Read any number of my responses to those dozen or so threads you're mentioning for the past 2-3 weeks. Release is twoish weeks off pending further bug fixes and feedback.

As for the error, I can only believe that you're either out of date with your RubyGems installation, or you're using an additional source that has an indexer that is out of date. RubyGems no longer uses YAML as its primary data source. It now uses Marshal exclusively.

···

On Jun 10, 2008, at 23:13 PM, Michael T. Richter wrote:

On Wed, 2008-06-11 at 03:16 +0900, Eric Hodel wrote: