From transfire at gmail.com  Mon Aug  2 04:22:54 2010
From: transfire at gmail.com (Trans)
Date: Mon, 2 Aug 2010 01:22:54 -0700 (PDT)
Subject: [Rubygems-developers] Can't pull down gemspec
Message-ID: <c293fa66-4d8f-4005-8ff6-a6c357d2429b@a4g2000prm.googlegroups.com>

Well, I've tried everything I can think of, but I can't seem to find a
way to pull down the gemspec of a specific version of a gem. All I can
get is the most recent version.

  $ gem spec --remote turn

But

  $ gem spec --remote turn -v0.5.1
  ERROR:  Unknown gem 'turn'

Any ideas?

From thewoolleyman at gmail.com  Mon Aug  2 11:52:11 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 2 Aug 2010 08:52:11 -0700
Subject: [Rubygems-developers] Can't pull down gemspec
In-Reply-To: <c293fa66-4d8f-4005-8ff6-a6c357d2429b@a4g2000prm.googlegroups.com>
References: <c293fa66-4d8f-4005-8ff6-a6c357d2429b@a4g2000prm.googlegroups.com>
Message-ID: <AANLkTinpJ74X_7RHL6QP5x8P691TmLeTZYtFfdUEpDgo@mail.gmail.com>

On Mon, Aug 2, 2010 at 1:22 AM, Trans <transfire at gmail.com> wrote:
> Well, I've tried everything I can think of, but I can't seem to find a
> way to pull down the gemspec of a specific version of a gem. All I can
> get is the most recent version.
>
> ?$ gem spec --remote turn
>
> But
>
> ?$ gem spec --remote turn -v0.5.1
> ?ERROR: ?Unknown gem 'turn'
>
> Any ideas?

Yeah, strange behavior.  Seems like a bug in the argument parsing for
the spec command.

From transfire at gmail.com  Mon Aug  2 13:01:16 2010
From: transfire at gmail.com (Trans)
Date: Mon, 2 Aug 2010 10:01:16 -0700 (PDT)
Subject: [Rubygems-developers] Dependency Resolution
Message-ID: <240d8029-1b6a-46b8-b467-19996fa5a751@u31g2000pru.googlegroups.com>

Hi--

I wrote up some code for doing dependency resolution. Right now I am
using my own Version class to do the constraint comparisons, but it
shouldn't too hard to adapt to RubyGems'.

    def rubygems_resolve
      requests = []
      matches  = []
      missing  = []
      gems.each do |name, constraint|
        gem_dep  = Gem::Dependency.new(name, [constraint])
        rubygems_resolve_gem(gem_dep, requests, matches, missing)
      end
      libs = matches.group_by{ |spec| spec.name }
      requests.each do |name, constraint|
        next unless libs[name]
        libs[name].reject! do |spec|
          !Gemdo::VersionNumber.new(spec.version.to_s).match?
(constraint.to_s)
        end
      end
      libs.each do |name, specs|
        print "#{name} ("
        print specs.sort.reverse.map{ |spec|
"#{spec.version}" }.join(', ')
        print ")"
        puts
      end
      missing.each do |gem_dep|
        puts "#{gem_dep.name} ()"
      end
    end

    # recursive resolution of dependencies
    def rubygems_resolve_gem(gem_dep, requests=[], matches=[],
missing=[])
      requests << [gem_dep.name, gem_dep.requirement]
      list = Gem.source_index.find_name(gem_dep.name,
gem_dep.requirement)
      missing << gem_dep if list.empty?
      matches.concat(list)
      list.each do |spec|
        next if matches.include?(spec)
        spec.runtime_dependencies.each do |dep_gem|
          next if missing.include?(gem_dep)
          rubygems_resolve_gem(dep_gem, matches, missing)
        end
        spec.development_dependencies.each do |dep_gem|
          next if missing.include?(gem_dep)
          rubygems_resolve_gem(dep_gem, matches, missing)
        end
      end
    end

The `gems` method used on the fifth line just returns a list of the
current project requirements in an assoc list of [foo, '>= 1.0']
format.

Currently this code only works against installed gems. To work really
well it would need to support remote lookup too. I haven't endeavored
into that b/c of the bug I ran into that I mentioned in my last post.
Any advice on adding that would be appreciated though.

With a bit of tweaking perhaps this can get into the RubyGems?

While I am on the subject, the Gemdo::Version class I'm using can
handle version constraints in these formats:

  1.0+   (same as >= 1.0)
  1.0-    (same as < 1.0)
  1.0~   (same as ~> 1.0)

It would very nice if RubyGems could handle constraints like that at
well.


From luislavena at gmail.com  Mon Aug  2 13:10:38 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 2 Aug 2010 14:10:38 -0300
Subject: [Rubygems-developers] Can't pull down gemspec
In-Reply-To: <AANLkTinpJ74X_7RHL6QP5x8P691TmLeTZYtFfdUEpDgo@mail.gmail.com>
References: <c293fa66-4d8f-4005-8ff6-a6c357d2429b@a4g2000prm.googlegroups.com>
	<AANLkTinpJ74X_7RHL6QP5x8P691TmLeTZYtFfdUEpDgo@mail.gmail.com>
Message-ID: <AANLkTi=WuDea7ZQZE6UrNYP5EVySGQLcYqMD8LcyGj=F@mail.gmail.com>

On Mon, Aug 2, 2010 at 12:52 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Mon, Aug 2, 2010 at 1:22 AM, Trans <transfire at gmail.com> wrote:
>> Well, I've tried everything I can think of, but I can't seem to find a
>> way to pull down the gemspec of a specific version of a gem. All I can
>> get is the most recent version.
>>
>> ?$ gem spec --remote turn
>>
>> But
>>
>> ?$ gem spec --remote turn -v0.5.1
>> ?ERROR: ?Unknown gem 'turn'
>>
>> Any ideas?
>
> Yeah, strange behavior. ?Seems like a bug in the argument parsing for
> the spec command.

spec is supposed to take --all argument

By default spec will use the latest version in the gem in the quick
index, so --all should do the trick, but it doesn't work.
-- 
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  Tue Aug  3 05:25:52 2010
From: jftucker at gmail.com (James Tucker)
Date: Tue, 3 Aug 2010 10:25:52 +0100
Subject: [Rubygems-developers] Dependency Resolution
In-Reply-To: <240d8029-1b6a-46b8-b467-19996fa5a751@u31g2000pru.googlegroups.com>
References: <240d8029-1b6a-46b8-b467-19996fa5a751@u31g2000pru.googlegroups.com>
Message-ID: <9F4DD5D2-9996-41C6-B135-477F0ECCD655@gmail.com>


On 2 Aug 2010, at 18:01, Trans wrote:

> Hi--
> 
> I wrote up some code for doing dependency resolution. Right now I am
> using my own Version class to do the constraint comparisons, but it
> shouldn't too hard to adapt to RubyGems'.
> With a bit of tweaking perhaps this can get into the RubyGems?

I'd like to see a runtime dependency tree resolver in RubyGems, but if we are to include one, I would like it to resolve some complex graphs:

 - Cycles
 - Troughs
 - Traps

A completely linear resolver I don't think can do this. You might want to read through the comments in the resolver in bundler, and it's test suite, to see what I'm talking about.

> While I am on the subject, the Gemdo::Version class I'm using can
> handle version constraints in these formats:
> 
>  1.0+   (same as >= 1.0)
>  1.0-    (same as < 1.0)
>  1.0~   (same as ~> 1.0)

I like this, I would say though, adding this could have quite a marked effect on performance with the current design, as Gem::Version is created and parsed all the time.


From transfire at gmail.com  Wed Aug  4 02:31:18 2010
From: transfire at gmail.com (Trans)
Date: Tue, 3 Aug 2010 23:31:18 -0700 (PDT)
Subject: [Rubygems-developers] Dependency Resolution
In-Reply-To: <9F4DD5D2-9996-41C6-B135-477F0ECCD655@gmail.com>
References: <240d8029-1b6a-46b8-b467-19996fa5a751@u31g2000pru.googlegroups.com>
	<9F4DD5D2-9996-41C6-B135-477F0ECCD655@gmail.com>
Message-ID: <831b9eac-c32f-4d80-b3ea-c28df1e38984@i31g2000yqm.googlegroups.com>



On Aug 3, 5:25?am, James Tucker <jftuc... at gmail.com> wrote:
> On 2 Aug 2010, at 18:01, Trans wrote:
>
> > Hi--
>
> > I wrote up some code for doing dependency resolution. Right now I am
> > using my own Version class to do the constraint comparisons, but it
> > shouldn't too hard to adapt to RubyGems'.
> > With a bit of tweaking perhaps this can get into the RubyGems?
>
> I'd like to see a runtime dependency tree resolver in RubyGems, but if we are to include one, I would like it to resolve some complex graphs:
>
> ?- Cycles
> ?- Troughs
> ?- Traps
>
> A completely linear resolver I don't think can do this. You might want to read through the comments in the resolver in bundler, and it's test suite, to see what I'm talking about.

I'll take a look, thanks.

The resolver I wrote recurses through the dependency tree adding each
dependency to a flat 'request' list, unless an entry already exists
with the same exact name and constraint, in which case the recursion
backtracks. At the same time it collects every available version of a
gem by that name. It then works through the request list rejecting
versions that don't conform, leaving in the final result only the
viable versions (or an empty list if none). I've thought about a good
bit, and I can't think of a way in which that wouldn't work. Perhaps b/
c it is a two-pass solution, it mitigates that fact that it is linear?
But yea, I could be missing something. I'll read up and write some
tests to be sure.

> > While I am on the subject, the Gemdo::Version class I'm using can
> > handle version constraints in these formats:
>
> > ?1.0+ ? (same as >= 1.0)
> > ?1.0- ? ?(same as < 1.0)
> > ?1.0~ ? (same as ~> 1.0)
>
> I like this, I would say though, adding this could have quite a marked effect on performance with the current design, as Gem::Version is created and parsed all the time.

I wouldn't think it would be any more difficult to parse than the
currently accepted formats, but then I'm not sure how it's coded, so
you might be right. Even so I wouldn't expect it be too much overhead.
One could map it pretty easily. Something like:

  c = { '+'=>">=", ... }

  ver = c[ver[-1,1]] + ver[0...-1] if c.key?(ver[-1,1])


From noreply at rubyforge.org  Sat Aug  7 10:49:24 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  7 Aug 2010 10:49:24 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28454 ] gem install
	--development installs transitive development dependencies
Message-ID: <20100807144924.444FB1858372@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: Nobody (None)
Summary: gem install --development installs transitive development dependencies

Initial Comment:
Currently it appears that if you install a gem with --development, it installs not only its development dependencies, and also its development dependencies' development dependencies (not just runtime).  

This results in a failure, for example not being able to use 

$ jruby -S gem install sensible-cinema --development 

because though all of its development dependencies are jruby friendly, their respective development dependencies are not, and it ends up trying to build binary extensions which don't work, since this is C, but they are for gems that aren't actual development dependencies for sensible-cinema, so I don't need them anyway.

This prevents --development from being useful in this situation.

Suggestion: only install development dependencies' run-time dependencies if --development is passed.
Thanks.
-r

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

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

From noreply at rubyforge.org  Tue Aug 10 14:39:18 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 10 Aug 2010 14:39:18 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Feature Requests-28464 ] gem
	install progress during download phase
Message-ID: <20100810183918.51EA61858377@rubyforge.org>

Feature Requests item #28464, was opened at 2010-08-10 11:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=578&aid=28464&group_id=126

Category: `gem install` command
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Ryan Melton (ryanmelt)
Assigned to: Nobody (None)
Summary: gem install progress during download phase

Initial Comment:
I just released a large binary gem for windows (50Mb - qtbindings) that takes a while to download on slow networks.  During the download, it appears like nothing is happening and "gem install qtbindings" just sits there looking like it is hung up.  It would be nice to have a progress bar during the download phase of gem installation.

Thanks,
Ryan

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

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

From rubygems at freeze.org  Sun Aug 15 14:34:36 2010
From: rubygems at freeze.org (Jim Freeze)
Date: Sun, 15 Aug 2010 13:34:36 -0500
Subject: [Rubygems-developers] Custom Gemspec Attribute
Message-ID: <AANLkTimmZDPjUD+HL_BWwFMctqHFV4RuYNmWcUvdRN7Z@mail.gmail.com>

Hi

Is there a way to add a custom attribute to a gem spec? We want to be
able to define a gem as an adhearsion component so that we can search
all the installed gems that are ahn_components.

-- 
Jim Freeze

From jbarnette at gmail.com  Sun Aug 15 15:05:22 2010
From: jbarnette at gmail.com (John Barnette)
Date: Sun, 15 Aug 2010 12:05:22 -0700
Subject: [Rubygems-developers] Custom Gemspec Attribute
In-Reply-To: <AANLkTimmZDPjUD+HL_BWwFMctqHFV4RuYNmWcUvdRN7Z@mail.gmail.com>
References: <AANLkTimmZDPjUD+HL_BWwFMctqHFV4RuYNmWcUvdRN7Z@mail.gmail.com>
Message-ID: <AANLkTi=GaWRmqxE_RS+2ePch-KmNNpsLFKkFHeekzbx2@mail.gmail.com>

Hey Jim,

On Sun, Aug 15, 2010 at 11:34 AM, Jim Freeze <rubygems at freeze.org> wrote:
> Is there a way to add a custom attribute to a gem spec? We want to be
> able to define a gem as an adhearsion component so that we can search
> all the installed gems that are ahn_components.

Not right now, no. I've had a branch that adds a #meta hash to
Specification around for a while, but changing gemspec is fraught with
terror and I haven't been brave enough to merge it yet. :(

You can fake it with the current version of RubyGems by using
Gem#find_files and examining the paths that it returns. Keep in mind
that it looks through ALL available versions of all gems, as well as
the load path. Really really bad example off the top of my head:

# let's pretend all adhearsion components must have a
lib/adhearsion/component.txt file

component_gems = Gem.find_files("adhearsion/component.txt").
  map { |f| %r|/([^/]+)/lib| =~ f && $1.split("-")[0..-2].join("-") }.uniq


~ j.

From ryand-ruby at zenspider.com  Mon Aug 16 03:08:46 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Mon, 16 Aug 2010 00:08:46 -0700
Subject: [Rubygems-developers] Custom Gemspec Attribute
In-Reply-To: <AANLkTi=GaWRmqxE_RS+2ePch-KmNNpsLFKkFHeekzbx2@mail.gmail.com>
References: <AANLkTimmZDPjUD+HL_BWwFMctqHFV4RuYNmWcUvdRN7Z@mail.gmail.com>
	<AANLkTi=GaWRmqxE_RS+2ePch-KmNNpsLFKkFHeekzbx2@mail.gmail.com>
Message-ID: <CB073600-A713-4655-89EF-76CEC8238F4F@zenspider.com>


On Aug 15, 2010, at 12:05 , John Barnette wrote:

> You can fake it with the current version of RubyGems by using
> Gem#find_files and examining the paths that it returns. Keep in mind
> that it looks through ALL available versions of all gems, as well as
> the load path. Really really bad example off the top of my head:

all _installed_ gems.

Since the gem index you download doesn't have package contents, this won't help for remote gem searches.


From jbarnette at gmail.com  Mon Aug 16 10:29:05 2010
From: jbarnette at gmail.com (John Barnette)
Date: Mon, 16 Aug 2010 07:29:05 -0700
Subject: [Rubygems-developers] Custom Gemspec Attribute
In-Reply-To: <CB073600-A713-4655-89EF-76CEC8238F4F@zenspider.com>
References: <AANLkTimmZDPjUD+HL_BWwFMctqHFV4RuYNmWcUvdRN7Z@mail.gmail.com>
	<AANLkTi=GaWRmqxE_RS+2ePch-KmNNpsLFKkFHeekzbx2@mail.gmail.com>
	<CB073600-A713-4655-89EF-76CEC8238F4F@zenspider.com>
Message-ID: <AANLkTimzEm+fTxW+qS7vPCFF6x=0CUCPcHZFQ33Dv69v@mail.gmail.com>

On Mon, Aug 16, 2010 at 12:08 AM, Ryan Davis <ryand-ruby at zenspider.com> wrote:
> On Aug 15, 2010, at 12:05 , John Barnette wrote:
>
>> You can fake it with the current version of RubyGems by using
>> Gem#find_files and examining the paths that it returns. Keep in mind
>> that it looks through ALL available versions of all gems, as well as
>> the load path. Really really bad example off the top of my head:
>
> all _installed_ gems.
>
> Since the gem index you download doesn't have package contents, this won't help for remote gem searches.

Oops, yeah, looking through the file list on the spec itself for a
token is a lot better.


~ j.

From noreply at rubyforge.org  Tue Aug 17 08:21:50 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 17 Aug 2010 08:21:50 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28481 ] 'gem install' always
	prefers local files with partial name match
Message-ID: <20100817122152.712AB185837D@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Hirotsugu Asari (asarih)
Assigned to: Nobody (None)
Summary: 'gem install' always prefers local files with partial name match

Initial Comment:
If you try to install gem with a shorter name (e.g., active_form) from a remote server but you have a .gem file of another gem with a longer name (e.g., active_forms) in the working directory, 'gem install' will use the gem file. The exact match should be preferred.

$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_forms-0.2.1.gem
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed
$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_form
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed

This was first reported by Stephen Bannasch in http://jira.codehaus.org/browse/JRUBY-4934.

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

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

From noreply at rubyforge.org  Wed Aug 18 18:27:00 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 18 Aug 2010 18:27:00 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28485 ] gem push is hardcoded
	to use GemCutter.
Message-ID: <20100818222700.B8BDB1858368@rubyforge.org>

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

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: robert gleeson (robgleeson)
Assigned to: Nobody (None)
Summary: gem push is hardcoded to use GemCutter.

Initial Comment:
The RubyGems command `push` is hard-coded to use GemCutter as its destination. 
We talked about this on IRC and you confirmed that it is a bug.

Rob

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

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

From noreply at rubyforge.org  Wed Aug 18 19:21:39 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 18 Aug 2010 19:21:39 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28485 ] gem push is hardcoded
	to use GemCutter.
Message-ID: <20100818232139.8D7201858387@rubyforge.org>

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

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: robert gleeson (robgleeson)
Assigned to: Nobody (None)
Summary: gem push is hardcoded to use GemCutter.

Initial Comment:
The RubyGems command `push` is hard-coded to use GemCutter as its destination. 
We talked about this on IRC and you confirmed that it is a bug.

Rob

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

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:21

Message:
Greetings sirs, I have provided a patch for this issue!

http://gist.github.com/536509

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

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

From noreply at rubyforge.org  Wed Aug 18 19:30:46 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 18 Aug 2010 19:30:46 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28485 ] gem push is hardcoded
	to use GemCutter.
Message-ID: <20100818233046.E6D2B1858344@rubyforge.org>

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

Category: other
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: robert gleeson (robgleeson)
Assigned to: Nobody (None)
Summary: gem push is hardcoded to use GemCutter.

Initial Comment:
The RubyGems command `push` is hard-coded to use GemCutter as its destination. 
We talked about this on IRC and you confirmed that it is a bug.

Rob

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

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:30

Message:
An update based on some review comments by Eric: http://gist.github.com/536523

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

Comment By: Erik Hollensbe (erikh)
Date: 2010-08-18 16:21

Message:
Greetings sirs, I have provided a patch for this issue!

http://gist.github.com/536509

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

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

From noreply at rubyforge.org  Wed Aug 18 20:29:54 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 18 Aug 2010 20:29:54 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28486 ] unable to use runtime
	dependencies in mkrf_conf.rb
Message-ID: <20100819002954.A2DB21858387@rubyforge.org>

Bugs item #28486, was opened at 2010-08-19 00:29
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28486&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: unable to use runtime dependencies in mkrf_conf.rb

Initial Comment:
Situation currently:

if you have the following in your mkrf_conf.rb file


require 'rubygems'
require 'some dependency gem'

and your gemspec lists "some dependency gem" as a runtime dependency, your gem will fail to install the first time, then install correctly when you attempt to install it a second time.  I would have expected runtime dependencies to be available at build time of the main gem.
Thanks!
-r

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

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

From noreply at rubyforge.org  Thu Aug 19 18:30:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 19 Aug 2010 18:30:01 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28491 ] fetch a specific
	prerelease version
Message-ID: <20100819223001.AAC0F1858361@rubyforge.org>

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

Category: `gem` commands (remote behavior)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: gabriel horner (cldwalker)
Assigned to: Nobody (None)
Summary: fetch a specific prerelease version

Initial Comment:
I can't fetch a specific prerelease version:
  $ gem fetch dm-core -v '1.0.0.rc2' --pre --debug
   Exception `NameError' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:164 - uninitialized constant Gem::Commands::FetchCommand
   Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1450 - invalid option: no-ri
   Exception `OptionParser::InvalidOption' at /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/lib/ruby/1.8/optparse.rb:1263 - invalid option: --no-ri
   ERROR:  Could not find a valid gem 'dm-core' (= 1.0.0.rc2) in any repository
  
I'm aware I can fetch the latest prerelease version: gem fetch dm-core --pre
but I need specific prerelease versions of gems. Is this possible?

FYI, I originally asked about this on help.rubygems.org: http://help.rubygems.org/discussions/questions/38-gem-fetch-a-specific-prerelease-version

My gem environment:

$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin9.4.0]
  - INSTALLATION DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext
  - RUBY EXECUTABLE: /Users/bozo/.rvm/rubies/ruby-1.8.7-p299/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-darwin-9
  - GEM PATHS:
     - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at ext
     - /Users/bozo/.rvm/gems/ruby-1.8.7-p299 at global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "gem" => "--no-ri"
     - :sources => ["http://rubygems.org"]
  - REMOTE SOURCES:
     - http://rubygems.org

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

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

From noreply at rubyforge.org  Fri Aug 20 02:47:51 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 20 Aug 2010 02:47:51 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname
	--remote will fail if gemname is in current directory
Message-ID: <20100820064751.6BB261858375@rubyforge.org>

Bugs item #26109, was opened at 2009-06-02 22:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: ara howard (ahoward)
Assigned to: Nobody (None)
Summary: gem install gemname --remote will fail if gemname is in current directory

Initial Comment:
gem install gemname --remote  will prefer a gem in the current directory.  seems like --remote should *never* do *anything* local?

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

Comment By: Christof Spies (wingfire)
Date: 2010-08-20 06:47

Message:
I can confirm this issue.
i.e. you have an outdated gem file in your home directory and run  "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem.

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

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-27 22:37

Message:
Just familiarizing myself with the code here. I now see the issue.

#find_gems_with_sources probably should only merge gem sources if @domain == :both

also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense

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

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-26 20:54

Message:
I can not reproduce this issue as a "preference". 

Rubygems appears to do remote as requested with requested gem in pwd.

In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.3
  - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby/gems/1.8
     - /home/nihildeb/.gem/ruby/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






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

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

From noreply at rubyforge.org  Fri Aug 20 02:52:39 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 20 Aug 2010 02:52:39 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname
	--remote will fail if gemname is in current directory
Message-ID: <20100820065239.8091E185837B@rubyforge.org>

Bugs item #26109, was opened at 2009-06-02 22:03
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: ara howard (ahoward)
Assigned to: Nobody (None)
Summary: gem install gemname --remote will fail if gemname is in current directory

Initial Comment:
gem install gemname --remote  will prefer a gem in the current directory.  seems like --remote should *never* do *anything* local?

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

Comment By: Christof Spies (wingfire)
Date: 2010-08-20 06:52

Message:
gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby/gems/1.8
     - /root/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/



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

Comment By: Christof Spies (wingfire)
Date: 2010-08-20 06:47

Message:
I can confirm this issue.
i.e. you have an outdated gem file in your home directory and run  "gem update" from home then gem reinstall the old gem from the home directory. "gem update -r" is also "updating" with the outdated local gem.

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

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-27 22:37

Message:
Just familiarizing myself with the code here. I now see the issue.

#find_gems_with_sources probably should only merge gem sources if @domain == :both

also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense

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

Comment By: Nick Hildebrant (nihildeb)
Date: 2009-08-26 20:54

Message:
I can not reproduce this issue as a "preference". 

Rubygems appears to do remote as requested with requested gem in pwd.

In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.3
  - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]
  - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /usr/lib/ruby/gems/1.8
     - /home/nihildeb/.gem/ruby/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






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

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

From noreply at rubyforge.org  Fri Aug 20 02:59:01 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 20 Aug 2010 02:59:01 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28481 ] 'gem install' always
	prefers local files with partial name match
Message-ID: <20100820065901.77CD2185837B@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Hirotsugu Asari (asarih)
Assigned to: Nobody (None)
Summary: 'gem install' always prefers local files with partial name match

Initial Comment:
If you try to install gem with a shorter name (e.g., active_form) from a remote server but you have a .gem file of another gem with a longer name (e.g., active_forms) in the working directory, 'gem install' will use the gem file. The exact match should be preferred.

$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_forms-0.2.1.gem
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed
$ ruby -v -S gem install --ignore-dependencies --no-rdoc --no-ri active_form
ruby 1.8.7 (2010-06-23 patchlevel 299) [i686-darwin10.4.0]
Successfully installed active_forms-0.2.1
1 gem installed

This was first reported by Stephen Bannasch in http://jira.codehaus.org/browse/JRUBY-4934.

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

Comment By: Christof Spies (wingfire)
Date: 2010-08-20 06:59

Message:
seams to be the same bug as #26109 http://rubyforge.org/tracker/index.php?func=detail&aid=26109&group_id=126&atid=575

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

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

From noreply at rubyforge.org  Sat Aug 21 19:41:22 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 21 Aug 2010 19:41:22 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20100821234122.AEF0A1858357@rubyforge.org>

Bugs item #28494, was opened at 22/08/2010 01:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
Assigned to: Nobody (None)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

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

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

From noreply at rubyforge.org  Sat Aug 21 20:25:39 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 21 Aug 2010 20:25:39 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20100822002539.1580D1858354@rubyforge.org>

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

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
>Assigned to: Luis Lavena (luislavena)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

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

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

From jftucker at gmail.com  Sun Aug 22 11:16:15 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 22 Aug 2010 12:16:15 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <20100822002539.1580D1858354@rubyforge.org>
References: <20100822002539.1580D1858354@rubyforge.org>
Message-ID: <9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>

I don't get why the code is not being taken as-is from the RubyGems repository. Sure we have backward compatibility stuff in there, but if I fix this in rubygems now, these modifications will have to be re-applied by core for the sake of a /really/ small optimisation?

On 21 Aug 2010, at 21:25, <noreply at rubyforge.org> <noreply at rubyforge.org> wrote:

> Bugs item #28494, was opened at 2010-08-21 20:41
> You can respond by visiting: 
> http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126
> 
> Category: `gem install` command
> Group: None
> Status: Open
> Resolution: None
> Priority: 3
> Submitted By: Michel Demazure (badal)
>> Assigned to: Luis Lavena (luislavena)
> Summary: C: hard coded in rubygems.rb
> 
> Initial Comment:
> Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :
> 
> in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]
> 
> _md
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126
> _______________________________________________
> 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  Sun Aug 22 11:28:36 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 22 Aug 2010 12:28:36 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <20100822002539.1580D1858354@rubyforge.org>
References: <20100822002539.1580D1858354@rubyforge.org>
Message-ID: <515690A6-8A6D-45B6-9DE4-5F6F31ED621B@gmail.com>

Luis,

Can you confirm that this patch is sane, I think it's more sensible.

Regards,

James

On 21 Aug 2010, at 21:25, <noreply at rubyforge.org> <noreply at rubyforge.org> wrote:

> Bugs item #28494, was opened at 2010-08-21 20:41
> You can respond by visiting: 
> http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126
> 
> Category: `gem install` command
> Group: None
> Status: Open
> Resolution: None
> Priority: 3
> Submitted By: Michel Demazure (badal)
>> Assigned to: Luis Lavena (luislavena)
> Summary: C: hard coded in rubygems.rb
> 
> Initial Comment:
> Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :
> 
> in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]
> 
> _md
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting: 
> http://rubyforge.org/tracker/?func=detail&atid=575&aid=28494&group_id=126
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers


From luislavena at gmail.com  Sun Aug 22 13:35:23 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 22 Aug 2010 14:35:23 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>
References: <20100822002539.1580D1858354@rubyforge.org>
	<9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>
Message-ID: <AANLkTinZJkOQBMyfzBu=WSoF8Xp-QZoe5DVvnS37e6pS@mail.gmail.com>

On Sun, Aug 22, 2010 at 12:16 PM, James Tucker <jftucker at gmail.com> wrote:
> I don't get why the code is not being taken as-is from the RubyGems repository. Sure we have backward compatibility stuff in there, but if I fix this in rubygems now, these modifications will have to be re-applied by core for the sake of a /really/ small optimisation?
>

The issue actually is Ruby implementation of RubyGems, not RubyGems:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L499

For this user scenario, it had defined as HOME just HOMEDRIVE, so
File.expand_path "~" internally in Ruby 1.9.x raised an exception that
failsafe to C:/

A sane alternative will be take the root drive of Gem.ruby itself and not C:/

But again, the discrepancies between Ruby's RubyGems and standalone
RubyGems are bad and not easy to fix follow and fix.

I'm open to suggestions on this, but the patch is not as good I thought.
-- 
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  Sun Aug 22 15:49:48 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 22 Aug 2010 16:49:48 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <AANLkTinZJkOQBMyfzBu=WSoF8Xp-QZoe5DVvnS37e6pS@mail.gmail.com>
References: <20100822002539.1580D1858354@rubyforge.org>
	<9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>
	<AANLkTinZJkOQBMyfzBu=WSoF8Xp-QZoe5DVvnS37e6pS@mail.gmail.com>
Message-ID: <A1F61410-13A9-43E3-A914-535CA1296301@gmail.com>


On 22 Aug 2010, at 14:35, Luis Lavena wrote:

> On Sun, Aug 22, 2010 at 12:16 PM, James Tucker <jftucker at gmail.com> wrote:
>> I don't get why the code is not being taken as-is from the RubyGems repository. Sure we have backward compatibility stuff in there, but if I fix this in rubygems now, these modifications will have to be re-applied by core for the sake of a /really/ small optimisation?
>> 
> 
> The issue actually is Ruby implementation of RubyGems, not RubyGems:
> 
> http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L499

Yup, but the issue exists in both, it is only the pre-amble if RUBY_VERSION < '1.9' that has been removed.

> For this user scenario, it had defined as HOME just HOMEDRIVE, so
> File.expand_path "~" internally in Ruby 1.9.x raised an exception that
> failsafe to C:/

Yup, I see that it must be an exception, and that C:/ is wrong.

> A sane alternative will be take the root drive of Gem.ruby itself and not C:/

If that has a drive too...

> But again, the discrepancies between Ruby's RubyGems and standalone
> RubyGems are bad and not easy to fix follow and fix.

Agreed.

> I'm open to suggestions on this, but the patch is not as good I thought.

Not sure what you want suggestions for. Regarding the ruby <-> rubygems discrepancy I don't see a good reason that such things as this need changing in ruby, I mean, it might be "cleaner" but this kind of change is horrible for debugging.

As far as the code is concerned, see my patch, it should solve the issue in a usable manner. I chose to use the approach of just using '/', as this will address the root of the currently active drive (which must exist at least at process launch). Does this make sense?

I could also expand it out to try just HOMEDRIVE, then fallback to the root of Gem.ruby, then fall back to '/', but this seems long when it would almost be reasonable if all these things are missing, to just raise an exception.

From luislavena at gmail.com  Sun Aug 22 16:12:54 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 22 Aug 2010 17:12:54 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <A1F61410-13A9-43E3-A914-535CA1296301@gmail.com>
References: <20100822002539.1580D1858354@rubyforge.org>
	<9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>
	<AANLkTinZJkOQBMyfzBu=WSoF8Xp-QZoe5DVvnS37e6pS@mail.gmail.com>
	<A1F61410-13A9-43E3-A914-535CA1296301@gmail.com>
Message-ID: <AANLkTik3QvqM193_iVO8NbDfD0xMQq8N0uquQ_gm8DnB@mail.gmail.com>

On Sun, Aug 22, 2010 at 4:49 PM, James Tucker <jftucker at gmail.com> wrote:
>
> As far as the code is concerned, see my patch, it should solve the issue in a usable manner. I chose to use the approach of just using '/', as this will address the root of the currently active drive (which must exist at least at process launch). Does this make sense?
>

There is no patch in all your previous messages or RubyGems tracker, I
had assume you refer to OP suggestion at the tracker.

> I could also expand it out to try just HOMEDRIVE, then fallback to the root of Gem.ruby, then fall back to '/', but this seems long when it would almost be reasonable if all these things are missing, to just raise an exception.

-- 
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  Sun Aug 22 16:26:58 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 22 Aug 2010 17:26:58 -0300
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
In-Reply-To: <AANLkTik3QvqM193_iVO8NbDfD0xMQq8N0uquQ_gm8DnB@mail.gmail.com>
References: <20100822002539.1580D1858354@rubyforge.org>
	<9A2F8720-CCBD-4B1F-BA2F-201F257AE97E@gmail.com>
	<AANLkTinZJkOQBMyfzBu=WSoF8Xp-QZoe5DVvnS37e6pS@mail.gmail.com>
	<A1F61410-13A9-43E3-A914-535CA1296301@gmail.com>
	<AANLkTik3QvqM193_iVO8NbDfD0xMQq8N0uquQ_gm8DnB@mail.gmail.com>
Message-ID: <A0A8734A-D29C-4EFB-9C80-EDB227F5360E@gmail.com>


On 22 Aug 2010, at 17:12, Luis Lavena wrote:

> On Sun, Aug 22, 2010 at 4:49 PM, James Tucker <jftucker at gmail.com> wrote:
>> 
>> As far as the code is concerned, see my patch, it should solve the issue in a usable manner. I chose to use the approach of just using '/', as this will address the root of the currently active drive (which must exist at least at process launch). Does this make sense?
>> 
> 
> There is no patch in all your previous messages or RubyGems tracker, I
> had assume you refer to OP suggestion at the tracker.

Oh, very odd, i think it was filtered, I'll attach to the tracker in the next couple of minutes.

From noreply at rubyforge.org  Sun Aug 22 16:28:41 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 22 Aug 2010 16:28:41 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20100822202841.63B35185835A@rubyforge.org>

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

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
Assigned to: Luis Lavena (luislavena)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

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

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

From noreply at rubyforge.org  Sun Aug 22 16:39:30 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 22 Aug 2010 16:39:30 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20100822203930.24F491858372@rubyforge.org>

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

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
Assigned to: Luis Lavena (luislavena)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

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

>Comment By: Luis Lavena (luislavena)
Date: 2010-08-22 17:39

Message:
Hello James,

I believe the only missing thing is File.expand_path around the values from ENV, as master branch have:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L501-507

But looks valid for a solution.

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

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

From noreply at rubyforge.org  Sun Aug 22 22:17:35 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 22 Aug 2010 22:17:35 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28494 ] C: hard coded in
	rubygems.rb
Message-ID: <20100823021735.60B401858376@rubyforge.org>

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

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michel Demazure (badal)
Assigned to: Luis Lavena (luislavena)
Summary: C: hard coded in rubygems.rb

Initial Comment:
Rubygems 1.3.7 bundled in ruby 1.9.2 p0 :

in rubygems.rb, line 500, 'C:' should be 'ENV["HOMEDRIVE"]

_md

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

>Comment By: James Tucker (raggi)
Date: 2010-08-23 02:17

Message:
Ah yes, sorry, I should have pulled. I will update and commit tomorrow, thanks Luis.

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

Comment By: Luis Lavena (luislavena)
Date: 2010-08-22 20:39

Message:
Hello James,

I believe the only missing thing is File.expand_path around the values from ENV, as master branch have:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems.rb#L501-507

But looks valid for a solution.

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

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

From luislavena at gmail.com  Tue Aug 31 21:03:26 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 31 Aug 2010 22:03:26 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
Message-ID: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>

Hello,

I was wondering which will the fate of RubyGems bug tracker at RubyForge.

Also, is anyone getting any pull request for RubyGems?.

Asking this due this interesting commit in a fork:

http://github.com/gstark/rubygems/commit/483fdb5223a3c17e2b0ebb5dd02cb1e228498517

Which could provide some hint to users installing gems and misspelling them.

There are comments there from authors of similar solutions.

Thank you for your attention.
-- 
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 clint at ubuntu.com  Thu Aug 26 14:34:00 2010
From: clint at ubuntu.com (Clint Byrum)
Date: Thu, 26 Aug 2010 18:34:00 -0000
Subject: [Rubygems-developers] rubygems and FHS compliance in Debian and
	Ubuntu
Message-ID: <7EB961E3-F5F1-4E9A-847F-C6C70FA334A3@ubuntu.com>

ABSTRACT

This proposal seeks to clarify the current state of the rubygems package
in Debian and Ubuntu, and provide a clear path toward full FHS compliance
and usability for users.

CURRENT STATUS

Rubygems is a tool used by ruby users to download and install ruby
modules in much the same way CPAN works for Perl, and pypi/easy_install
works for python. A developer may create a "gem" that encompasses their
software module, and publish it into the rubygems repository. Ruby users
have grown to use this as their primary source of software modules,
and as such, it is so important that it is now included with Ruby 1.9,
the latest stable release of Ruby.

One component of these modules is executable scripts. These scripts are
provided to users to perform essential functions related to whatever
module they are packaged with, or sometimes the script itself is the
entire point of the module, as is the case with the 'rails' gem, which
installs a web framework and application server. Rubygems actually
generates the files that go in to its "bindir" so that they are pointed
at the desired ruby binary.

In the upstream default install of rubygems, the default location for
these binaries and rubygems library files is /usr/bin, and /usr/lib
respectively. This places the binaries in the default shell path for most
FHS systems, so that users can have an experience something like this:

$ sudo gem install rails [... gem downloads and installs rails ... ]
$ rails my-facebook-killer-app/ [... A skeleton of a rails app is
created ...  ... I Start hacking on my-facebook-killer-app ...]

A few years ago, these two bugs were filed, and fixed, in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458987

These were fixed by having rubygems change its default path, to
/var/lib/gems/$ruby_version

This definitely address the users' issue, which was basically "I don't
want the rubygems package manager to be able to easily conflict with
the debian package manager."

However, this introduced an incompatibility with the FHS definition of
the purpose of /var[1].

"/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary files.

Some portions of /var are not shareable between different systems. For
instance, /var/log, /var/lock, and /var/run. Other portions may be shared,
notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.

/var is specified here in order to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to during
system operation (as opposed to installation and software maintenance)
must be in /var."

And further, the purpose of /var/lib

"This hierarchy holds state information pertaining to an application or
the system. State information is data that programs modify while they
run, and that pertains to one specific host. Users must never need to
modify files in /var/lib to configure a package's operation.

State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between invocations
and between different instances of the same application. State information
should generally remain valid after a reboot, should not be logging
output, and should not be spooled data."

While the terms used are certainly open to interpretation, its difficult
to argue that executable scripts and libraries constitute "state
information that programs modify while they run and that pertains to
one specific host".

This potential issue with FHS compliance means rubygems may be in
violation of Section 9.1 of the debian policy manual:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1

Whats more, users do not expect to find executable scripts in /var. The
default path on current Debian systems is as follows:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and on Ubuntu:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Adding entries to the path is a non-trivial activity that most users
won't do in a way that makes their system maintainable or flexible over
a long period of time.

PROPOSED SOLUTION

Rubygems in Debian and Ubuntu should place gems in /usr/local/lib/gems
and gem executables in /usr/local/bin.

FHS defines the purpose of /usr/local as such:

"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than
/usr unless it is being installed to replace or upgrade software in /usr."

Placing installed gems in /usr/local/lib/gems and /usr/local/bin, would
allow rubygems to maintain FHS compliance, and avoid the problem of
users accidentally overwriting dpkg installed files. This would seem a
"win win" for all issues involved.

Because the default path in the shell on most systems includes
/usr/local/bin, this would ease users' experience, and allow system
administrators to use both rubygems and dpkg/apt in the same way,
without having them conflict.

--

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html


From lucas at lucas-nussbaum.net  Sat Aug 28 02:56:05 2010
From: lucas at lucas-nussbaum.net (Lucas Nussbaum)
Date: Sat, 28 Aug 2010 08:56:05 +0200
Subject: [Rubygems-developers] Bug#588125: Rubygems 1.3.7 broken with
 Ruby 1.9.2 in Debian -- help needed
In-Reply-To: <AANLkTimBC81SPbByKTct-MVPH1EemXm-OM30vaC8cDsJ@mail.gmail.com>
References: <20100825195203.GB16194@xanadu.blop.info>
	<AANLkTimBC81SPbByKTct-MVPH1EemXm-OM30vaC8cDsJ@mail.gmail.com>
Message-ID: <20100828065605.GA5733@xanadu.blop.info>

On 26/08/10 at 08:25 +0900, akira yamada wrote:
> 2010/8/26 Lucas Nussbaum <lucas at lucas-nussbaum.net>:
> > That worked fine until Ruby 1.9.1, but apparently a change in Ruby
> > 1.9.2 broke Rubygems 1.3.7. This is exhibited by two bugs:
> [...]
> > - rubygems doesn't work:
> > ?http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588125
> 
> I trace the following error:
> --
> $ gem1.9.1 list
> /usr/lib/ruby/1.9.1/rubygems.rb:634:in `path': undefined method `path'
> for #<Gem::ConfigFile:0x000000014a09d8> (NoMethodError)
> --
> 
> I got a result:
> --
> $ ruby1.9.1 -e 'p Gem.path; require "rubygems"; p Gem.path'
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:68:in
> `installed_spec_directories': undefined method `path' for Gem:Module
> (NoMethodError)
> 
> $ ruby1.9.1 -e 'p Gem.path; begin; require "not exist"; rescue
> LoadError; end; require "rubygems"; p Gem.path'
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
> 
> $ ruby1.9.1 -e 'p Gem.path; Gem::QuickLoader.remove; require
> "rubygems"; p Gem.path'                                          ~
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
> --
> 
> There is difference:
> --
> $ diff -u ruby_1_9_2/lib/rubygems.rb /usr/lib/ruby/1.9.1/rubygems.rb |head -20
> --- ruby_1_9_2/lib/rubygems.rb	2010-08-02 09:53:36.000000000 +0900
> +++ /usr/lib/ruby/1.9.1/rubygems.rb	2010-08-26 07:05:24.000000000 +0900
> @@ -4,14 +4,8 @@
>  # All rights reserved.
>  # See LICENSE.txt for permissions.
>  #++
> -
>  gem_disabled = !defined? Gem
> 
> -unless gem_disabled
> -  # Nuke the Quickloader stuff
> -  Gem::QuickLoader.remove
> -end
> -
>  require 'rubygems/defaults'
>  require 'thread'
>  require 'etc'
> @@ -492,8 +486,26 @@
> 
>    ##
> --
> (ruby_1_9_2 is tree of ruby_1_9_2 in the svn.
> /usr/lib/ruby/1.9.1/rubygems.rb is provided rubygems-1.3.1.deb)
> 
> When ruby requires "rubygems", rubygems.rb will require
> "rubygems/defaults/operating_system".
> And ruby re-requires "rubygems" internally because the file is not given.
> 
> On the 2nd require "rubygems", Gem::QuickLoader.remove is called.
> The method removes Gem module methods defined in gem_prelude.
> But the 2nd require "rubygems" don't executed because ruby interpreter
> is already in requiring rubygems.
> So some pre-defined Gem module methods is missing
> and chance of new definition of these methods isn't given.
> 
> Calling Gem::QuickLoader.remove in top of rubygems.rb
> can avoid "circular require" of rubygems.
> (It sets @loaded_full_rubygems_library)

Thanks for the investigation!

After looking at this issue, I think that we should:
- package rubygems1.8 from rubygems 1.3.7
- package rubygems for 1.9.1 from the ruby 1.9.2 sources

While it's not the cleanest approach, it seems that it is the most
reasonable solution given that upstream has failed to make sure that
ruby1.9.2 wouldn't break with rubygems's rubygems. It might happen again
in the future.

We need to decide on the following questions:

- Do we want to make the installation of rubygems optional with 1.9.1?
  (as a separate package ?) That would probably be the right thing to do
  since I think that we should make the use of external package managers
  optional in Debian, but frankly, if we do that, some users are going
  to complain, and I'm totally tired of hearing complains about ruby
  packaging in Debian.
- Do we want to disable gem update --system? I think that we should
  allow a way for the user to do it anyway. For example, we could add a
  check for a "I_KNOW_WHAT_IM_DOING_ABOUT_GEM_UPDATE_SYSTEM" environment
  variable (ok, name could be improved). We would still refuse to gem
  update --system by default, but would accept it of the environment
  variable was set.
- Paths: until consensus emerge in #448639, we should continue to
  install gems in /var. Those changes should be moved to 
  rubygems/defaults/operating_system.rb, but we may do that later, and
  just continue with 01_default_gem_path.diff for now.

Lucas

From tony.arcieri at medioh.com  Tue Aug 31 21:48:32 2010
From: tony.arcieri at medioh.com (Tony Arcieri)
Date: Tue, 31 Aug 2010 19:48:32 -0600
Subject: [Rubygems-developers] Is a "pure" platform needed?
Message-ID: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>

Context for the problem is here:

http://github.com/defunkt/resque/commit/28e3f03d6536fb70254668e7e05...<http://github.com/defunkt/resque/commit/28e3f03d6536fb70254668e7e05c5971676c1a34>

Resque used to be broken on JRuby because the json gem used to only work on
MRI. After a lot of complaining Charlie from the JRuby team got commit
access, and patches from Evan of Rubinius got accepted. Now everything is
dandy, except on IronRuby. The JSON gem only works on MRI, YARV, JRuby, and
Rubinius, NOT on IronRuby.

But IronRuby isn't the only concern. What about MagLev? Or BlueRuby? There
are a lot of alternative Ruby implementations out there which don't provide
the MRI C extension API. Using a gem like "json" on these platforms is
broken-by-default, since the "default" platform is called "ruby", and the
"ruby" platform seems to assume out-of-the-gate that you can install C
extensions, when in fact the opposite is true. Support for MRI C extensions
is almost a rarity when it comes to the totality of Ruby implementations
available, with the only implementations supporting them are MRI, YARV,
Rubinius, and JRuby to a limited extent.

For these platforms, there's the "json_pure" gem. This gem exposes (in
theory!) the same API as the json gem, but is implemented in pure Ruby.
However, when trying to specify dependencies, which gem does one pick?
json_pure is the least common denominator, but as has been seen in practice
in Resque, compatibility issues can arise:

http://librelist.com/browser//resque/2010/8/13/issue-with-json-pure...<http://librelist.com/browser//resque/2010/8/13/issue-with-json-pure-stack-level-too-deep-resque-+-resque-status/>

My immediate proposed solution for the resque/json scenario is:

MRI/YARV/Rubinius: use the C extension
JRuby: use the Java version
IronRuby: package json_pure as "json"
Other platforms: you're screwed

The question is, how can we solve this problem for not only IronRuby, but
all other Ruby platforms without C extension support? (e.g. BlueRuby,
MagLev). I would propose Ruby implementers add some check to their
implementation RubyGems can use to determine if MRI-style C extensions are
supported, and if they are not supported for this platform, the "pure"
implementation be used in lieu of the "ruby" implementation.

Thoughts?
-- 
Tony Arcieri
Medioh! A Kudelski Brand