From rick.denatale at gmail.com  Thu Jul  1 11:01:59 2010
From: rick.denatale at gmail.com (Rick DeNatale)
Date: Thu, 1 Jul 2010 11:01:59 -0400
Subject: [Rubygems-developers] Problems compiling native gems under Snow
	Leopard + Homebrew
In-Reply-To: <AANLkTinw_xPz40eMsGgbygV36qHfqEo2iWVbk2iHjFt1@mail.gmail.com>
References: <AANLkTinw_xPz40eMsGgbygV36qHfqEo2iWVbk2iHjFt1@mail.gmail.com>
Message-ID: <AANLkTini2iMA47TZVN0R2BdoDoL-9BqL7pWmUE-Q1pIa@mail.gmail.com>

On Tue, Jun 29, 2010 at 3:23 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Hopefully somebody here can help with this, I've asked a few other
> places with no success.

Chad, did you bring this up on the RVM list
http://groups.google.com/group/rubyversionmanager?hl=en

Don't recall seeing it there, but it's another place to ask.


-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Github: http://github.com/rubyredrick
Twitter: @RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

From thewoolleyman at gmail.com  Sat Jul  3 13:15:25 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 3 Jul 2010 10:15:25 -0700
Subject: [Rubygems-developers] Problems compiling native gems under Snow
	Leopard + Homebrew
In-Reply-To: <AANLkTini2iMA47TZVN0R2BdoDoL-9BqL7pWmUE-Q1pIa@mail.gmail.com>
References: <AANLkTinw_xPz40eMsGgbygV36qHfqEo2iWVbk2iHjFt1@mail.gmail.com> 
	<AANLkTini2iMA47TZVN0R2BdoDoL-9BqL7pWmUE-Q1pIa@mail.gmail.com>
Message-ID: <AANLkTik_N9LN_JI4sP_athJHKa3Vw2C7UWbUyuUfDD8H@mail.gmail.com>

On Thu, Jul 1, 2010 at 8:01 AM, Rick DeNatale <rick.denatale at gmail.com> wrote:
> On Tue, Jun 29, 2010 at 3:23 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> Hopefully somebody here can help with this, I've asked a few other
>> places with no success.
>
> Chad, did you bring this up on the RVM list
> http://groups.google.com/group/rubyversionmanager?hl=en
>
> Don't recall seeing it there, but it's another place to ask.

Hi Rick,

Thanks for the reply.  Yes, I did ask on the RVM list [1].  Luis
responded and asked for some additional info, which I added to the
gist:  http://gist.github.com/456916

I also got a response from adamv on the homebrew mailing list.  He
suggested doing a universal mysql build, which I did, but now the
mysql gem does not compile at all.  Here's the mkmf.log:

http://gist.github.com/456916#file_5._universal_mysql_binary_attempt

Thanks for the help,
-- Chad


[1] http://groups.google.com/group/rubyversionmanager/browse_thread/thread/8d385835387c5ed7

From noreply at rubyforge.org  Mon Jul  5 11:27:04 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Jul 2010 11:27:04 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28356 ] gem which only shows
	one possible option
Message-ID: <20100705152704.96D05185837B@rubyforge.org>

Bugs item #28356, was opened at 2010-07-05 15:27
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem which only shows one possible option

Initial Comment:
Situation: currently if there is a conflict among gems, i.e. 

gem1/lib/xxx.rb
and
gem2/lib/xxx.rb

gem which will only show one of the possibilities, which seems unexpected to me.

ex:

d:\dev>gem which ruby_to_ruby_c
(checking gem RubyToC-1.0.0.5 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/RubyToC-1.0.0.5/lib/ruby_to_ruby_c.rb

d:\dev> gem uninstall RubyToC
...
d:\dev>gem which ruby_to_ruby_c
(checking gem ruby2c-1.0.0.7 for ruby_to_ruby_c)
c:/ruby/lib/ruby/gems/1.8/gems/ruby2c-1.0.0.7/lib/ruby_to_ruby_c.rb

-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28356&group_id=126

From noreply at rubyforge.org  Tue Jul  6 20:51:31 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Jul 2010 20:51:31 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28358 ] UTF-8 encoded files
	aren't documented (with example file)
Message-ID: <20100707005132.0B3A61858395@rubyforge.org>

Bugs item #28358, was opened at 2010-07-07 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28358&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stefano Diem (teonimesic)
Assigned to: Nobody (None)
Summary: UTF-8 encoded files aren't documented (with example file)

Initial Comment:
This is a dup of #26200, but with the addition of an example file as asked by Eric.

The attached file only contains the following:

# encoding: utf-8

But i added a BOM (Byte Order Mark) to the file (with kate > Tools > Add BOM), and because of it the parser doesn't finishes (it goes to 100% and then crashes/stops)

The original message on #26200 is:

Hi, 

I've tried to document some of my UTF-8 encoded Ruby 1.9 files, but it seems that RDoc cannot do this: 

#Encoding: UTF-8
#test file

#test class
class A

  #test method
  def a
    puts "a"
  end

end

A file like the above one can't be documented on my system (I'm using Windows XP SP3 and RDoc 2.4.3). See also
http://www.ruby-forum.com/topic/189135#new.

Marvin. 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28358&group_id=126

From jbarnette at gmail.com  Wed Jul  7 10:30:54 2010
From: jbarnette at gmail.com (John Barnette)
Date: Wed, 7 Jul 2010 07:30:54 -0700
Subject: [Rubygems-developers] GitHub
Message-ID: <60EECB92-0560-40C7-A5EB-F2BD78FCC063@gmail.com>

All the active committers appear to be switched over, but I wanted to remind everyone else on the list that we've switched over to git and GitHub for the RubyGems code (http://github.com/rubygems). Chad and I worked to make sure everyone who had an active commit bit on the Subversion repo got moved over, so please ping if we missed you.


~ j.


From luislavena at gmail.com  Wed Jul  7 10:38:44 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 7 Jul 2010 11:38:44 -0300
Subject: [Rubygems-developers] GitHub
In-Reply-To: <60EECB92-0560-40C7-A5EB-F2BD78FCC063@gmail.com>
References: <60EECB92-0560-40C7-A5EB-F2BD78FCC063@gmail.com>
Message-ID: <AANLkTin3ZvYb4Ir-gulfY6F_PLgxMlL4QvH_ZjX__1Hx@mail.gmail.com>

On Wed, Jul 7, 2010 at 11:30 AM, John Barnette <jbarnette at gmail.com> wrote:
> All the active committers appear to be switched over, but I wanted to remind everyone else on the list that we've switched over to git and GitHub for the RubyGems code (http://github.com/rubygems). Chad and I worked to make sure everyone who had an active commit bit on the Subversion repo got moved over, so please ping if we missed you.
>

I believe Daniel Berger was left out:

http://github.com/djberg96

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jbarnette at gmail.com  Wed Jul  7 11:12:26 2010
From: jbarnette at gmail.com (John Barnette)
Date: Wed, 7 Jul 2010 08:12:26 -0700
Subject: [Rubygems-developers] GitHub
In-Reply-To: <AANLkTin3ZvYb4Ir-gulfY6F_PLgxMlL4QvH_ZjX__1Hx@mail.gmail.com>
References: <60EECB92-0560-40C7-A5EB-F2BD78FCC063@gmail.com>
	<AANLkTin3ZvYb4Ir-gulfY6F_PLgxMlL4QvH_ZjX__1Hx@mail.gmail.com>
Message-ID: <E342F33B-F3DC-46D0-A62D-6F2AC1EF281B@gmail.com>

On Jul 7, 2010, at 7:38 AM, Luis Lavena wrote:
> I believe Daniel Berger was left out:
> http://github.com/djberg96

Added, thanks.


From jftucker at gmail.com  Wed Jul  7 11:27:46 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 7 Jul 2010 16:27:46 +0100
Subject: [Rubygems-developers] faster rubygems.rb loading by way of deferred
	plugin loads, and other resource usage enhancements
Message-ID: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>

Hey all,

I've started work on a branch to reduce the runtime resource usage by loading rubygems.rb. Some of you are already aware of this [1].

The main 'cheat' in the branch so far is to move plugin loads into the command manager, but I'm not entirely satisfied with this, and so I'm polling for interest in what features plugin authors actually need / want, and where those can be injected. Most specifically, I want to see if they can be done so more lightly.

Initially, probably the most commonly used plugin is the gemcutter plugin, which provides commands. At present it deliberately loads the CommandManager, which results in loading in about 37 files and the spec cache into memory whenever rubygems.rb is loaded. The difference in startup performance is significantly over an order of magnitude on common developer systems (with largish numbers of gems installed).

A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:

Gem.register_plugin(:install, 'some_plugin/gem/installer')
Gem.register_plugin(:command, 'some_plugin/gem/command')

Such that rubygems could contain simple internal hooks to load these on demand, rather than ahead of time, avoiding pre-activation of plugins and the current increased cost of loading rubygems.

My end goal with this is to aim to get rubygems.rb fast and light enough that it could be used for the core integration in 1.9, to avoid the remaining and otherwise unavoidable bugs in gem_prelude.rb.

Other work that will be included in this, is indexing the paths to rubygems_plugin.rb files, and reducing the resource requirements for activation, by having a lightweight version and index set that can be used by Gem.activate in place of the current heavyweight Gem.spec.

If anyone has any comments on any of the above, I would really like to hear them before I embark on these various enhancements.

Regards,

James Tucker

[1] http://github.com/rubygems/rubygems/compare/master...perflude

From jftucker at gmail.com  Wed Jul  7 11:36:43 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 7 Jul 2010 16:36:43 +0100
Subject: [Rubygems-developers] Tracking RubyGems as a dependency
Message-ID: <231715E4-D395-4080-924D-8AB12D79DF97@gmail.com>

Hi again,

One of the things that has come up along the lines of research for better integration with system package managers is the idea of tracking rubygems itself as a dependency for gem code. Some package managers simply strip out "require 'rubygems'" from 3rd party code, which in most cases is workable given their installation plan, however, some libraries may use the Gem API, for example Gem.gunzip or the like (for want of a better example). I recognise it's hard to get 3rd party users to fill in gemspecs fully, and I have other ideas for that, but in light of simply allowing dependency lists to be filled in correctly, should there be a method to do this in the gemspec?

At present specs contain a rubygems_version field that I'm not sure we even use. Can we add some kind of "uses_rubygems" boolean field for this purpose, as it seems depending on rubygems-update would be quite incorrect.

Regards,

James Tucker

From jeremy at hinegardner.org  Wed Jul  7 12:17:23 2010
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Wed, 7 Jul 2010 10:17:23 -0600
Subject: [Rubygems-developers] Tracking RubyGems as a dependency
In-Reply-To: <231715E4-D395-4080-924D-8AB12D79DF97@gmail.com>
References: <231715E4-D395-4080-924D-8AB12D79DF97@gmail.com>
Message-ID: <20100707161723.GC29363@hinegardner.org>

On Wed, Jul 07, 2010 at 04:36:43PM +0100, James Tucker wrote:
> Hi again,
> 
> One of the things that has come up along the lines of research for better
> integration with system package managers is the idea of tracking rubygems
> itself as a dependency for gem code. Some package managers simply strip out
> "require 'rubygems'" from 3rd party code, which in most cases is workable
> given their installation plan, however, some libraries may use the Gem API,
> for example Gem.gunzip or the like (for want of a better example). I recognise
> it's hard to get 3rd party users to fill in gemspecs fully, and I have other
> ideas for that, but in light of simply allowing dependency lists to be filled
> in correctly, should there be a method to do this in the gemspec?
> 
> At present specs contain a rubygems_version field that I'm not sure we even
> use. Can we add some kind of "uses_rubygems" boolean field for this purpose,
> as it seems depending on rubygems-update would be quite incorrect.
> 

I do believe this is the purpose of the :required_rubygems_version field
in the gemspec.

  ##
  # :attr_accessor: required_rubygems_version
  #
  # The RubyGems version required by this gem

  attribute :required_rubygems_version, Gem::Requirement.default

enjoy,

-jeremy

-- 
========================================================================
 Jeremy Hinegardner                              jeremy at hinegardner.org 


From jftucker at gmail.com  Wed Jul  7 14:11:15 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 7 Jul 2010 19:11:15 +0100
Subject: [Rubygems-developers] Tracking RubyGems as a dependency
In-Reply-To: <20100707161723.GC29363@hinegardner.org>
References: <231715E4-D395-4080-924D-8AB12D79DF97@gmail.com>
	<20100707161723.GC29363@hinegardner.org>
Message-ID: <5A65F45D-9C21-4CC4-A693-4FBAD96DE612@gmail.com>


On 7 Jul 2010, at 17:17, Jeremy Hinegardner wrote:

> On Wed, Jul 07, 2010 at 04:36:43PM +0100, James Tucker wrote:
>> Hi again,
>> 
>> One of the things that has come up along the lines of research for better
>> integration with system package managers is the idea of tracking rubygems
>> itself as a dependency for gem code. Some package managers simply strip out
>> "require 'rubygems'" from 3rd party code, which in most cases is workable
>> given their installation plan, however, some libraries may use the Gem API,
>> for example Gem.gunzip or the like (for want of a better example). I recognise
>> it's hard to get 3rd party users to fill in gemspecs fully, and I have other
>> ideas for that, but in light of simply allowing dependency lists to be filled
>> in correctly, should there be a method to do this in the gemspec?
>> 
>> At present specs contain a rubygems_version field that I'm not sure we even
>> use. Can we add some kind of "uses_rubygems" boolean field for this purpose,
>> as it seems depending on rubygems-update would be quite incorrect.
>> 
> 
> I do believe this is the purpose of the :required_rubygems_version field
> in the gemspec.
> 
>  ##
>  # :attr_accessor: required_rubygems_version
>  #
>  # The RubyGems version required by this gem
> 
>  attribute :required_rubygems_version, Gem::Requirement.default

That claims therefore that *every* gem requires rubygems, which the folks I'm talking about will tell you isn't true. I'm trying to help them automate their tools by way of using spec fields that are valid. If this field was defaulted to nil, then explicitly set, then it would be valid.

> 
> enjoy,
> 
> -jeremy
> 
> -- 
> ========================================================================
> Jeremy Hinegardner                              jeremy at hinegardner.org 
> 
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From drbrain at segment7.net  Wed Jul  7 17:27:54 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 7 Jul 2010 14:27:54 -0700
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
Message-ID: <31D0B281-741B-4171-B17D-5149302CE206@segment7.net>

On Jul 7, 2010, at 08:27, James Tucker wrote:
> The main 'cheat' in the branch so far is to move plugin loads into the command manager, but I'm not entirely satisfied with this, and so I'm polling for interest in what features plugin authors actually need / want, and where those can be injected. Most specifically, I want to see if they can be done so more lightly.
> 
> Initially, probably the most commonly used plugin is the gemcutter plugin, which provides commands. At present it deliberately loads the CommandManager, which results in loading in about 37 files and the spec cache into memory whenever rubygems.rb is loaded. The difference in startup performance is significantly over an order of magnitude on common developer systems (with largish numbers of gems installed).
> 
> A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:
> 
> Gem.register_plugin(:install, 'some_plugin/gem/installer')
> Gem.register_plugin(:command, 'some_plugin/gem/command')

I like this idea.

> Such that rubygems could contain simple internal hooks to load these on demand, rather than ahead of time, avoiding pre-activation of plugins and the current increased cost of loading rubygems.

Yes.

From drbrain at segment7.net  Wed Jul  7 17:27:01 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 7 Jul 2010 14:27:01 -0700
Subject: [Rubygems-developers] Tracking RubyGems as a dependency
In-Reply-To: <5A65F45D-9C21-4CC4-A693-4FBAD96DE612@gmail.com>
References: <231715E4-D395-4080-924D-8AB12D79DF97@gmail.com>
	<20100707161723.GC29363@hinegardner.org>
	<5A65F45D-9C21-4CC4-A693-4FBAD96DE612@gmail.com>
Message-ID: <B3AC7748-328E-4CC6-9337-4F821F9542B3@segment7.net>

On Jul 7, 2010, at 11:11, James Tucker wrote:
> On 7 Jul 2010, at 17:17, Jeremy Hinegardner wrote:
>> On Wed, Jul 07, 2010 at 04:36:43PM +0100, James Tucker wrote:
>>> Hi again,
>>> 
>>> One of the things that has come up along the lines of research for better
>>> integration with system package managers is the idea of tracking rubygems
>>> itself as a dependency for gem code. Some package managers simply strip out
>>> "require 'rubygems'" from 3rd party code, which in most cases is workable
>>> given their installation plan, however, some libraries may use the Gem API,
>>> for example Gem.gunzip or the like (for want of a better example). I recognise
>>> it's hard to get 3rd party users to fill in gemspecs fully, and I have other
>>> ideas for that, but in light of simply allowing dependency lists to be filled
>>> in correctly, should there be a method to do this in the gemspec?
>>> 
>>> At present specs contain a rubygems_version field that I'm not sure we even
>>> use. Can we add some kind of "uses_rubygems" boolean field for this purpose,
>>> as it seems depending on rubygems-update would be quite incorrect.

This is supposed to be the version of rubygems used to package the gem.  (RubyGems may need some defensive coding around this to prevent it from being overridden by people who set it in their gemspecs.)

>> I do believe this is the purpose of the :required_rubygems_version field
>> in the gemspec.
>> 
>> ##
>> # :attr_accessor: required_rubygems_version
>> #
>> # The RubyGems version required by this gem
>> 
>> attribute :required_rubygems_version, Gem::Requirement.default
> 
> That claims therefore that *every* gem requires rubygems, which the folks I'm talking about will tell you isn't true. I'm trying to help them automate their tools by way of using spec fields that are valid. If this field was defaulted to nil, then explicitly set, then it would be valid.

Rake doesn't set this, so it defaults to ">= 0" (`gem spec -r rake required_rubygems_version`).

Perhaps we can bump specification_version and define a new behavior for required_rubygems_version using a newer spec_version:

> If required_rubygems_version is not set then RubyGems features are not used in the gem.  You must set required_rubygems_version in your gem if you wish to use RubyGems features in your gem.

We can continue defaulting to ">= 0" for backwards compatibility with older versions of RubyGems if necessary.  (I'm not sure what will happen if we use nil)

From thewoolleyman at gmail.com  Thu Jul  8 02:54:33 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 7 Jul 2010 23:54:33 -0700
Subject: [Rubygems-developers] Problems compiling native gems under Snow
	Leopard + Homebrew
In-Reply-To: <AANLkTinw_xPz40eMsGgbygV36qHfqEo2iWVbk2iHjFt1@mail.gmail.com>
References: <AANLkTinw_xPz40eMsGgbygV36qHfqEo2iWVbk2iHjFt1@mail.gmail.com>
Message-ID: <AANLkTikBxYBdvLDnUw6bt5sS5eJbasKmYLfJcEKo7THJ@mail.gmail.com>

On Tue, Jun 29, 2010 at 12:23 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> (also at http://gist.github.com/456916)
>
> Hopefully somebody here can help with this, I've asked a few other
> places with no success.
>
> I've got Snow Leopard running on an older macbook, with Homebrew.
>
> My problem is that some native gems have problems compiling for the
> correct architecture when I use a compiled ruby (e.g. RVM) instead of
> the system ruby.

Solved this.  Root cause was that RVM/Ruby had compiled for i386
architecture rather than x86_64:
http://gist.github.com/456916#file_6._solved

Thanks for the help...
-- Chad

From noreply at rubyforge.org  Thu Jul  8 13:23:17 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Jul 2010 13:23:17 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does
	not work on 1.9
Message-ID: <20100708172317.A645A1858388@rubyforge.org>

Bugs item #22617, was opened at 2008-10-30 16:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

Category: other
Group: v1.3.x
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Paul Brannan (cout)
Assigned to: Eric Hodel (drbrain)
Summary: Gem.loaded_specs does not work on 1.9

Initial Comment:
The loaded_specs attribute seems to always be empty on 1.9:

[pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
{"ruby-prof"=>#<Gem::Specification:0x402fd664 @extra_rdoc_files=["bin/ruby-prof", "ext/ruby_prof.c", "examples/flat.txt", "examples/graph.txt", "examples/graph.html", "README", "LICENSE"], @date=Sun Feb 03 00:00:00 -0500 2008, @new_platform="ruby", @executables=["ruby-prof"], @authors=["Shugo Maeda and Charlie Savage"], @cert_chain=[], @required_rubygems_version=#<Gem::Requirement:0x402fd470 @version=nil, @requirements=[[">=", #<Gem::Version "0">]]>, @version=#<Gem::Version "0.6.0">, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#<Gem::Requirement:0x402fcad4 @version=nil, @requirements=[[">=", #<Gem::Version "1.8.4">]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles.  For each method, graph profiles show how long the method ran, which methods called it and which  methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>}
[pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end'
/usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end'
{}


----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 17:23

Message:
I can't require 'gemname' on ruby1.9.1. Could it be related?

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-01-19 02:44

Message:
you can run ruby --disable-gems (I think) to disable gem prelude (auto loading of gem lib dirs).
Barring that, you could submit a patch that compares $LOADED_FEATURES with the load paths of existing gems and "infers" "we have already loaded those other gems via the normal mechanism"
Cheers!
-r

----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 20:36

Message:
Yes, I would love to be able to provide a patch, but I don?t see a solution.  To me it looks like this is an inherent flaw in how Ruby 1.9 and Rubygems interact.  Since Ruby 1.9 adds all the paths to gems installed on your system, Rubygems never gets a chance to load the specs and thus solve this problem.  I have no idea why it was decided that Ruby 1.9 should augment its $LOAD_PATH in this way, nor why these things weren?t considered at the time, but it would be great if someone came up with a solution.

----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2009-10-21 17:00

Message:
Whiny you sound, patches are welcome too :-)



----------------------------------------------------------------------

Comment By: Nikolai Weibull (pcp)
Date: 2009-10-21 16:48

Message:
This is still the case on Windows 1.9.1-p243.  By extension, Config.datadir, which is what I care about, doesn?t work.

I don?t want to sound whiny, but I can?t see how this can have gone unfixed for close to a year now.  It seems like a rather central concept.

----------------------------------------------------------------------

Comment By: Matt Hulse (mhulse)
Date: 2009-08-04 23:27

Message:
Yes, this is still happening in 1.9.1-p129.  I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads.  I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for).

----------------------------------------------------------------------

Comment By: Joeri Samson (joeri)
Date: 2009-03-29 18:42

Message:
with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake":

joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs'
{}
{"rake"=>#<Gem::Specification:0x81c8240 @new_platform="ruby", @name="rake", @version=#<Gem::Version "0.8.4">, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#<Gem::Requirement:0x81c8088 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @required_rubygems_version=#<Gem::Requirement:0x81c7778 @requirements=[[">=", #<Gem::Version "0">]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">}

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2009-03-27 21:29

Message:
With 1.9.1p0 and 1.9.2dev I see:

$ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs'
ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0]
<internal:gem_prelude>:234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError)
	from <internal:gem_prelude>:14:in `gem'
	from -e:1:in `<main>'

This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:50

Message:
Ah, no, I hit .activate, which hits source_index.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2009-03-16 10:48

Message:
works for me

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-01-02 15:59

Message:
Is this still happening in 1.9.1?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126

From noreply at rubyforge.org  Thu Jul  8 15:28:12 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Jul 2010 15:28:12 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20100708192813.05F9F1858370@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 19:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Thu Jul  8 16:08:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Jul 2010 16:08:30 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20100708200830.B57531858377@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 19:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

>Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 20:08

Message:
I did a further investigation and found out that when ruby
is run with --disable-gems the gem loading works.

I looks like the line below on rubygems.rb is preventing the
load through 'require' to work in 1.9.1:

require 'rubygems/custom_require' if gem_disabled or
RUBY_VERSION < '1.9'

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Fri Jul  9 09:59:38 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  9 Jul 2010 09:59:38 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20100709135938.9B835185837A@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 19:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-09 13:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 20:08

Message:
I did a further investigation and found out that when ruby
is run with --disable-gems the gem loading works.

I looks like the line below on rubygems.rb is preventing the
load through 'require' to work in 1.9.1:

require 'rubygems/custom_require' if gem_disabled or
RUBY_VERSION < '1.9'

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Fri Jul  9 09:59:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  9 Jul 2010 09:59:49 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28365 ] rubygems not
	uploading $LOAD_PATH with ruby 1.9.1
Message-ID: <20100709135949.EE576185837F@rubyforge.org>

Bugs item #28365, was opened at 2010-07-08 19:28
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

Category: #gem and #require methods
Group: v1.3.x
Status: Open
>Resolution: Rejected
Priority: 3
Submitted By: Giorgenes Gelatti (giorgenes)
Assigned to: Nobody (None)
Summary: rubygems not uploading $LOAD_PATH with ruby 1.9.1

Initial Comment:
I have successful installed gems, but when I do a require 'gemname' it fails. The $LOAD_PATH var shows the gem paths are not loaded.
I'm using ruby1.9.1p378 and gems 1.3.7 on ubuntu 10.04.

# gem list

*** LOCAL GEMS ***

rest-client (1.6.0)
.....

# irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> $:
=> ["/usr/local/lib/site_ruby/1.9.1", "/usr/local/lib/site_ruby/1.9.1/i486-linux", "/usr/local/lib/site_ruby", "/usr/lib/ruby/vendor_ruby/1.9.1", "/usr/lib/ruby/vendor_ruby/1.9.1/i486-linux", "/usr/lib/ruby/vendor_ruby", "/usr/lib/ruby/1.9.1", "/usr/lib/ruby/1.9.1/i486-linux", "."]
irb(main):003:0> require 'rest_client'
LoadError: no such file to load -- rest_client
	from (irb):3:in `require'
	from (irb):3
	from /usr/bin/irb:12:in `<main>'




----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-09 13:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-07-09 13:59

Message:
Yup, this is a bug in ruby.

----------------------------------------------------------------------

Comment By: Giorgenes Gelatti (giorgenes)
Date: 2010-07-08 20:08

Message:
I did a further investigation and found out that when ruby
is run with --disable-gems the gem loading works.

I looks like the line below on rubygems.rb is preventing the
load through 'require' to work in 1.9.1:

require 'rubygems/custom_require' if gem_disabled or
RUBY_VERSION < '1.9'

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28365&group_id=126

From noreply at rubyforge.org  Fri Jul  9 10:38:16 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  9 Jul 2010 10:38:16 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Feature Requests-28366 ] Better C
	Extension Handling
Message-ID: <20100709143816.EEC21185837F@rubyforge.org>

Feature Requests item #28366, was opened at 2010-07-09 14:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28366&group_id=126

Category: local package management
Group: future
Status: Open
Resolution: None
Priority: 3
Submitted By: Kyle Banker (kbanker)
Assigned to: Nobody (None)
Summary: Better C Extension Handling

Initial Comment:
When installing a gem, if the C extensions fail to compile, then the gem won't be installed. This forces me to maintain two gems, one in pure ruby and the other containing the optional extensions, just to make sure that users can fail over to the pure ruby version if the extension don't compile.

I'd like to merge these gems into one. This would require that RubyGems change somehow.

Ideally, there'd be a setting which would allow the gem to be installed even if the extensions fail to compile. That setting would allow for a special error message to be displayed, informing the user that the extensions haven't compiled correctly but that the gem is still usable.

Would you accept a patch for this feature?
Is there another way of going about this?
Is there a way to handle this situation with the current version of RubyGems?

Thanks,
Kyle

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28366&group_id=126

From luislavena at gmail.com  Fri Jul  9 12:25:05 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 9 Jul 2010 13:25:05 -0300
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
Message-ID: <AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>

On Wed, Jul 7, 2010 at 12:27 PM, James Tucker <jftucker at gmail.com> wrote:
> Hey all,
>
> I've started work on a branch to reduce the runtime resource usage by loading rubygems.rb. Some of you are already aware of this [1].
>
> The main 'cheat' in the branch so far is to move plugin loads into the command manager, but I'm not entirely satisfied with this, and so I'm polling for interest in what features plugin authors actually need / want, and where those can be injected. Most specifically, I want to see if they can be done so more lightly.
>
> Initially, probably the most commonly used plugin is the gemcutter plugin, which provides commands. At present it deliberately loads the CommandManager, which results in loading in about 37 files and the spec cache into memory whenever rubygems.rb is loaded. The difference in startup performance is significantly over an order of magnitude on common developer systems (with largish numbers of gems installed).
>
> A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:
>
> Gem.register_plugin(:install, 'some_plugin/gem/installer')
> Gem.register_plugin(:command, 'some_plugin/gem/command')
>

Wouldn't be more appropriate Gem.register_command(:push,
'path/to/gemcutter/plugin') ?

After all, you're registering commands, since the plugin loader has
already been started.

> Such that rubygems could contain simple internal hooks to load these on demand, rather than ahead of time, avoiding pre-activation of plugins and the current increased cost of loading rubygems.
>

I like this, a lot.

> My end goal with this is to aim to get rubygems.rb fast and light enough that it could be used for the core integration in 1.9, to avoid the remaining and otherwise unavoidable bugs in gem_prelude.rb.
>
> Other work that will be included in this, is indexing the paths to rubygems_plugin.rb files, and reducing the resource requirements for activation, by having a lightweight version and index set that can be used by Gem.activate in place of the current heavyweight Gem.spec.
>

Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer
the actual plugin loading script for the command invitation?

What is the benefit on indexing those, since these were already loaded?

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From jftucker at gmail.com  Fri Jul  9 13:40:00 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 9 Jul 2010 18:40:00 +0100
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
Message-ID: <0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>


On 9 Jul 2010, at 17:25, Luis Lavena wrote:

> On Wed, Jul 7, 2010 at 12:27 PM, James Tucker <jftucker at gmail.com> wrote:
>> Hey all,
>> 
>> I've started work on a branch to reduce the runtime resource usage by loading rubygems.rb. Some of you are already aware of this [1].
>> 
>> The main 'cheat' in the branch so far is to move plugin loads into the command manager, but I'm not entirely satisfied with this, and so I'm polling for interest in what features plugin authors actually need / want, and where those can be injected. Most specifically, I want to see if they can be done so more lightly.
>> 
>> Initially, probably the most commonly used plugin is the gemcutter plugin, which provides commands. At present it deliberately loads the CommandManager, which results in loading in about 37 files and the spec cache into memory whenever rubygems.rb is loaded. The difference in startup performance is significantly over an order of magnitude on common developer systems (with largish numbers of gems installed).
>> 
>> A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:
>> 
>> Gem.register_plugin(:install, 'some_plugin/gem/installer')
>> Gem.register_plugin(:command, 'some_plugin/gem/command')
>> 
> 
> Wouldn't be more appropriate Gem.register_command(:push,
> 'path/to/gemcutter/plugin') ?
> 
> After all, you're registering commands, since the plugin loader has
> already been started.

Special casing for some hooks is fine, yes. Obviously the hooks for plugin initializations don't override or replace hooks for specific things, like pre_install / post_install, etc. I'm also looking into adding new hooks for certain things so that other things can be registered more correctly (e.g. http://github.com/erikh/hanna/blob/master/lib/rubygems_plugin.rb)

>> Such that rubygems could contain simple internal hooks to load these on demand, rather than ahead of time, avoiding pre-activation of plugins and the current increased cost of loading rubygems.
>> 
> 
> I like this, a lot.
> 
>> My end goal with this is to aim to get rubygems.rb fast and light enough that it could be used for the core integration in 1.9, to avoid the remaining and otherwise unavoidable bugs in gem_prelude.rb.
>> 
>> Other work that will be included in this, is indexing the paths to rubygems_plugin.rb files, and reducing the resource requirements for activation, by having a lightweight version and index set that can be used by Gem.activate in place of the current heavyweight Gem.spec.
>> 
> 
> Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer
> the actual plugin loading script for the command invitation?

Yes, it will defer calling activate and modifying the load path.

> What is the benefit on indexing those, since these were already loaded?

To avoid needing to load Gem.spec in order to execute Gem.find_files, which is insanely expensive (relatively speaking).


From headius at headius.com  Fri Jul  9 14:36:51 2010
From: headius at headius.com (Charles Oliver Nutter)
Date: Fri, 9 Jul 2010 13:36:51 -0500
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com> 
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com> 
	<0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>
Message-ID: <AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>

On Fri, Jul 9, 2010 at 12:40 PM, James Tucker <jftucker at gmail.com> wrote:
>> Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer
>> the actual plugin loading script for the command invitation?
>
> Yes, it will defer calling activate and modifying the load path.
>
>> What is the benefit on indexing those, since these were already loaded?
>
> To avoid needing to load Gem.spec in order to execute Gem.find_files, which is insanely expensive (relatively speaking).

FWIW, I wrote up a blog post last night about how to walk the heap,
examine memory sizes, and so on using JRuby. One of the items I called
out were all the Gem::Version objects in memory, and there's other
offenders. If you'd like to do some of that exploration, I'm happy to
help.

http://blog.headius.com/2010/07/browsing-memory-jruby-way.html

I'm definitely interested in helping reduce the startup load from
RubyGems. It's the largest (by far) slowdown for JRuby startup, which
drives our users a bit batty.

- Charlie

From jftucker at gmail.com  Fri Jul  9 15:08:14 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 9 Jul 2010 20:08:14 +0100
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
	<0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>
	<AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
Message-ID: <61EBA846-8204-4087-8FA3-03CE2AFC8548@gmail.com>


On 9 Jul 2010, at 19:36, Charles Oliver Nutter wrote:

> On Fri, Jul 9, 2010 at 12:40 PM, James Tucker <jftucker at gmail.com> wrote:
>>> Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer
>>> the actual plugin loading script for the command invitation?
>> 
>> Yes, it will defer calling activate and modifying the load path.
>> 
>>> What is the benefit on indexing those, since these were already loaded?
>> 
>> To avoid needing to load Gem.spec in order to execute Gem.find_files, which is insanely expensive (relatively speaking).
> 
> FWIW, I wrote up a blog post last night about how to walk the heap,
> examine memory sizes, and so on using JRuby. One of the items I called
> out were all the Gem::Version objects in memory, and there's other
> offenders. If you'd like to do some of that exploration, I'm happy to
> help.
> 
> http://blog.headius.com/2010/07/browsing-memory-jruby-way.html
> 
> I'm definitely interested in helping reduce the startup load from
> RubyGems. It's the largest (by far) slowdown for JRuby startup, which
> drives our users a bit batty.

The real pain is loading Gem.spec. I have a two fold plan for this, initially, try to avoid loading it with rubygems.rb. Later on, I want to cut down the amount of metadata that is even loaded through ruby when just activating gems. Stuff that can really kill you is like having multiple versions of pre 2.0 facets installed, or having rdoc-data installed and so on.

I blogged about this back in 2007, although I was more interested in page fragmentation under MRI back then: http://blog.ra66i.org/archives/2007/10/calling-on-the-gc-after-rubygems/

At present, adding GC.start after loading Gem.spec on MRI still actually has quite a significantly positive impact on heap fragmentation, depending on other specific context.

> 
> - Charlie
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From jftucker at gmail.com  Fri Jul  9 15:10:50 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 9 Jul 2010 20:10:50 +0100
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
	<0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>
	<AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
Message-ID: <D56ACB3A-0337-4551-AF54-15AB2DBA6BE0@gmail.com>


On 9 Jul 2010, at 19:36, Charles Oliver Nutter wrote:

> On Fri, Jul 9, 2010 at 12:40 PM, James Tucker <jftucker at gmail.com> wrote:
>>> Wouldn't rubygems_plugin.rb do the Gem.register* command and deffer
>>> the actual plugin loading script for the command invitation?
>> 
>> Yes, it will defer calling activate and modifying the load path.
>> 
>>> What is the benefit on indexing those, since these were already loaded?
>> 
>> To avoid needing to load Gem.spec in order to execute Gem.find_files, which is insanely expensive (relatively speaking).
> 
> FWIW, I wrote up a blog post last night about how to walk the heap,
> examine memory sizes, and so on using JRuby. One of the items I called
> out were all the Gem::Version objects in memory, and there's other
> offenders. If you'd like to do some of that exploration, I'm happy to
> help.
> 
> http://blog.headius.com/2010/07/browsing-memory-jruby-way.html
> 
> I'm definitely interested in helping reduce the startup load from
> RubyGems. It's the largest (by far) slowdown for JRuby startup, which
> drives our users a bit batty.

And yes, despite the interpreter specific details in my last, this is very much an architectural problem, and can be fixed with some work.

> 
> - Charlie
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From jbarnette at gmail.com  Fri Jul  9 17:37:39 2010
From: jbarnette at gmail.com (John Barnette)
Date: Fri, 9 Jul 2010 14:37:39 -0700
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
	<0752C020-B2AC-4435-8F28-EC0F316E17C7@gmail.com>
	<AANLkTikvh4r5RljCs9ZOxklX6OjYpYv8nWOSKBF99y7I@mail.gmail.com>
Message-ID: <41F12B2A-A81E-4866-A8EB-D2EBDDA7D41B@gmail.com>

On Jul 9, 2010, at 11:36 AM, Charles Oliver Nutter wrote:
> FWIW, I wrote up a blog post last night about how to walk the heap,
> examine memory sizes, and so on using JRuby. One of the items I called
> out were all the Gem::Version objects in memory, and there's other
> offenders. If you'd like to do some of that exploration, I'm happy to
> help.

Evan and I were talking a while ago about changing RubyGems to memoize/reuse Gem::Version, Gem::Dependency, and Gem::Requirement. The burndown I did on them for 1.3.4 made them immutable, so it shouldn't be a huge effort. Interested in poking at that with us?


~ j.


From drbrain at segment7.net  Fri Jul  9 19:39:47 2010
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 9 Jul 2010 16:39:47 -0700
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
Message-ID: <199C51DD-D075-4626-8C14-F5DA306724E8@segment7.net>

On Jul 9, 2010, at 09:25, Luis Lavena wrote:
>> A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:
>> 
>> Gem.register_plugin(:install, 'some_plugin/gem/installer')
>> Gem.register_plugin(:command, 'some_plugin/gem/command')
>> 
> 
> Wouldn't be more appropriate Gem.register_command(:push,
> 'path/to/gemcutter/plugin') ?
> 
> After all, you're registering commands, since the plugin loader has
> already been started.

I think register_plugin could be as simple as:

module Gem

  @plugins = Hash.new { |h,k| h[k] = [] }

  def self.register_plugin type, path
    @plugins[type] << path
  end
end

And Gem::CommandManager would look in the hash to see what files it should load after it is required (if at all).

From jftucker at gmail.com  Fri Jul  9 22:15:22 2010
From: jftucker at gmail.com (James Tucker)
Date: Sat, 10 Jul 2010 03:15:22 +0100
Subject: [Rubygems-developers] faster rubygems.rb loading by way of
	deferred plugin loads, and other resource usage enhancements
In-Reply-To: <199C51DD-D075-4626-8C14-F5DA306724E8@segment7.net>
References: <BD8CB3CF-A64C-4C7A-BF09-01568CEFF15D@gmail.com>
	<AANLkTinB67EakmcPtjZZCuc7SXKEDiQ_1pSMyeKzoKaG@mail.gmail.com>
	<199C51DD-D075-4626-8C14-F5DA306724E8@segment7.net>
Message-ID: <F85DC3F0-812E-47A8-95C3-8DEBB64AC176@gmail.com>


On 10 Jul 2010, at 00:39, Eric Hodel wrote:

> On Jul 9, 2010, at 09:25, Luis Lavena wrote:
>>> A solution for command plugins would be to have plugins simply register a list of files that should be loaded when commands are going to be invoked. A continuation of this idea leads to an API something along the lines of:
>>> 
>>> Gem.register_plugin(:install, 'some_plugin/gem/installer')
>>> Gem.register_plugin(:command, 'some_plugin/gem/command')
>>> 
>> 
>> Wouldn't be more appropriate Gem.register_command(:push,
>> 'path/to/gemcutter/plugin') ?
>> 
>> After all, you're registering commands, since the plugin loader has
>> already been started.
> 
> I think register_plugin could be as simple as:
> 
> module Gem
> 
>  @plugins = Hash.new { |h,k| h[k] = [] }
> 
>  def self.register_plugin type, path
>    @plugins[type] << path
>  end
> end
> 
> And Gem::CommandManager would look in the hash to see what files it should load after it is required (if at all).

Yup, that's exactly what i was going toward.

> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From noreply at rubyforge.org  Sat Jul 10 12:39:00 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Jul 2010 12:39:00 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28371 ] Gem.find_home should
	expand all the paths, including Windows
Message-ID: <20100710163901.197C61858366@rubyforge.org>

Bugs item #28371, was opened at 2010-07-10 13:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Luis Lavena (luislavena)
Assigned to: Luis Lavena (luislavena)
Summary: Gem.find_home should expand all the paths, including Windows

Initial Comment:
On Windows, find_home look for environment variables like HOME, USERPROFILE and HOMEDRIVE + HOMEPATH

The problem is that it directly assign the value obtained from it to user_home, disregarding if these variables contain slashes or backslashes.

On fetching of gems, RubyGems uses user_home to download and store remote specifications and quick indexes, which uses FileUtils.mkdir_p to create the folder structure.

The problem at this point is that FileUtils is not aware of backslashes and thus, failing.

Having consistent slashes using File.expand_path will be more consistent and reduce the chances of errors.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28371&group_id=126

From noreply at rubyforge.org  Tue Jul 13 11:33:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Jul 2010 11:33:30 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-26792 ] uses gem even when an
	install fails
Message-ID: <20100713153330.663381858381@rubyforge.org>

Bugs item #26792, was opened at 2009-07-29 23:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26792&group_id=126

Category: None
Group: v1.3.x
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: Evan Phoenix (evan)
Summary: uses gem even when an install fails

Initial Comment:
Appears that in 1.9, at least

if you install a gem, and the installation fails

then you run 
require 'gemname'
it still loads it--in its very broken state.

At least that's about what I figure from scratching my head at this circumstance:

C:\dev\ruby\downloads\ruby-debug\pkg>gem search linecache -b

*** LOCAL GEMS ***

mark-moseley-linecache (0.5.2)
# note the lack of linecache -- removing mark-moseley-linecache seems to not affect the results, either

*** REMOTE GEMS ***

linecache (0.43)
mark-moseley-linecache (0.5.2)

C:\dev\ruby\downloads\ruby-debug\pkg>gem install linecache
Building native extensions.  This could take a while...
ERROR:  Error installing linecache:
        ERROR: Failed to build gem native extension.

c:/installs/ruby_trunk_installed/bin/ruby.exe extconf.rb
Can't handle 1.9.x yet
*** extconf.rb failed ***
...

C:\dev\ruby\downloads\ruby-debug\pkg>gem search linecache

*** LOCAL GEMS ***

mark-moseley-linecache (0.5.2)

C:\dev\ruby\downloads\ruby-debug\pkg>irb
irb(main):001:0> require 'ruby-debug'
LoadError: no such file to load -- c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/../lib/trace_nums # note that it's using the linecache-0.43 that just failed
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:12:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:12:in `rescue in <module:TraceLineNumbers>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:8:in `<module:TraceLineNumbers>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/tracelines.rb:6:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb:63:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb:63:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/mark-moseley-ruby-debug-base-0.11.6/lib/ruby-debug-base.rb:3:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/mark-moseley-ruby-debug-base-0.11.6/lib/ruby-debug-base.rb:3:in `<top (required)>'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/ruby-debug-0.11/cli/ruby-debug.rb:5:in `require'
        from c:/installs/ruby_trunk_installed/lib/ruby/gems/1.9.1/gems/ruby-debug-0.11/cli/ruby-debug.rb:5:in `<top (required)>'
        from (irb):1:in `require'
        from (irb):1
        from c:/installs/ruby_trunk_installed/bin/irb.bat:20:in `<main>'

Thanks!

[gem v 1.3.5, ruby 1.9.2 trunk]

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-13 15:33

Message:
`gem list` cannot reproduce the issue.

It's gem_prelude requires not using the installed spec list that's the problem.

Assigning to Evan.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-02-09 15:56

Message:
It doesn't show up as a gem list, however it still gets
assigned to the load path thanks to gem prelude.

How to reproduce:

c:\dev_old\digitalarchive_trunk>gem install linecache
Building native extensions.  This could take a while...
ERROR:  Error installing linecache:
        ERROR: Failed to build gem native extension.

...
c:\dev_old\digitalarchive_trunk>gem search linecache

*** LOCAL GEMS ***


c:\dev_old\digitalarchive_trunk>gem which linecache
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/linecache-0.43/lib/linecache.rb

(and you can require it--require 'linecache' even though the
install failed, which was unexpected to me since 1.8 doesn't
do this).
-r

----------------------------------------------------------------------

Comment By: Eric Hodel (drbrain)
Date: 2010-02-09 05:38

Message:
I believe this was fixed prior to 1.3.5 as 1.8 and 1.9.2 trunk give me the same:

$ ruby19 -Ilib bin/gem install mysql -i ~/tmp/gems

mysql 2.8.1 is 100% verified 1.9
Update http://isitruby19.com/mysql with your experiences!

Building native extensions.  This could take a while...
ERROR:  Error installing mysql:
	ERROR: Failed to build gem native extension.
[...]
$ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ruby19 -Ilib bin/gem list

*** LOCAL GEMS ***


$

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26792&group_id=126

From noreply at rubyforge.org  Wed Jul 14 13:32:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Jul 2010 13:32:26 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28384 ] gem install doesn't
	refresh Rakefile (or something along those lines)
Message-ID: <20100714173226.4390718583AD@rubyforge.org>

Bugs item #28384, was opened at 2010-07-14 17:32
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem install doesn't refresh Rakefile (or something along those lines)

Initial Comment:
Hi.  Noticed the following:




C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
Successfully installed spork-0.8.4
1 gem installed

# reports success


C:\installs\a space\ruby_1_8_installed\bin>gem uninstall spork -a
Remove executables:
        spork

in addition to the gem? [Yn]  y
Removing spork
Successfully uninstalled spork-0.8.4

C:\installs\a space\ruby_1_8_installed\bin>gem install spork
Building native extensions.  This could take a while...
ERROR:  Error installing spork:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" mkrf_conf.rb
Actually, there aren't any native extensions. I'm just dynamically installing dependencies based off of your operating system
installing windows dependencies

"C:/installs/a space/ruby_1_8_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/lib"
C:/installs/a space/ruby_1_8_installed/bin/ruby.exe:36: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4 for inspection.
Results logged to C:/installs/a space/ruby_1_8_installed/lib/ruby/gems/1.8/gems/spork-0.8.4/ext/gem_make.out


now reports failure.  I would have expected them both to report failure.

Thanks.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28384&group_id=126

From noreply at rubyforge.org  Wed Jul 14 13:40:51 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Jul 2010 13:40:51 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28385 ] gems with
	mkrf_conf.rb extensions fail to build when installed into a
	ruby in a directory name that includes spaces
Message-ID: <20100714174051.7967A19783BA@rubyforge.org>

Bugs item #28385, was opened at 2010-07-14 17:40
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gems with mkrf_conf.rb extensions fail to build when installed into a ruby in a directory name that includes spaces

Initial Comment:

C:\installs\a space\ruby_1_9_2_installed\bin>gem install rdp-rb-readline
Building native extensions.  This could take a while...
ERROR:  Error installing rdp-rb-readline:
        ERROR: Failed to build gem native extension.

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" mkrf_conf.rb

"C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe" -rubygems C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rake-0.8.7/bin/rake RUBYARCHDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib" RUBYLIBDIR="C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/lib"
C:/installs/a space/ruby_1_9_2_installed/bin/ruby.exe: No such file or directory -- C:/installs/a (LoadError)


Gem files will remain installed in C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1 for inspection.
Results logged to C:/installs/a space/ruby_1_9_2_installed/lib/ruby/gems/1.9.1/gems/rdp-rb-readline-0.2.0.1/ext/gem_make.out

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28385&group_id=126

From noreply at rubyforge.org  Wed Jul 14 20:56:02 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Jul 2010 20:56:02 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Feature Requests-28386 ] please
	disallow non standard gems
Message-ID: <20100715005602.651A81858379@rubyforge.org>

Feature Requests item #28386, was opened at 2010-07-15 00:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28386&group_id=126

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: please disallow non standard gems

Initial Comment:
Would it be possible to require gems to have at most one lib dir, and at most one file in that dir, named gem_name.rb?

This would sure beat the confusion of doing a

require 'xxx' # automagically looks up xxx in any gem--and arbitrarily loads the first.

Thanks so much.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28386&group_id=126

From noreply at rubyforge.org  Sat Jul 17 21:38:03 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 17 Jul 2010 21:38:03 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28399 ] rubygems should use
	RbConfig::CONFIG['make-prog']
Message-ID: <20100718013803.7C95B185836B@rubyforge.org>

Bugs item #28399, was opened at 2010-07-17 18:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody (None)
Summary: rubygems should use RbConfig::CONFIG['make-prog']

Initial Comment:
Similar to mkmf.rb, rubygems should use Config['make-prog'] if it is set. This allows per-ruby configuration of which "make" to use.


mkmf.rb does:

$make = with_config("make-prog", ENV["MAKE"] || "make")
make, = Shellwords.shellwords($make)
$nmake = nil
case
when $mswin
  $nmake = ?m if /nmake/i =~ make
when $bccwin
  $nmake = ?b if /Borland/i =~ `#{make} -h`
end


rubygems/ext/builder.rb does:

make_program = ENV['make']
unless make_program then
  make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make'
end


I believe they should be the same, and that the mkmf.rb method is preferable.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

From noreply at rubyforge.org  Sun Jul 18 08:23:13 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 18 Jul 2010 08:23:13 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28399 ] rubygems should use
	RbConfig::CONFIG['make-prog']
Message-ID: <20100718122313.89C941858384@rubyforge.org>

Bugs item #28399, was opened at 2010-07-18 01:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Greg Hazel (ghazel)
Assigned to: Nobody (None)
Summary: rubygems should use RbConfig::CONFIG['make-prog']

Initial Comment:
Similar to mkmf.rb, rubygems should use Config['make-prog'] if it is set. This allows per-ruby configuration of which "make" to use.


mkmf.rb does:

$make = with_config("make-prog", ENV["MAKE"] || "make")
make, = Shellwords.shellwords($make)
$nmake = nil
case
when $mswin
  $nmake = ?m if /nmake/i =~ make
when $bccwin
  $nmake = ?b if /Borland/i =~ `#{make} -h`
end


rubygems/ext/builder.rb does:

make_program = ENV['make']
unless make_program then
  make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make'
end


I believe they should be the same, and that the mkmf.rb method is preferable.

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-18 12:23

Message:
+1

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28399&group_id=126

From noreply at rubyforge.org  Mon Jul 19 09:32:43 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Jul 2010 09:32:43 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25826 ] Uninstalling
	executables created with --format-executable
Message-ID: <20100719133243.D25C31858386@rubyforge.org>

Bugs item #25826, was opened at 2009-05-07 10:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Sven Schwyn (sschwyn)
Assigned to: Nobody (None)
Summary: Uninstalling executables created with --format-executable

Initial Comment:
Here's an example:

gem install --format-executable rake
==> Installs executable "rake18".

ln -s rake18 rake
==> This step is performed by most Linux distros.

gem uninstall rake
==> Asks whether to uninstall "rake", but not "rake18".

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-19 13:32

Message:
Indeed, this should not be used on a per command basis at all.

I'm thinking about removing it to avoid these problems, and maintaining support purely by config file.

----------------------------------------------------------------------

Comment By: Sven Schwyn (svoop)
Date: 2010-01-14 18:51

Message:
In fact, just add --format-executable to the uninstall command and the case is closed as those using this option most likely won't use it on a "per command" basis.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=25826&group_id=126

From noreply at rubyforge.org  Mon Jul 19 09:34:19 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Jul 2010 09:34:19 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated
	rubygems/rubygems_version.rb still exists on Leopard default
	ruby install even though it was removed in 1.3.5
Message-ID: <20100719133419.411C1185838A@rubyforge.org>

Bugs item #26740, was opened at 2009-07-24 07:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126

Category: None
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Chad Woolley (thewoolleyman)
Assigned to: Nobody (None)
Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5

Initial Comment:
Does system installer not delete old files?  If someone happens to load this file, they get a warning, then get the wrong version.

Can't we just move the version back into this file and avoid the issue altogether?

chadmac:1.8 woolley$ pwd
/Library/Ruby/Site/1.8
chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb 
  RubyGemsVersion = VERSION = '1.3.5'
chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb 
rubygems/rubygems_version.rb


chadmac:~ woolley$ irb
>> Gem::RubyGemsVersion
=> "1.3.5"
>> require 'rubygems/rubygems_version'
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION
=> true
>> Gem::RubyGemsVersion
=> "1.3.4"


chadmac:~ woolley$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0]
  - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8
  - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - universal-darwin-9
  - GEM PATHS:
     - /Library/Ruby/Gems/1.8
     - /Users/woolley/.gem/ruby/1.8
     - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org
     - http://gems.github.com




----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-19 13:34

Message:
We should keep a manifest and use that during uninstalls.


----------------------------------------------------------------------

Comment By: Youssef Gaigi (youssefg)
Date: 2009-10-09 00:31

Message:
Did you figure out a way out of this.

I tried to delete rubygems and install again, but still the problem is there. Here's what I get whenever i require rubygems:

irb(main):001:0> require 'RubyGems'
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:14: warning: already initialized constant VERSION
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:14: warning: already initialized constant RubyGemsVersion
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:193: warning: already initialized constant MUTEX
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:195: warning: already initialized constant RubyGemsPackageVersion
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:207: warning: already initialized constant WIN_PATTERNS
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:1078: warning: already initialized constant MARSHAL_SPEC_DIR
/usr/lib/ruby/site_ruby/1.8/RubyGems.rb:1083: warning: already initialized constant YAML_SPEC_DIR
=> true

I appreciate your help

Youssef

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-18 01:53

Message:
You have fixed it Chad-- our preinit wasn't enforcing 0.5.3 or greater, and this particular box did not yet have 0.5.3 installed.

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-09-17 21:08

Message:
"You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb."

I'm sure I fixed this in the latest geminstaller release.  Please open a bug if I didn't.

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-17 18:44

Message:
Hey Ryan,

You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb.

As a result, the "require 'rubygems'" call on line 86 of config/boot.rb was actually returning false and consequently not setting the RubyGemsVersion to 1.3.5 appropriately.

This explains why I could not reproduce the problem in irb.  My apologies for the noise.

In any case, manually deleting the file did do the trick.

-John


----------------------------------------------------------------------

Comment By: Ryan Davis (zenspider)
Date: 2009-09-17 18:23

Message:
I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion.

How did you get bit by this bug?

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-09-17 14:55

Message:
I just want to point out that this exact bug bit us pretty badly again.  The scenario is this (and I'm surprised it hasn't happened more frequently):

We're running a rails 2.3.4 app.  The rails 2.3.x branch requires rubygems 1.3.2 or greater.

On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5.  As a result, this left the rubygems_version.rb file specifying version 1.3.1.  As a result, we could never actually run the rails app because of the version checking code in config/boot.rb.

It took us quite awhile to track down what the issue really was.  Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did.

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-07-24 20:53

Message:
Agreed, a very low priority.  I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs.

However, this should probably get turned into a bug with the system install command, because it isn't deleting old files.  This could come back to bite us in a more serious way in the future.

----------------------------------------------------------------------

Comment By: John Trupiano (jtrupiano)
Date: 2009-07-24 20:51

Message:
I can confirm the odd behavior on a default Leopard install:

john-mbp:1.8 john$ irb
irb(main):001:0> Gem::RubyGemsVersion
=> "1.3.5"
irb(main):002:0> require 'rubygems/rubygems_version'
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion
/Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION
=> true
irb(main):003:0> Gem::RubyGemsVersion
=> "1.3.4"

-John

----------------------------------------------------------------------

Comment By: Daniel Berger (djberg96)
Date: 2009-07-24 19:16

Message:
I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix.

Regards,

Dan

----------------------------------------------------------------------

Comment By: Chad Woolley (thewoolleyman)
Date: 2009-07-24 19:01

Message:
Rejected with no comment, huh?  Classy.

You ignore the fact that there are actual bugs:  

* RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution
* This file contains an outdated and conflicting RubyGems version number
* If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version.
* There is a bug with the system update command that does not delete old files, at least on the default Leopard install.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126

From noreply at rubyforge.org  Mon Jul 19 09:36:48 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Jul 2010 09:36:48 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-27841 ] gem prelude appears
	to prefer older versions of gems at times
Message-ID: <20100719133648.C9B0F185838B@rubyforge.org>

Bugs item #27841, was opened at 2010-02-16 14:57
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27841&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem prelude appears to prefer older versions of gems at times

Initial Comment:
Currently on doze, if I install the ffi gem with the following two version:


ffi-0.5.4-x86-mingw32

ffi-0.6.2 (from source)

gem prelude appears to "prefer" 0.5.4 even though it's older.

c:\dev_old\digitalarchive_trunk>gem search ffi

*** LOCAL GEMS ***

ffi (0.6.2, 0.6.0, 0.5.4)

c:\dev_old\digitalarchive_trunk>ruby -v  -rffi -e 'puts $LOADED_FEATURES.grep(/ffi/)'
ruby 1.9.1p376 (2009-12-07 revision 26041) [i386-mingw32]
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/ffi-0.5.4-x86-mingw32/lib/1.9/ffi_c.so
E:/installs/ruby191p376/lib/ruby/gems/1.9.1/gems/ffi-0.5.4-x86-mingw32/lib/ffi/platform.rb
...

Thanks!
-rp

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-19 13:36

Message:
Sigh, prelude, roger, is this bug still active?


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27841&group_id=126

From noreply at rubyforge.org  Mon Jul 19 09:38:36 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Jul 2010 09:38:36 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-27946 ] gem install hangs
	indefinitely on a NAT-ed machine
Message-ID: <20100719133836.0E6761858389@rubyforge.org>

Bugs item #27946, was opened at 2010-03-09 11:59
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bret Weinraub (bretweinraub)
Assigned to: Nobody (None)
Summary: gem install hangs indefinitely on a NAT-ed machine

Initial Comment:
As described in this thread from ruby forum:

http://www.ruby-forum.com/topic/204146



----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-19 13:38

Message:
I'm going to have to close this up unless I get more info to be able to replicate it locally.

----------------------------------------------------------------------

Comment By: Bradly Feeley (bradly)
Date: 2010-03-15 23:18

Message:
I've started seeing this today on an ec2 instance running Ubuntu.

----------------------------------------------------------------------

Comment By: James Tucker (raggi)
Date: 2010-03-11 10:45

Message:
It seems to not be "NAT'd machines", being that every developer behind a router / on wireless is generally NAT'd.

That being said, the multiple layers of NAT can introduce more problems.

We do need to get to the bottom of this issue, however, it very much seems that this is a problem on a lower layer than our app layer.

It's possible that read(2) is causing some kind of blocking issue in some connection teardown / nat mapping release. On that note, it's worth mentioning that a lot (but far from all) of the complaints are linux in a VM on win32.

My first question, given the seemingly repeatable failure caused by using NAT rather than bridged mode, is what class of NAT is actually being used, is it symmetric / asymmetric, full / partial cone, etc?

Also, are you running any ipv6?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=27946&group_id=126

From noreply at rubyforge.org  Mon Jul 19 12:45:23 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Jul 2010 12:45:23 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28404 ] Gem build does not
	check version carefully enough
Message-ID: <20100719164523.C6DF3185838B@rubyforge.org>

Bugs item #28404, was opened at 19/07/2010 18:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pierre Baillet (octplane)
Assigned to: Nobody (None)
Summary: Gem build does not check version carefully enough

Initial Comment:
Hi,

When building a gem, Gem should check that the version indicated by the gem builder is the same as the Gem computed one. If this is not the case, then things can go weird later:

- On one of our server, we have a Gem server that contains genx4r version "0.05" and another library mongo_report version "0.5".

- Because of the way the Gem::Version comparator is implemented (and I think this way is correct today), the two version are identical

- When building the Gem server indices, the Marshal compress method attempts to create as less objects as possible and will reuse objects that already exists when assembling the specs

- In out case this result is assigning version "0.05" to mongo_report. The gem cannot be installed anymore.

I've forked rubygems on github ( following jbarnette suggestion on IRC) and implemented a very crude algorithm to check that the computed version number is the same as the one provided by the gem builder.

http://github.com/octplane/rubygems/commit/cc332c3165cadea8766cc54b42db78ba8dc53375

Please feel free to integrate this patch in the master if you feel this is useful.

Thank your for rubygem,
-- 
Pierre 
Admin at fotopedia.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28404&group_id=126

From noreply at rubyforge.org  Tue Jul 20 17:41:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Jul 2010 17:41:14 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100720214115.029991858385@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 21:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Tue Jul 20 18:33:18 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Jul 2010 18:33:18 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100720223318.47586185837F@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-07-20 19:33

Message:
rspec prerelease include the binary in rspec-core and is named rspec, not spec anymore.

http://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec#L16

The spec stub:


gem 'rspec', version
load Gem.bin_path('rspec', 'spec', version)

Can't know that rspec gem no longer provide the binary needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Tue Jul 20 21:39:57 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Jul 2010 21:39:57 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100721013957.23274185835A@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 21:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

>Comment By: Roger Pack (rogerdpack)
Date: 2010-07-21 01:39

Message:
The spec stub can't but Gem.bin_path could, I believe, by 
looking it up in the gemspecs.


----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-07-20 22:33

Message:
rspec prerelease include the binary in rspec-core and is named rspec, not spec anymore.

http://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec#L16

The spec stub:


gem 'rspec', version
load Gem.bin_path('rspec', 'spec', version)

Can't know that rspec gem no longer provide the binary needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Wed Jul 21 06:35:51 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Jul 2010 06:35:51 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100721103551.911F91858363@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 23:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-07-21 12:35

Message:
for the same reason the rails team moved the wrapper script back from railties to the rails package. as it also broke older rails versions.

So I would say close this bug and open a bug with the rspec team.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-07-21 03:39

Message:
The spec stub can't but Gem.bin_path could, I believe, by 
looking it up in the gemspecs.


----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-07-21 00:33

Message:
rspec prerelease include the binary in rspec-core and is named rspec, not spec anymore.

http://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec#L16

The spec stub:


gem 'rspec', version
load Gem.bin_path('rspec', 'spec', version)

Can't know that rspec gem no longer provide the binary needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Wed Jul 21 06:36:40 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Jul 2010 06:36:40 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100721103640.094ED1858363@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 23:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-07-21 12:36

Message:
and maybe document the requirement that you cant change the package of a script without breaking older versions.

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-07-21 12:35

Message:
for the same reason the rails team moved the wrapper script back from railties to the rails package. as it also broke older rails versions.

So I would say close this bug and open a bug with the rspec team.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-07-21 03:39

Message:
The spec stub can't but Gem.bin_path could, I believe, by 
looking it up in the gemspecs.


----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-07-21 00:33

Message:
rspec prerelease include the binary in rspec-core and is named rspec, not spec anymore.

http://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec#L16

The spec stub:


gem 'rspec', version
load Gem.bin_path('rspec', 'spec', version)

Can't know that rspec gem no longer provide the binary needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Thu Jul 22 06:57:49 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Jul 2010 06:57:49 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100722105749.37D6D185838D@rubyforge.org>

Bugs item #28411, was opened at 2010-07-20 21:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: unable to run a gem bin/xxx when newer version

Initial Comment:
Here's what occurs currently:
$ gem install rspec
$ gem install rspec --pre
$ spec

c:/ruby19/lib/ruby/site_ruby/1.9.1/rubygems.rb:335:in `bin_path': can't find executable spec for rspec-2.0.0.beta.17 (Gem::Exception)
        from c:/ruby19/lib/ruby/site_ruby/1.9.1/faster_rubygems/prelude_bin_path.rb:44:in `bin_path'
        from c:/ruby19/bin/spec:19:in `<main>'


Unless there's a new requirement I'm not aware of that newer versions *have* to have any binary scripts that all previous versions had.

Thanks much.
-r

----------------------------------------------------------------------

>Comment By: James Tucker (raggi)
Date: 2010-07-22 10:57

Message:
This is definitely a bug in rubygems, although not entirely trivial to solve. I will have a think about it, certainly bin_path should make it easier.

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-07-21 10:36

Message:
and maybe document the requirement that you cant change the package of a script without breaking older versions.

----------------------------------------------------------------------

Comment By: Marcus Rueckert (darix)
Date: 2010-07-21 10:35

Message:
for the same reason the rails team moved the wrapper script back from railties to the rails package. as it also broke older rails versions.

So I would say close this bug and open a bug with the rspec team.

----------------------------------------------------------------------

Comment By: Roger Pack (rogerdpack)
Date: 2010-07-21 01:39

Message:
The spec stub can't but Gem.bin_path could, I believe, by 
looking it up in the gemspecs.


----------------------------------------------------------------------

Comment By: Luis Lavena (luislavena)
Date: 2010-07-20 22:33

Message:
rspec prerelease include the binary in rspec-core and is named rspec, not spec anymore.

http://github.com/rspec/rspec-core/blob/master/rspec-core.gemspec#L16

The spec stub:


gem 'rspec', version
load Gem.bin_path('rspec', 'spec', version)

Can't know that rspec gem no longer provide the binary needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28411&group_id=126

From noreply at rubyforge.org  Thu Jul 22 08:44:08 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Jul 2010 08:44:08 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28414 ] RubyGems 1.3.7
	default gem directory is wrong when used with ruby 1.9.1 with
	--program-suffix=1.9
Message-ID: <20100722124408.3F43B1858356@rubyforge.org>

Bugs item #28414, was opened at 2010-07-22 15:44
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Svetoslav Agafonkin (svetlyo)
Assigned to: Nobody (None)
Summary: RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9

Initial Comment:
RubyGems 1.3.7 default gem directory is wrong when used with ruby 1.9.1 with --program-suffix=1.9.

Gem.default_dir generates "/opt/local/lib/ruby/gems/1.9.1/"  instead of "/opt/local/lib/ruby1.9/gems/1.9.1/".

The change was introduced in lib/rubygems/defaults.rb in

http://github.com/rubygems/rubygems/commit/0495c7c0dd9878f9a7a74f5133d7892d28d01812

- a big import from the ruby trunk, right after 1.3.6 was released.

The original change comes from this commit:
http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=26048


---------------------
Mac OS X 10.5.8
ruby 1.9.1_429 (from Macports)
rubgygems 1.3.7

$ gem1.9 env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.1 (2010-07-02 patchlevel 429) [i386-darwin9]
  - INSTALLATION DIRECTORY: /opt/local/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /opt/local/bin/ruby1.9
  - EXECUTABLE DIRECTORY: /opt/local/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /opt/local/lib/ruby/gems/1.9.1
     - /Users/fro/.gem/ruby/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28414&group_id=126

From noreply at rubyforge.org  Sat Jul 24 21:36:14 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Jul 2010 21:36:14 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28419 ] gem install and gem
	update commands fail
Message-ID: <20100725013614.1DB2B1858372@rubyforge.org>

Bugs item #28419, was opened at 2010-07-24 19:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Radu Popescu (radascuta)
Assigned to: Nobody (None)
Summary: gem install and gem update commands fail

Initial Comment:
I get this error when trying to upgrade to Rail 2.2.2 from 2.0.2:

Updating installed gems...
ERROR:  While executing gem ... (Gem::RemoteSourceException)
    HTTP Response 301 fetching http://gems.rubyforge.org/yaml

I get the very same error for both %>gem install rails --version 2.2.2 and %>gem update rails.

Any ideas? 
Thank you. 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

From noreply at rubyforge.org  Sat Jul 24 21:52:26 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Jul 2010 21:52:26 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28419 ] gem install and gem
	update commands fail
Message-ID: <20100725015226.3A9491678316@rubyforge.org>

Bugs item #28419, was opened at 2010-07-24 22:36
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Radu Popescu (radascuta)
Assigned to: Nobody (None)
Summary: gem install and gem update commands fail

Initial Comment:
I get this error when trying to upgrade to Rail 2.2.2 from 2.0.2:

Updating installed gems...
ERROR:  While executing gem ... (Gem::RemoteSourceException)
    HTTP Response 301 fetching http://gems.rubyforge.org/yaml

I get the very same error for both %>gem install rails --version 2.2.2 and %>gem update rails.

Any ideas? 
Thank you. 

----------------------------------------------------------------------

>Comment By: Luis Lavena (luislavena)
Date: 2010-07-24 22:52

Message:
Please update your gem sources to http://rubygems.org, removing the gems.rubyforge.org source.

Gem sources are in ~/.gemrc


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28419&group_id=126

From nick at quaran.to  Thu Jul 29 00:39:24 2010
From: nick at quaran.to (Nick Quaranto)
Date: Thu, 29 Jul 2010 00:39:24 -0400
Subject: [Rubygems-developers] gem install --development ?
Message-ID: <AANLkTik4TdVTXsKzNNgYRVDfhpq2gpSswwPz6L-Z5-mO@mail.gmail.com>

Does this...work?

/tmp % gem install paperclip --development -V
GET http://rubygems.org/latest_specs.4.8.gz
302 Found
GET http://production.s3.rubygems.org/latest_specs.4.8.gz
304 Not Modified
GET http://rubygems.org/specs.4.8.gz
302 Found
GET http://production.s3.rubygems.org/specs.4.8.gz
304 Not Modified

Installing gem hoe-2.6.1
ERROR:  Error installing paperclip:
        hoe requires minitest (>= 1.6.0, development)

Seems like paperclip's development dependency hits sqlite3-ruby, which has a
dev dependency on hoe, which has a dev dependency on minitest, which has a
dev dependency on hoe....

Any ideas on what we can do to make this work once again?

From luislavena at gmail.com  Thu Jul 29 08:53:02 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 29 Jul 2010 09:53:02 -0300
Subject: [Rubygems-developers] gem install --development ?
In-Reply-To: <AANLkTik4TdVTXsKzNNgYRVDfhpq2gpSswwPz6L-Z5-mO@mail.gmail.com>
References: <AANLkTik4TdVTXsKzNNgYRVDfhpq2gpSswwPz6L-Z5-mO@mail.gmail.com>
Message-ID: <AANLkTin3B=ZQXX2WLCiRnCAU2wsCoKQd9+HY=g9y=izn@mail.gmail.com>

On Thu, Jul 29, 2010 at 1:39 AM, Nick Quaranto <nick at quaran.to> wrote:
> Does this...work?
>
> /tmp % gem install paperclip --development -V
> GET http://rubygems.org/latest_specs.4.8.gz
> 302 Found
> GET http://production.s3.rubygems.org/latest_specs.4.8.gz
> 304 Not Modified
> GET http://rubygems.org/specs.4.8.gz
> 302 Found
> GET http://production.s3.rubygems.org/specs.4.8.gz
> 304 Not Modified
>
> Installing gem hoe-2.6.1
> ERROR: ?Error installing paperclip:
> ? ? ? ?hoe requires minitest (>= 1.6.0, development)
>
> Seems like paperclip's development dependency hits sqlite3-ruby, which has a
> dev dependency on hoe, which has a dev dependency on minitest, which has a
> dev dependency on hoe....
>
> Any ideas on what we can do to make this work once again?

I believe this is similar to the recursive runtime dependency issue we
had with 1.3.5:

http://rubyforge.org/pipermail/rubygems-developers/2009-December/005132.html

Seems we need an example for development dependencies too.

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

From transfire at gmail.com  Sat Jul 31 11:52:50 2010
From: transfire at gmail.com (Trans)
Date: Sat, 31 Jul 2010 08:52:50 -0700 (PDT)
Subject: [Rubygems-developers] Deactivate RDoc Generation
Message-ID: <c282bb4b-438f-46cf-b8fb-3fa3d43d542e@z10g2000yqb.googlegroups.com>

Is there a way to globally turn off RDoc generation on install?

Side thought: With the advent of everything "cloud", it seems like
generating the RDocs would be better as an option to turn on, rather
than off. Also consider that YARD is getting more play, and Tomdoc
looks like it could become a player down the road too.



From luislavena at gmail.com  Sat Jul 31 13:07:59 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 31 Jul 2010 14:07:59 -0300
Subject: [Rubygems-developers] Deactivate RDoc Generation
In-Reply-To: <c282bb4b-438f-46cf-b8fb-3fa3d43d542e@z10g2000yqb.googlegroups.com>
References: <c282bb4b-438f-46cf-b8fb-3fa3d43d542e@z10g2000yqb.googlegroups.com>
Message-ID: <AANLkTi=TZGD2s5r3pMn6fq=L6DMwj=7-_AnOTocFBHKE@mail.gmail.com>

On Sat, Jul 31, 2010 at 12:52 PM, Trans <transfire at gmail.com> wrote:
> Is there a way to globally turn off RDoc generation on install?
>

in ~/.gemrc --no-ri --no-rdoc for install and update commands

> Side thought: With the advent of everything "cloud", it seems like
> generating the RDocs would be better as an option to turn on, rather
> than off. Also consider that YARD is getting more play, and Tomdoc
> looks like it could become a player down the road too.
>

I was working on a post_install hook to generate a sqlite3-driven YARD
index, powered by a small sinatra app, but is just for Windows. :-P

Stole the idea from Aaron Patterson who uses that in nokogiri:

http://github.com/tenderlove/rdocsql

http://nokogiri.org/


-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry