From noreply at rubyforge.org  Thu Sep  9 00:34:41 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  9 Sep 2010 00:34:41 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28551 ] UTF-8 files break Gem
	builds under Ruby 1.9.0
Message-ID: <20100909043441.5B7A11858363@rubyforge.org>

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

Category: `gem install` command
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: chocolate boy (chocolateboy)
Assigned to: Nobody (None)
Summary: UTF-8 files break Gem builds under Ruby 1.9.0

Initial Comment:
I've spent the past couple of hours trying to get "rake gem" to build a valid gem for this project:

http://github.com/nricciar/wikicloth

Each time, gem install pkg/wikicloth-0.2.0.gem would fail with:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte

gem install --backtrace pkg/wikicloth-0.2.0.gem gives:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte
	/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66:in `join'
	...
	/usr/lib/ruby/1.9.0/rubygems/gem_runner.rb:58:in `run'
	/usr/bin/gem1.9:21:in `<main>'

Placing a puts statement in the join method revealed a corrupt header:

Good header:

#<Gem::Package::TarHeader:0x97f9064 @checksum=7592, @devmajor=0, @devminor=0, @gid=0, @gname="wheel", @linkname="", @magic="ustar", @mode=420, @mtime=0, @name="sample_documents/lists.wiki", @prefix="", @size=12390, @typeflag="0", @uid=0, @uname="wheel", @version=0, @empty=false>

Bad header:

#<Gem::Package::TarHeader:0x97f7c64 @checksum=95, @devmajor=0, @devminor=0, @gid=420, @gname="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00wheel", @linkname="000000\x00020307\x00 0", @magic="", @mode=0, @mtime=0, @name="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00sample_documents/air_force_one.wiki", @prefix="0000000\x000000000", @size=0, @typeflag="0", @uid=0, @uname="\x00\x00\x00\x00\x00\x00\x00\x00ustar\x0000wheel", @version=0, @empty=false>

Although the "file" command flags both of these as UTF-8, it seems that the first UTF-8 entry corrupts the following entry. Removing UTF-8 files from the sample_documents directory solves the problem (a valid data.tar gzipped inside the gem) and placing any of the UTF-8 files in the samples directory, even on its own, produces an invalid tarball.

After a couple of hours of tracing gem creation through the maze of:

/usr/lib/ruby/1.9.0/rubygems/builder.rb
/usr/lib/ruby/1.9.0/rubygems/package.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_header.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_output.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_writer.rb

- trying to find the bug, I finally relented and installed rubygems1.8 (just to build the gem) and it worked.

The rubygems1.8 package on Ubuntu (10.04) is exactly the same version as rubygems1.9: 1.3.5. All the files above are the same. They just differ in the path and the Ruby version: 1.8.7 vs 1.9.0.

This may be fixed in 1.9.1 or 1.9.2, but as it stands: RubyGems can't build a valid tarball on 1.9.0 when confronted with UTF-8 files.

Ubuntu 10.04
Ruby 1.9.0
RubyGems 1.3.5
(Rake 0.8.7)

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.9.0 (2008-10-04 patchlevel 0) [i486-linux]
  - INSTALLATION DIRECTORY: ~/.gem/ruby/1.9.0
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: ~/.gem/ruby/1.9.0/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - ~/.gem/ruby/1.9.0
     - /var/lib/gems/1.9.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/

wikicloth$ gem --debug install pkg/wikicloth-0.2.0.gem 
Exception `NameError' at /usr/lib/ruby/1.9.0/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `LoadError' at /usr/lib/ruby/1.9.0/rubygems/gem_openssl.rb:40 - no such file to load -- openssl
Exception `Gem::LoadError' at /usr/lib/ruby/1.9.0/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0)

Exception `NoMethodError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_input.rb:48 - undefined method `readpartial' for #<Gem::Package::TarReader::Entry:0x9f9e508>
Exception `ArgumentError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66 - string contains null byte
Exception `IOError' at /usr/lib/ruby/1.9.0/rubygems/format.rb:50 - closed stream

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

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

From noreply at rubyforge.org  Thu Sep  9 11:10:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  9 Sep 2010 11:10:09 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28551 ] UTF-8 files break Gem
	builds under Ruby 1.9.0
Message-ID: <20100909151009.DBBCD1858375@rubyforge.org>

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

Category: `gem install` command
>Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: chocolate boy (chocolateboy)
>Assigned to: Eric Hodel (drbrain)
Summary: UTF-8 files break Gem builds under Ruby 1.9.0

Initial Comment:
I've spent the past couple of hours trying to get "rake gem" to build a valid gem for this project:

http://github.com/nricciar/wikicloth

Each time, gem install pkg/wikicloth-0.2.0.gem would fail with:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte

gem install --backtrace pkg/wikicloth-0.2.0.gem gives:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte
	/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66:in `join'
	...
	/usr/lib/ruby/1.9.0/rubygems/gem_runner.rb:58:in `run'
	/usr/bin/gem1.9:21:in `<main>'

Placing a puts statement in the join method revealed a corrupt header:

Good header:

#<Gem::Package::TarHeader:0x97f9064 @checksum=7592, @devmajor=0, @devminor=0, @gid=0, @gname="wheel", @linkname="", @magic="ustar", @mode=420, @mtime=0, @name="sample_documents/lists.wiki", @prefix="", @size=12390, @typeflag="0", @uid=0, @uname="wheel", @version=0, @empty=false>

Bad header:

#<Gem::Package::TarHeader:0x97f7c64 @checksum=95, @devmajor=0, @devminor=0, @gid=420, @gname="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00wheel", @linkname="000000\x00020307\x00 0", @magic="", @mode=0, @mtime=0, @name="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00sample_documents/air_force_one.wiki", @prefix="0000000\x000000000", @size=0, @typeflag="0", @uid=0, @uname="\x00\x00\x00\x00\x00\x00\x00\x00ustar\x0000wheel", @version=0, @empty=false>

Although the "file" command flags both of these as UTF-8, it seems that the first UTF-8 entry corrupts the following entry. Removing UTF-8 files from the sample_documents directory solves the problem (a valid data.tar gzipped inside the gem) and placing any of the UTF-8 files in the samples directory, even on its own, produces an invalid tarball.

After a couple of hours of tracing gem creation through the maze of:

/usr/lib/ruby/1.9.0/rubygems/builder.rb
/usr/lib/ruby/1.9.0/rubygems/package.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_header.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_output.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_writer.rb

- trying to find the bug, I finally relented and installed rubygems1.8 (just to build the gem) and it worked.

The rubygems1.8 package on Ubuntu (10.04) is exactly the same version as rubygems1.9: 1.3.5. All the files above are the same. They just differ in the path and the Ruby version: 1.8.7 vs 1.9.0.

This may be fixed in 1.9.1 or 1.9.2, but as it stands: RubyGems can't build a valid tarball on 1.9.0 when confronted with UTF-8 files.

Ubuntu 10.04
Ruby 1.9.0
RubyGems 1.3.5
(Rake 0.8.7)

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.9.0 (2008-10-04 patchlevel 0) [i486-linux]
  - INSTALLATION DIRECTORY: ~/.gem/ruby/1.9.0
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: ~/.gem/ruby/1.9.0/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - ~/.gem/ruby/1.9.0
     - /var/lib/gems/1.9.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/

wikicloth$ gem --debug install pkg/wikicloth-0.2.0.gem 
Exception `NameError' at /usr/lib/ruby/1.9.0/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `LoadError' at /usr/lib/ruby/1.9.0/rubygems/gem_openssl.rb:40 - no such file to load -- openssl
Exception `Gem::LoadError' at /usr/lib/ruby/1.9.0/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0)

Exception `NoMethodError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_input.rb:48 - undefined method `readpartial' for #<Gem::Package::TarReader::Entry:0x9f9e508>
Exception `ArgumentError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66 - string contains null byte
Exception `IOError' at /usr/lib/ruby/1.9.0/rubygems/format.rb:50 - closed stream

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

>Comment By: Eric Hodel (drbrain)
Date: 2010-09-09 08:10

Message:
RubyGems is not supported on Ruby 1.9.0.

Ruby 1.9.0 is not a production-ready release.

You will need to upgrade your ruby.

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

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

From noreply at rubyforge.org  Thu Sep  9 11:43:11 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  9 Sep 2010 11:43:11 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28551 ] UTF-8 files break Gem
	builds under Ruby 1.9.0
Message-ID: <20100909154311.D6B80185837B@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: chocolate boy (chocolateboy)
Assigned to: Eric Hodel (drbrain)
Summary: UTF-8 files break Gem builds under Ruby 1.9.0

Initial Comment:
I've spent the past couple of hours trying to get "rake gem" to build a valid gem for this project:

http://github.com/nricciar/wikicloth

Each time, gem install pkg/wikicloth-0.2.0.gem would fail with:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte

gem install --backtrace pkg/wikicloth-0.2.0.gem gives:

ERROR:  While executing gem ... (ArgumentError)
    string contains null byte
	/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66:in `join'
	...
	/usr/lib/ruby/1.9.0/rubygems/gem_runner.rb:58:in `run'
	/usr/bin/gem1.9:21:in `<main>'

Placing a puts statement in the join method revealed a corrupt header:

Good header:

#<Gem::Package::TarHeader:0x97f9064 @checksum=7592, @devmajor=0, @devminor=0, @gid=0, @gname="wheel", @linkname="", @magic="ustar", @mode=420, @mtime=0, @name="sample_documents/lists.wiki", @prefix="", @size=12390, @typeflag="0", @uid=0, @uname="wheel", @version=0, @empty=false>

Bad header:

#<Gem::Package::TarHeader:0x97f7c64 @checksum=95, @devmajor=0, @devminor=0, @gid=420, @gname="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00wheel", @linkname="000000\x00020307\x00 0", @magic="", @mode=0, @mtime=0, @name="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00sample_documents/air_force_one.wiki", @prefix="0000000\x000000000", @size=0, @typeflag="0", @uid=0, @uname="\x00\x00\x00\x00\x00\x00\x00\x00ustar\x0000wheel", @version=0, @empty=false>

Although the "file" command flags both of these as UTF-8, it seems that the first UTF-8 entry corrupts the following entry. Removing UTF-8 files from the sample_documents directory solves the problem (a valid data.tar gzipped inside the gem) and placing any of the UTF-8 files in the samples directory, even on its own, produces an invalid tarball.

After a couple of hours of tracing gem creation through the maze of:

/usr/lib/ruby/1.9.0/rubygems/builder.rb
/usr/lib/ruby/1.9.0/rubygems/package.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_header.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_output.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb
/usr/lib/ruby/1.9.0/rubygems/package/tar_writer.rb

- trying to find the bug, I finally relented and installed rubygems1.8 (just to build the gem) and it worked.

The rubygems1.8 package on Ubuntu (10.04) is exactly the same version as rubygems1.9: 1.3.5. All the files above are the same. They just differ in the path and the Ruby version: 1.8.7 vs 1.9.0.

This may be fixed in 1.9.1 or 1.9.2, but as it stands: RubyGems can't build a valid tarball on 1.9.0 when confronted with UTF-8 files.

Ubuntu 10.04
Ruby 1.9.0
RubyGems 1.3.5
(Rake 0.8.7)

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.5
  - RUBY VERSION: 1.9.0 (2008-10-04 patchlevel 0) [i486-linux]
  - INSTALLATION DIRECTORY: ~/.gem/ruby/1.9.0
  - RUBY EXECUTABLE: /usr/bin/ruby1.9
  - EXECUTABLE DIRECTORY: ~/.gem/ruby/1.9.0/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-linux
  - GEM PATHS:
     - ~/.gem/ruby/1.9.0
     - /var/lib/gems/1.9.0
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/

wikicloth$ gem --debug install pkg/wikicloth-0.2.0.gem 
Exception `NameError' at /usr/lib/ruby/1.9.0/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `LoadError' at /usr/lib/ruby/1.9.0/rubygems/gem_openssl.rb:40 - no such file to load -- openssl
Exception `Gem::LoadError' at /usr/lib/ruby/1.9.0/rubygems.rb:827 - Could not find RubyGem test-unit (>= 0)

Exception `NoMethodError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_input.rb:48 - undefined method `readpartial' for #<Gem::Package::TarReader::Entry:0x9f9e508>
Exception `ArgumentError' at /usr/lib/ruby/1.9.0/rubygems/package/tar_reader/entry.rb:66 - string contains null byte
Exception `IOError' at /usr/lib/ruby/1.9.0/rubygems/format.rb:50 - closed stream

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

>Comment By: chocolate boy (chocolateboy)
Date: 2010-09-09 15:43

Message:
Thanks. FYI:
https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/634137

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

Comment By: Eric Hodel (drbrain)
Date: 2010-09-09 15:10

Message:
RubyGems is not supported on Ruby 1.9.0.

Ruby 1.9.0 is not a production-ready release.

You will need to upgrade your ruby.

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

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

From luislavena at gmail.com  Fri Sep 10 11:29:25 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 10 Sep 2010 12:29:25 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
Message-ID: <AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>

On Tue, Aug 31, 2010 at 10:03 PM, Luis Lavena <luislavena at gmail.com> wrote:
> 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.
>

Bumping this message, anyone could care saying something (at least f*ck off).

Thank you.
-- 
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 thewoolleyman at gmail.com  Fri Sep 10 12:31:15 2010
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 10 Sep 2010 09:31:15 -0700
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
Message-ID: <AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>

I brought this up before and I believe Eric said he'd watch both ticket
systems (actually 3 counting the one for ruby itself).  I think it makes
sense only have one, migrate the tickets and kill the other.

On Sep 10, 2010 8:29 AM, "Luis Lavena" <luislavena at gmail.com> wrote:
> On Tue, Aug 31, 2010 at 10:03 PM, Luis Lavena <luislavena at gmail.com>
wrote:
>> 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.
>>
>
> Bumping this message, anyone could care saying something (at least f*ck
off).
>
> Thank you.
> --
> 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
> _______________________________________________
> Rubygems-developers mailing list
> http://rubyforge.org/projects/rubygems
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers

From nick at quaran.to  Fri Sep 10 13:46:17 2010
From: nick at quaran.to (Nick Quaranto)
Date: Fri, 10 Sep 2010 13:46:17 -0400
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
Message-ID: <AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>

+1 github pull requests!

On Fri, Sep 10, 2010 at 12:31 PM, Chad Woolley <thewoolleyman at gmail.com>wrote:

> I brought this up before and I believe Eric said he'd watch both ticket
> systems (actually 3 counting the one for ruby itself).  I think it makes
> sense only have one, migrate the tickets and kill the other.
>
> On Sep 10, 2010 8:29 AM, "Luis Lavena" <luislavena at gmail.com> wrote:
> > On Tue, Aug 31, 2010 at 10:03 PM, Luis Lavena <luislavena at gmail.com>
> wrote:
> >> 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.
> >>
> >
> > Bumping this message, anyone could care saying something (at least f*ck
> off).
> >
> > Thank you.
> > --
> > 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
> > _______________________________________________
> > Rubygems-developers mailing list
> > http://rubyforge.org/projects/rubygems
> > Rubygems-developers at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rubygems-developers
> _______________________________________________
> 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 Sep 10 14:31:44 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 15:31:44 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
	<AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
Message-ID: <0B7CCDF0-E7FB-4442-A5FD-EC6A4816C8F4@gmail.com>

I think with the organization setup we get pull requests in our inbox don't we? (moving forward).

As far as this specific branch/patchset is concerned, I'm not sure if it was this one, or the alternate one, but John Barnett and I had a quick look through and noticed a few potential edge cases we wanted to see covered before a merge, so if we could get a code review / discussion going (that pays attention to potential edge cases / breakage), that would be awesome.

Some examples:

What about casing? Example: ZenTest and zentest - the ideal is to prefer the prior.

Secondary sort by release date? - prefer native gems (of same versions / release dates)?

etc.



From stephen.bannasch at deanbrook.org  Fri Sep 10 15:26:13 2010
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Fri, 10 Sep 2010 15:26:13 -0400
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
	<AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
Message-ID: <p0624081fc8b03657e01e@[63.138.152.169]>

At 1:46 PM -0400 9/10/10, Nick Quaranto wrote:
>+1 github pull requests!

The recent changes at github where pull requests are integrated into the github issue tracker have in my experience made them much more useful: http://github.com/blog/712-pull-requests-2-0

From luislavena at gmail.com  Fri Sep 10 17:22:50 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 10 Sep 2010 18:22:50 -0300
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
Message-ID: <AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>

Hello Tony.

On Tue, Aug 31, 2010 at 10:48 PM, Tony Arcieri <tony.arcieri at medioh.com> wrote:
> Context for the problem is here:
>
> 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
>

There are a few ways to solve this:

json gem provides the pure-ruby version of JSON specification
json_ext provides the C, JRuby or whatever-under-the-sun required for
each platform (-java, windows binaries, etc).

json gem tries to use json_ext and on failure falls back to pure-ruby version.

> 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.
>

There is another approach which is a dummy_makefile by mkmf, been
discussed here:

http://rubyforge.org/tracker/index.php?func=detail&aid=28366&group_id=126&atid=578

But it assumes that:

1) mkmf provided by your Ruby implementation actually works (mkmf in
JRuby says that is not supported and fails), at least providing the
minimum checking to create this dummy makefile.

2) Your environment provides a sane build environment capable of invoking "make"

This one highly unlikely is going to work for IronRuby or others that
do not support C extensions (like MagLev, which endorses FFI) or not
provide a sane build environment.

If we can make RubyGems more smart in relation to extensions and when
it fails to compile them somehow, then the issue with pure ruby
extensions and C extensions is gone.

-- 
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 Sep 10 17:34:10 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 18:34:10 -0300
Subject: [Rubygems-developers] rubygems and FHS compliance in Debian and
	Ubuntu
In-Reply-To: <7EB961E3-F5F1-4E9A-847F-C6C70FA334A3@ubuntu.com>
References: <7EB961E3-F5F1-4E9A-847F-C6C70FA334A3@ubuntu.com>
Message-ID: <B391F55B-0B12-450D-826E-3D4D72B038DA@gmail.com>


On 26 Aug 2010, at 14:51, Clint Byrum wrote:

> 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.

I'm glad to receive this, I am planning on some implementation work by february to make all of this more friendly, but I want to get it right, for as many people, packagers, distros as possible.

> 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:

It relies on rbconfig.rb. As far as I know, rubys default prefix is /usr/local, so I should think the default is really /usr/local bin and /usr/local/lib.

> $ 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

This conflict is hard to solve without patches to RubyGems to warn when it happens, I plan on doing this as part of the work in February, unless it is done sooner. I wouldn't say anyone is directly at fault, two debian packages could even do the same thing (or for example, provide the same named binary, maybe BSD grep and GNU grep). Marking these as conflicting is difficult, I would like ideally for RubyGems packagers to be able to hook this by writing a hook into their local operating system defaults  configuration file, rather than them maintaining substantial patches or the like.

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

This should be immediately solved by turning on --executable_format by default. I believe this is the default for the Debian RubyGems package now.

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

I'm not 100% sure that was right, but you discuss this later.

> 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."

See above and below.

> However, this introduced an incompatibility with the FHS definition of
> the purpose of /var[1].
> 
> 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".

Agreed, I don't think this choice was entirely correct.

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

I don't want to start an argument, but this isn't RubyGems that selected to use /var.

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

Understood, and sympathetic.

> Whats more, users do not expect to find executable scripts in /var.

Agreed, we can do better.

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

Disagree, you've missed the Ruby version in the lib path, as such installing 1.9 and 1.8 alongside would lead to new bugs, unless you're proposing:

/usr/local/lib/gems/<ruby-version>/gems

This is similar to now, it just removes the ruby portion of the path.

I would like to suggest to ruby-core that the version used here be corrected to include patch levels and local modification suffixes, to avoid issues with native gems that link the ruby binary. I think conscientious package managers would agree with this, in which case, an example of a good enough path might be:

/usr/local/lib/gems/<RbConfig::CONFIG['ruby_install_name']>-<RUBY_VERSION>-<RUBY_PATCHLEVEL>-<RbConfig::CONFIG['sitearch']>/...

This should ensure maintenance of ABI compatibility without overwriting during development installs and so on.

> FHS defines the purpose of /usr/local as such...
> 
> 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.

Agreed.


From jftucker at gmail.com  Fri Sep 10 17:41:09 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 18:41:09 -0300
Subject: [Rubygems-developers] Bug#588125: Rubygems 1.3.7 broken with
	Ruby 1.9.2 in Debian -- help needed
In-Reply-To: <20100828065605.GA5733@xanadu.blop.info>
References: <20100825195203.GB16194@xanadu.blop.info>
	<AANLkTimBC81SPbByKTct-MVPH1EemXm-OM30vaC8cDsJ@mail.gmail.com>
	<20100828065605.GA5733@xanadu.blop.info>
Message-ID: <734B236A-E6B1-4B33-B911-5E5E4A948079@gmail.com>


On 28 Aug 2010, at 03:56, Lucas Nussbaum wrote:
> 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.

This solution makes me uncomfortable, however, I am entirely sympathetic. I think it is incorrect that we have multiple versions of RubyGems around with the same version tag. The issues of gem_prelude and ruby-core patches should be forwarded on to Evan Pheonix and ruby-core respectively, as they're out of our (or some of our) direct control.

> 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.

This is a hard choice for you guys I know, all I might ask is that you try to avoid too bigger patches, I will do what I can to help accommodate where appropriate.

> - 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.

Also a hard problem, I want to try and make this easier, but I am still trying to find the best way to integrate such features between RubyGems and packagers. A hook in the operating system defaults to allow you to override this more cleanly is the only immediate solution that comes to mind. Related to the FHS discussion, I also wonder if it's outside of allowed policy for you guys to have a sort of "shim package" that just delivers a local install without recording all of it as a package, such that users can use it "as they expect", and an alternate "managed package", that would disable features such as this. Just a thought.

> - 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.

It would be preferred that it's done in the defaults file. We have of course, discussed some of this already, off the list. I thank you for your patience.

From jftucker at gmail.com  Fri Sep 10 17:51:34 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 18:51:34 -0300
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
	<AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
Message-ID: <AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>


On 10 Sep 2010, at 18:22, Luis Lavena wrote:
> json gem tries to use json_ext and on failure falls back to pure-ruby version.

We need to add a feature to really support this. The problem is, gems that fail to build although left on the filesystem for debugging purposes and to allow access to the build logs, they are not added to the installed index, and as such are not loadable except under old gem_prelude bugs.

Maybe a gemspec option ext_optional or pure_option, or some better name?

>> 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.
>> 
> 
> There is another approach which is a dummy_makefile by mkmf, been
> discussed here:
> 
> http://rubyforge.org/tracker/index.php?func=detail&aid=28366&group_id=126&atid=578
> 
> But it assumes that:
> 
> 1) mkmf provided by your Ruby implementation actually works (mkmf in
> JRuby says that is not supported and fails), at least providing the
> minimum checking to create this dummy makefile.
> 
> 2) Your environment provides a sane build environment capable of invoking "make"
> 
> This one highly unlikely is going to work for IronRuby or others that
> do not support C extensions (like MagLev, which endorses FFI) or not
> provide a sane build environment.
> 
> If we can make RubyGems more smart in relation to extensions and when
> it fails to compile them somehow, then the issue with pure ruby
> extensions and C extensions is gone.

I have proposed a number of times moving toward a single script invocation (maybe with some build helpers) rather than having specifically matched build types.

So, that would be moving towards having spec.extensions simply call:

	spec.extensions.each { |e| system Gem.ruby, e }

We could have very simple helpers for migration, like so:

	require "rubygems/extconf_make" # calls at_exit { system ENV['make'] || 'make' }
	require "rubygems/mkrf_make"    # calls at_exit { system "rake" } # n.b. the correct path and bin name ofc.

You get the idea. We would migrate the old methods out in the long term, and then deprecate these. This way RubyGems can drop all specific build methods, and simply execute a single ruby script for each extension in the gem. If further utilities are required, they can be provided by the Gem api, or separate gems which may be dependencies (for example an extended mkmf, some helpers from rake-compiler, or the like).


From jftucker at gmail.com  Fri Sep 10 17:58:44 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 18:58:44 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <p0624081fc8b03657e01e@[63.138.152.169]>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
	<AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
	<p0624081fc8b03657e01e@[63.138.152.169]>
Message-ID: <E50A7ACB-BFFB-4A47-8BD8-07F38C043672@gmail.com>


On 10 Sep 2010, at 16:26, Stephen Bannasch wrote:

> At 1:46 PM -0400 9/10/10, Nick Quaranto wrote:
>> +1 github pull requests!
> 
> The recent changes at github where pull requests are integrated into the github issue tracker have in my experience made them much more useful: http://github.com/blog/712-pull-requests-2-0

Indeed, I just wish they had an apply button!

> _______________________________________________
> 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  Fri Sep 10 18:08:18 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 10 Sep 2010 19:08:18 -0300
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
	<AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
	<AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
Message-ID: <AANLkTik+m=xZzey4cGsJ_bN7BuUt5gm-X8kDMRsQdc2u@mail.gmail.com>

On Fri, Sep 10, 2010 at 6:51 PM, James Tucker <jftucker at gmail.com> wrote:
>
> I have proposed a number of times moving toward a single script invocation (maybe with some build helpers) rather than having specifically matched build types.
>
> So, that would be moving towards having spec.extensions simply call:
>
> ? ? ? ?spec.extensions.each { |e| system Gem.ruby, e }
>
> We could have very simple helpers for migration, like so:
>
> ? ? ? ?require "rubygems/extconf_make" # calls at_exit { system ENV['make'] || 'make' }
> ? ? ? ?require "rubygems/mkrf_make" ? ?# calls at_exit { system "rake" } # n.b. the correct path and bin name ofc.
>
> You get the idea. We would migrate the old methods out in the long term, and then deprecate these. This way RubyGems can drop all specific build methods, and simply execute a single ruby script for each extension in the gem. If further utilities are required, they can be provided by the Gem api, or separate gems which may be dependencies (for example an extended mkmf, some helpers from rake-compiler, or the like).
>

Interesting idea, but RubyGems specifically tweak the installation directory:

http://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/builder.rb#L19-21

Because of that little thing, calling at_exit will not work as expected.

Bug, I see lot of potential on this.

-- 
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 luislavena at gmail.com  Fri Sep 10 18:09:52 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 10 Sep 2010 19:09:52 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <E50A7ACB-BFFB-4A47-8BD8-07F38C043672@gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
	<AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
	<p0624081fc8b03657e01e@63.138.152.169>
	<E50A7ACB-BFFB-4A47-8BD8-07F38C043672@gmail.com>
Message-ID: <AANLkTimTbPLbbTxH-1cHHgupHxxhABVJw4J0XxgpttMP@mail.gmail.com>

On Fri, Sep 10, 2010 at 6:58 PM, James Tucker <jftucker at gmail.com> wrote:
>
> On 10 Sep 2010, at 16:26, Stephen Bannasch wrote:
>
>> At 1:46 PM -0400 9/10/10, Nick Quaranto wrote:
>>> +1 github pull requests!
>>
>> The recent changes at github where pull requests are integrated into the github issue tracker have in my experience made them much more useful: http://github.com/blog/712-pull-requests-2-0
>
> Indeed, I just wish they had an apply button!
>

Not as simple as apply but fork queue can cherry pick the changes for you ;-)
-- 
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 Sep 10 18:29:32 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 19:29:32 -0300
Subject: [Rubygems-developers] GitHub pull request, Bug tracker and more
In-Reply-To: <AANLkTimTbPLbbTxH-1cHHgupHxxhABVJw4J0XxgpttMP@mail.gmail.com>
References: <AANLkTikBesv0K2WcN6nGLzKaM+7mqh-qU6_Nqvnt1_vd@mail.gmail.com>
	<AANLkTin+EpR01gcrjpYi5dqrH0iKW+D+9fmzCQ9MRU70@mail.gmail.com>
	<AANLkTi=86rTXxrF-Ox6xgepyUjh3f+fMa6Xtk1O59efG@mail.gmail.com>
	<AANLkTi=erTfDMQ6ea8Vc4TOsMZEBUUo__HRJw1wRTEMb@mail.gmail.com>
	<p0624081fc8b03657e01e@63.138.152.169>
	<E50A7ACB-BFFB-4A47-8BD8-07F38C043672@gmail.com>
	<AANLkTimTbPLbbTxH-1cHHgupHxxhABVJw4J0XxgpttMP@mail.gmail.com>
Message-ID: <B24397D3-94B4-409B-8851-497A798B3D0D@gmail.com>


On 10 Sep 2010, at 19:09, Luis Lavena wrote:
> Not as simple as apply but fork queue can cherry pick the changes for you ;-)

Yeah I know, I've been using it for rack, but with a larger number of older forks, you end up with it getting rather slow and cumbersome to use :-)

Also, that means you have to as you say, cherry pick commits. Of course we still have to fall back to manual commits for incomplete or non-fast-forward changes.

From jftucker at gmail.com  Fri Sep 10 18:31:05 2010
From: jftucker at gmail.com (James Tucker)
Date: Fri, 10 Sep 2010 19:31:05 -0300
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AANLkTik+m=xZzey4cGsJ_bN7BuUt5gm-X8kDMRsQdc2u@mail.gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
	<AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
	<AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
	<AANLkTik+m=xZzey4cGsJ_bN7BuUt5gm-X8kDMRsQdc2u@mail.gmail.com>
Message-ID: <C3672BC6-0A9D-43BA-8E98-CE9CF86DFC1E@gmail.com>


On 10 Sep 2010, at 19:08, Luis Lavena wrote:
> Interesting idea, but RubyGems specifically tweak the installation directory:
> 
> http://github.com/rubygems/rubygems/blob/master/lib/rubygems/ext/builder.rb#L19-21
> 
> Because of that little thing, calling at_exit will not work as expected.
> 
> Bug, I see lot of potential on this.

Right, good point. So one would add that to the compat shim too. For specs that are old, in the interim, we would just load that shim for the user, keeping it dry and simple :-)


From noreply at rubyforge.org  Sun Sep 12 13:27:44 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Sep 2010 13:27:44 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28561 ] Doesn't check that
	the current thread already has the mutex in Gem.searcher
Message-ID: <20100912172744.22EAA185834E@rubyforge.org>

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

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Evans (jeremyevans)
Assigned to: Nobody (None)
Summary: Doesn't check that the current thread already has the mutex in Gem.searcher

Initial Comment:
Gem.search doesn't check that the current thread already has the mutex.  In certain cases, it's possible that it will call itself when it already has the mutex.  See http://github.com/jeremyevans/home_run/issues/issue/13.

For example, this backtrace shows that searcher can call itself recursively (see ****):

C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize': thread 0x4394f10 tried to join itself (ThreadError)
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/date.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml/rubytypes.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml.rb:396
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:220:in `load_file'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:168:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `configuration'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:635:in `path'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:68:in `installed_spec_directories'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:58:in `from_installed_gems'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:883:in `source_index'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:13:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize'
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:479:in `find_files'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:983:in `load_plugins'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:1139
    from ./script/../config/boot.rb:90:in `require'
    from ./script/../config/boot.rb:90:in `load_rubygems'
    from ./script/../config/boot.rb:53:in `load_initializer'
    from ./script/../config/boot.rb:38:in `run'
    from ./script/../config/boot.rb:11:in `boot!'
    from ./script/../config/boot.rb:114
    from script/console:2:in `require'
    from script/console:2

You can prevent this by checking if current thread already has the mutex, and not doing MUTEX.synchronize if so.

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

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

From noreply at rubyforge.org  Sun Sep 12 14:04:05 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Sep 2010 14:04:05 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28561 ] Doesn't check that
	the current thread already has the mutex in Gem.searcher
Message-ID: <20100912180405.29CDF1858344@rubyforge.org>

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

Category: #gem and #require methods
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Evans (jeremyevans)
Assigned to: Nobody (None)
Summary: Doesn't check that the current thread already has the mutex in Gem.searcher

Initial Comment:
Gem.search doesn't check that the current thread already has the mutex.  In certain cases, it's possible that it will call itself when it already has the mutex.  See http://github.com/jeremyevans/home_run/issues/issue/13.

For example, this backtrace shows that searcher can call itself recursively (see ****):

C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize': thread 0x4394f10 tried to join itself (ThreadError)
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:34:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/date.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml/rubytypes.rb:2
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/1.8/yaml.rb:396
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:220:in `load_file'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:168:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:385:in `configuration'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:635:in `path'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:68:in `installed_spec_directories'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:58:in `from_installed_gems'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:883:in `source_index'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:81:in `init_gemspecs'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems/gem_path_searcher.rb:13:in `initialize'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `new'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:841:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `synchronize'
****from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:840:in `searcher'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:479:in `find_files'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:983:in `load_plugins'
    from C:/Ruby187/lib/ruby/site_ruby/1.8/rubygems.rb:1139
    from ./script/../config/boot.rb:90:in `require'
    from ./script/../config/boot.rb:90:in `load_rubygems'
    from ./script/../config/boot.rb:53:in `load_initializer'
    from ./script/../config/boot.rb:38:in `run'
    from ./script/../config/boot.rb:11:in `boot!'
    from ./script/../config/boot.rb:114
    from script/console:2:in `require'
    from script/console:2

You can prevent this by checking if current thread already has the mutex, and not doing MUTEX.synchronize if so.

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

>Comment By: James Tucker (raggi)
Date: 2010-09-12 18:04

Message:
The following should be cherry picked into master at the appropriate time.

http://github.com/rubygems/rubygems/commit/cceab040bde07d567131ccea2bc707a1f7dd7c8b

We're not thread safe, this mutex is pointless and incorrect.

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

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

From noreply at rubyforge.org  Sun Sep 12 16:33:04 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Sep 2010 16:33:04 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100912203304.6E6571858354@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-09-12 20:33

Message:
Fixed.

http://github.com/rubygems/rubygems/commit/18b1d2d4b57abd1b7adee0215c04e4faaed781b0

Thanks Roger. If you are able to notify the rspec folks that this is fixed in future, that would be good.

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

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  Sun Sep 12 16:33:35 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Sep 2010 16:33:35 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100912203335.A7177185835D@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: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
>Assigned to: James Tucker (raggi)
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-09-12 20:33

Message:
Fixed.

http://github.com/rubygems/rubygems/commit/18b1d2d4b57abd1b7adee0215c04e4faaed781b0

Thanks Roger. If you are able to notify the rspec folks that this is fixed in future, that would be good.

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

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  Mon Sep 13 10:04:03 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 10:04:03 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913140403.DD1A61678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 10:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 13:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 08:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 10:16:39 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 10:16:39 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913141639.0F84D1678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

>Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 11:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 11:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 14:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 10:35:33 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 10:35:33 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28411 ] unable to run a gem
	bin/xxx when newer version
Message-ID: <20100913143533.B2B631858372@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: Closed
Resolution: Accepted
Priority: 3
Submitted By: Roger Pack (rogerdpack)
Assigned to: James Tucker (raggi)
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-09-13 14:35

Message:
Thanks seems to work great for me here. thanks!

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

Comment By: James Tucker (raggi)
Date: 2010-09-12 20:33

Message:
Fixed.

http://github.com/rubygems/rubygems/commit/18b1d2d4b57abd1b7adee0215c04e4faaed781b0

Thanks Roger. If you are able to notify the rspec folks that this is fixed in future, that would be good.

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

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 tony.arcieri at medioh.com  Mon Sep 13 14:26:05 2010
From: tony.arcieri at medioh.com (Tony Arcieri)
Date: Mon, 13 Sep 2010 12:26:05 -0600
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
	<AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
	<AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
Message-ID: <AANLkTinHci-HZruhtCaRYBrwScoQu0s-jt6bh2MUDnFx@mail.gmail.com>

On Fri, Sep 10, 2010 at 3:51 PM, James Tucker <jftucker at gmail.com> wrote:

> We need to add a feature to really support this. The problem is, gems that
> fail to build although left on the filesystem for debugging purposes and to
> allow access to the build logs, they are not added to the installed index,
> and as such are not loadable except under old gem_prelude bugs.
>

This was why I was suggesting it be solved at the platform level as opposed
to trying to solve it within the gem itself.

The idea would be that on platforms with support for native extensions,
RubyGems would look for gems by platform in the following order:

1. A platform-native gem
2. The "ruby" platform
3. The "pure" platform

On platforms without native extensions, it'd check for:

1. A platform-native gem
2. The "pure" platform
3. The "ruby" platform (for legacy's sake)

This would allow tools like Bundler to automatically choose the right set of
dependencies for a given platform and avoid it ever trying to install gems
with native extensions at all.

-- 
Tony Arcieri
Medioh! A Kudelski Brand

From djberg96 at gmail.com  Mon Sep 13 14:35:44 2010
From: djberg96 at gmail.com (Daniel Berger)
Date: Mon, 13 Sep 2010 12:35:44 -0600
Subject: [Rubygems-developers] Is a "pure" platform needed?
In-Reply-To: <AANLkTinHci-HZruhtCaRYBrwScoQu0s-jt6bh2MUDnFx@mail.gmail.com>
References: <AANLkTi==17-P=4mTT+NyLbAtcyYOu+WmQasDS8h_yEuL@mail.gmail.com>
	<AANLkTin8Whjy5P+oBaPGSaeUB+1rJVGrAuQVzwaqWo5b@mail.gmail.com>
	<AD7684FE-94E9-4BD6-969D-5CB1DB5C8CB8@gmail.com>
	<AANLkTinHci-HZruhtCaRYBrwScoQu0s-jt6bh2MUDnFx@mail.gmail.com>
Message-ID: <AANLkTikMB_QOE9_1uzAqkhXtc6yTKdae8U4sSGDCqSSE@mail.gmail.com>

On Mon, Sep 13, 2010 at 12:26 PM, Tony Arcieri <tony.arcieri at medioh.com> wrote:
> On Fri, Sep 10, 2010 at 3:51 PM, James Tucker <jftucker at gmail.com> wrote:
>
>> We need to add a feature to really support this. The problem is, gems that
>> fail to build although left on the filesystem for debugging purposes and to
>> allow access to the build logs, they are not added to the installed index,
>> and as such are not loadable except under old gem_prelude bugs.
>>
>
> This was why I was suggesting it be solved at the platform level as opposed
> to trying to solve it within the gem itself.
>
> The idea would be that on platforms with support for native extensions,
> RubyGems would look for gems by platform in the following order:
>
> 1. A platform-native gem
> 2. The "ruby" platform
> 3. The "pure" platform
>
> On platforms without native extensions, it'd check for:
>
> 1. A platform-native gem
> 2. The "pure" platform
> 3. The "ruby" platform (for legacy's sake)
>
> This would allow tools like Bundler to automatically choose the right set of
> dependencies for a given platform and avoid it ever trying to install gems
> with native extensions at all.

Does this address my earlier issue?

http://rubyforge.org/tracker/index.php?func=detail&aid=23970&group_id=126&atid=578

Regards,

Dan

From noreply at rubyforge.org  Mon Sep 13 16:55:57 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 16:55:57 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913205557.F2A541678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 16:55

Message:
Thanks Luis,

Apologies for posting this against this thread.

Here is my gem env :

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i386-mingw32]
  - INSTALLATION DIRECTORY: C:/Ruby192/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: C:/Ruby192/bin/ruby.exe
  - EXECUTABLE DIRECTORY: C:/Ruby192/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - C:/Ruby192/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

My HomeDrive was Z:, I changed it to C:

HomePath = \

USERPROFILE=C:\Documents and Settings\saurabh.doshi

Still getting the error. Based on my environment, do I need to set the GEM_HOME variable?










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 10:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 10:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 13:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 08:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 17:05:28 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 17:05:28 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913210528.98EA21678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

>Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 18:05

Message:
Can you tell me what "SET GEM" tells you? Also, what "SET HOME" tells you?

Please include complete output. Also, include details about the exact version of Windows you're using,a nd if is 64bits, if you had E-editor installed or cygwin.

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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 17:55

Message:
Thanks Luis,

Apologies for posting this against this thread.

Here is my gem env :

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i386-mingw32]
  - INSTALLATION DIRECTORY: C:/Ruby192/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: C:/Ruby192/bin/ruby.exe
  - EXECUTABLE DIRECTORY: C:/Ruby192/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - C:/Ruby192/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

My HomeDrive was Z:, I changed it to C:

HomePath = \

USERPROFILE=C:\Documents and Settings\saurabh.doshi

Still getting the error. Based on my environment, do I need to set the GEM_HOME variable?










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 11:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 11:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 14:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 17:34:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 17:34:09 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913213409.C36661678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 17:34

Message:
My HomeDrive still remains Z: after I used env HOMEDRIVE=C:

C:\Ruby192\bin>set gem
Environment variable gem not defined

C:\Ruby192\bin>set home
HOMEDRIVE=Z:
HOMEPATH=\
HOMESHARE=\(servername)\users\saurabh.doshi


I am using 32 bit Win XP and have installed gnuwin32. I have added C:\gnuwin32\bin to my PATH env variable.

Does the Default drive change from Z: to C: be done at the domain level by my System  Administrator? 

Thanks,










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 17:05

Message:
Can you tell me what "SET GEM" tells you? Also, what "SET HOME" tells you?

Please include complete output. Also, include details about the exact version of Windows you're using,a nd if is 64bits, if you had E-editor installed or cygwin.

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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 16:55

Message:
Thanks Luis,

Apologies for posting this against this thread.

Here is my gem env :

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i386-mingw32]
  - INSTALLATION DIRECTORY: C:/Ruby192/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: C:/Ruby192/bin/ruby.exe
  - EXECUTABLE DIRECTORY: C:/Ruby192/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - C:/Ruby192/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

My HomeDrive was Z:, I changed it to C:

HomePath = \

USERPROFILE=C:\Documents and Settings\saurabh.doshi

Still getting the error. Based on my environment, do I need to set the GEM_HOME variable?










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 10:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 10:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 13:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 08:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 17:38:17 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 17:38:17 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913213817.538381678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

>Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 18:38

Message:
Hello,

First you need to use SET VARIABLE=VALUE, not "env" as env is not a native Windows command, perhaps from gnuwin32.

Also, you can modify those at runtime, but everyt ie you start a new command prompt or session, the values will be restored with the values your Admin set for you.

Is Z: mapped? do you have write permissions to the root?

Can you do this?

ruby -rfileutils -ve "FileUtils.touch 'z:/foo'"



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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 18:34

Message:
My HomeDrive still remains Z: after I used env HOMEDRIVE=C:

C:\Ruby192\bin>set gem
Environment variable gem not defined

C:\Ruby192\bin>set home
HOMEDRIVE=Z:
HOMEPATH=\
HOMESHARE=\(servername)\users\saurabh.doshi


I am using 32 bit Win XP and have installed gnuwin32. I have added C:\gnuwin32\bin to my PATH env variable.

Does the Default drive change from Z: to C: be done at the domain level by my System  Administrator? 

Thanks,










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 18:05

Message:
Can you tell me what "SET GEM" tells you? Also, what "SET HOME" tells you?

Please include complete output. Also, include details about the exact version of Windows you're using,a nd if is 64bits, if you had E-editor installed or cygwin.

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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 17:55

Message:
Thanks Luis,

Apologies for posting this against this thread.

Here is my gem env :

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i386-mingw32]
  - INSTALLATION DIRECTORY: C:/Ruby192/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: C:/Ruby192/bin/ruby.exe
  - EXECUTABLE DIRECTORY: C:/Ruby192/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - C:/Ruby192/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

My HomeDrive was Z:, I changed it to C:

HomePath = \

USERPROFILE=C:\Documents and Settings\saurabh.doshi

Still getting the error. Based on my environment, do I need to set the GEM_HOME variable?










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 11:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 11:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 14:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 12:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 10:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 13 18:28:19 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Sep 2010 18:28:19 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-25882 ] Handling of Windows
	paths broken in 1.3.3
Message-ID: <20100913222819.D1EFA1678316@rubyforge.org>

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

Category: `gem install` command
Group: v1.3.x
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Lars Christensen (larsch)
Assigned to: Daniel Berger (djberg96)
Summary: Handling of Windows paths broken in 1.3.3

Initial Comment:
Installing gems from local drives other than the current is broken on Windows. RubyGems strips the drive letter (through using the URI class for something which isn't an URI).

C:\> gem install p:\path\to\mygem-2.1.18.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /path/to/mygem-2.1.18.gem

Then I tried to pass a valid URI:

C:\> gem install file:///p:/path/to/mygem-2.1.18.gem

But that doesn't work either;

ERROR:  could not find gem file:///p:/path/to/mygem-2.1.18.gem locally or in a repository

I believe this is because URI#path returns "/p:/path/to/mygem..." (with leading slash), which is not a valid path on Windows.

Finally, I attempted to hack RubyGems to prefix file:/// itself, but I don't understand the reason for this line of code in remote_fetcher.rb:

        remote_gem_path = File.join(path, 'gems', gem_file_name)

That causes this error instead:

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - p:/path/to/gems/mygem-2.1.18.gem

Notice the extra /gems/ path.


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 18:28

Message:
Set HOMEDIRECTORY worked. Thanks a lot.

I was able to install the rhodes gem.

Thanks for helping a newbie :)

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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 17:38

Message:
Hello,

First you need to use SET VARIABLE=VALUE, not "env" as env is not a native Windows command, perhaps from gnuwin32.

Also, you can modify those at runtime, but everyt ie you start a new command prompt or session, the values will be restored with the values your Admin set for you.

Is Z: mapped? do you have write permissions to the root?

Can you do this?

ruby -rfileutils -ve "FileUtils.touch 'z:/foo'"



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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 17:34

Message:
My HomeDrive still remains Z: after I used env HOMEDRIVE=C:

C:\Ruby192\bin>set gem
Environment variable gem not defined

C:\Ruby192\bin>set home
HOMEDRIVE=Z:
HOMEPATH=\
HOMESHARE=\(servername)\users\saurabh.doshi


I am using 32 bit Win XP and have installed gnuwin32. I have added C:\gnuwin32\bin to my PATH env variable.

Does the Default drive change from Z: to C: be done at the domain level by my System  Administrator? 

Thanks,










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 17:05

Message:
Can you tell me what "SET GEM" tells you? Also, what "SET HOME" tells you?

Please include complete output. Also, include details about the exact version of Windows you're using,a nd if is 64bits, if you had E-editor installed or cygwin.

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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 16:55

Message:
Thanks Luis,

Apologies for posting this against this thread.

Here is my gem env :

RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.9.2 (2010-08-18 patchlevel 0) [i386-mingw32]
  - INSTALLATION DIRECTORY: C:/Ruby192/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: C:/Ruby192/bin/ruby.exe
  - EXECUTABLE DIRECTORY: C:/Ruby192/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mingw32
  - GEM PATHS:
     - C:/Ruby192/lib/ruby/gems/1.9.1
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://rubygems.org/

My HomeDrive was Z:, I changed it to C:

HomePath = \

USERPROFILE=C:\Documents and Settings\saurabh.doshi

Still getting the error. Based on my environment, do I need to set the GEM_HOME variable?










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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-13 10:16

Message:
Saurabh,

Seems to me that your report has nothing to do with the original report here.

See, it is indicating "Z:/" not been accesible or exist, while you have C: as your system drive.

Please provide the full output of "gem env" when reporting any error.

Also, see what are the values of HOME, HOMEDRIVE, HOMEPATH and USERPROFILE in your system (use SET command).


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

Comment By: Saurabh Doshi (cashkap)
Date: 2010-09-13 10:04

Message:
I have used the One Click Ruby installer(1.9.2) and have installed it as C:\Ruby192.

I am facing the same error:

C:\Ruby192\bin>gem install rake
ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - Z:/

I have tried changing the default mapping from z: to c: but havent found success. I don't have admin priv on my m/c.

can some please guide me on this

Thanks,

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 13:55

Message:
Fixed in SVN.

Thanks for the report.

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:59

Message:
Oops, let's update that to "if Gem.win_platform && source_uri.scheme"

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 11:51

Message:
I think this patch does what we want:

--- remote_fetcher.orig Sun Apr 12 13:52:46 2009
+++ remote_fetcher.rb   Tue May 12 09:35:30 2009
@@ -139,7 +139,11 @@
         Gem.configuration.really_verbose
     when nil then # TODO test for local overriding cache
       begin
-        FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        if Gem.win_platform?
+          FileUtils.cp URI.unescape(source_uri.scheme + ':' + source_uri.path), local_gem_path
+        else
+          FileUtils.cp URI.unescape(source_uri.path), local_gem_path
+        end
       rescue Errno::EACCES
         local_gem_path = source_uri.to_s
       end

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:46

Message:
Looks like a bug in line 142 of remote_fetcher.rb related to the URI class and the fact that we're stripping the scheme off of Windows paths.

It works for "C:" because, iirc, certain Ruby core File methods assume "C:" if no drive is found. We'll have to fix this.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 09:22

Message:
Well, this is odd. I tried installing from an explicit path using "C:\Documents and Settings\djberge". That worked fine. But, when I tried to install from a drive other than "C:", things went bad:

C:\Documents and Settings\djberge>gem install "z:\djberge on my mac\documents\workspace\ptools\ptools-1.1.7.gem" --verbose --debug
Exception `NameError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:161 - uninitialized constant Gem::Commands::InstallCommand
Exception `IOError' at C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:50 - closed stream
Installing gem ptools-1.1.7
Exception `Errno::ENOENT' at C:/Ruby/lib/ruby/1.8/fileutils.rb:1200 - No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem

ERROR:  While executing gem ... (Errno::ENOENT)
    No such file or directory - /djberge on my mac/documents/workspace/ptools/ptools-1.1.7.gem
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1200:in `lstat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1178:in `stat'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1260:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:463:in `copy_file'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:383:in `cp'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1395:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1411:in `fu_each_src_dest0'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:1393:in `fu_each_src_dest'
        C:/Ruby/lib/ruby/1.8/fileutils.rb:382:in `cp'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142:in `download'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:232:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:222:in `install'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:78:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `each'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:75:in `execute'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:254:in `invoke'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `process_args'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run'
        C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run'
        C:/Ruby/bin/gem:21

I'll have to investigate further to determine if this is a bug in rubygems or fileutils.

Regards,

Dan

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

Comment By: Daniel Berger (djberg96)
Date: 2009-05-12 08:20

Message:
The use of file urls is meant for use with the --source flag (i.e. from a local repository), which is why the method includes the 'gems' directory.

However, the "gem install p:\path\to\mygem-2.1.18.gem" should work. I'll take a look.

Regards,

Dan

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

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

From noreply at rubyforge.org  Mon Sep 20 16:37:05 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 20 Sep 2010 16:37:05 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28582 ] gem build on a yaml
	spec file fails because of missing require 'yaml'
Message-ID: <20100920203705.AEC7C185835A@rubyforge.org>

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

Category: `gem` commands (other)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Clint Byrum (spamaps)
Assigned to: Nobody (None)
Summary: gem build on a yaml spec file fails because of missing require 'yaml'

Initial Comment:
If I run gem build on a yaml gemspec, and I have no .gemrc, I get this error:


ubuntu at ip-10-196-111-253:~/g$ gem build metadata 
ERROR:  While executing gem ... (NameError)
    uninitialized constant Gem::Specification::YAML

However, if there is a .gemrc, I don't get an error.

This is because rubygems/config_file.rb requires yaml.

rubygems/specification.rb should require yaml at the top of the file as it uses YAML directly in its own code.


RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7
  - RUBY VERSION: 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux]
  - INSTALLATION DIRECTORY: /var/lib/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /var/lib/gems/1.8
     - /home/clint/.gem/ruby/1.8
  - 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=28582&group_id=126

From jeremy at hinegardner.org  Mon Sep 20 17:05:16 2010
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Mon, 20 Sep 2010 15:05:16 -0600
Subject: [Rubygems-developers] [ANN] stickler gem server 2.0.2 released
Message-ID: <20100920210516.GL32500@hinegardner.org>

Hi all,

You might have seen this announced on ruby-talk, and I figured it might
be of use to some of you.  I've just pushed the latest release of stickler.

Stickler is a tool to organize and maintain an internal gem repository.
Similar to running your own instance of gemcutter, or maybe geminabox, in that
it responds to push and yank requests and you can use it as a gem source.

It also adds the capability to mirror gems from rubygems.org or another upstream
gem server.

Documentation: http://www.copiousfreetime.org/projects/stickler/
Github       : http://github.com/copiousfreetime/stickler

thanks,

-jeremy

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


From nick at quaran.to  Mon Sep 20 23:46:27 2010
From: nick at quaran.to (Nick Quaranto)
Date: Mon, 20 Sep 2010 23:46:27 -0400
Subject: [Rubygems-developers] [ANN] stickler gem server 2.0.2 released
In-Reply-To: <20100920210516.GL32500@hinegardner.org>
References: <20100920210516.GL32500@hinegardner.org>
Message-ID: <AANLkTimpkYoLysSG4Mk7ba0eEg2piUU778nUbGBKuwAT@mail.gmail.com>

Cool idea, jeremy. I wonder if you could work together with or replace

http://github.com/cwninja/geminabox ?

Also, maybe we could share code between rubygems/gemcutter
and copiousfreetime/stickler esp on the rack end? Let me know if you think
that's feasible.

-Nick

On Mon, Sep 20, 2010 at 5:05 PM, Jeremy Hinegardner
<jeremy at hinegardner.org>wrote:

> Hi all,
>
> You might have seen this announced on ruby-talk, and I figured it might
> be of use to some of you.  I've just pushed the latest release of stickler.
>
> Stickler is a tool to organize and maintain an internal gem repository.
> Similar to running your own instance of gemcutter, or maybe geminabox, in
> that
> it responds to push and yank requests and you can use it as a gem source.
>
> It also adds the capability to mirror gems from rubygems.org or another
> upstream
> gem server.
>
> Documentation: http://www.copiousfreetime.org/projects/stickler/
> Github       : http://github.com/copiousfreetime/stickler
>
> thanks,
>
> -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 jeremy at hinegardner.org  Tue Sep 21 12:10:53 2010
From: jeremy at hinegardner.org (Jeremy Hinegardner)
Date: Tue, 21 Sep 2010 10:10:53 -0600
Subject: [Rubygems-developers] [ANN] stickler gem server 2.0.2 released
In-Reply-To: <AANLkTimpkYoLysSG4Mk7ba0eEg2piUU778nUbGBKuwAT@mail.gmail.com>
References: <20100920210516.GL32500@hinegardner.org>
	<AANLkTimpkYoLysSG4Mk7ba0eEg2piUU778nUbGBKuwAT@mail.gmail.com>
Message-ID: <20100921161053.GO32500@hinegardner.org>

Yes, stickler and geminabox are similar in functionality and could be merged
into some lightweight standalone gemserver.  They both allow for the upload
of gems into their respective servers, and they both can be uses with --source.

They differ in that geminabox uses the 'gem inabox' gem command which uploads
the gem to an '/upload' uri in the geminabox server and stickler implements some
of the server side of the gemcutter /api/v1.   I would actually like to do away 
with stickler's client side commandline and use 'gem push' and 'gem yank'
natively, but the only way to switch RUBYGEM_HOST, at least from my digging,
is via an environment variable.

Along those lines, I'd like to get a patch together to have 'push', 'yank', etc
either take a --source option, or a --rubygems-host option, or have something in
.gem/config or similar to allow for different targets of gemcutter commands.
Thoughts?

As for sharing code on the rack side between rubygems/gemcutter and stickler,
That should be feasible.  Stickler's server is a stack of sinatra middleware.
I've separated them out into different functionalities:

    Gemcutter : implementing gemcutter specific calls (push/yank)
        Index : implements the gem server functionality (specs/marshal/gem/etc )

There's a few others in there for specific use cases of stickler.  These
two are what share functionality with gemcutter. 

enjoy,

-jeremy

On Mon, Sep 20, 2010 at 11:46:27PM -0400, Nick Quaranto wrote:
> Cool idea, jeremy. I wonder if you could work together with or replace
> 
> http://github.com/cwninja/geminabox ?
> 
> Also, maybe we could share code between rubygems/gemcutter
> and copiousfreetime/stickler esp on the rack end? Let me know if you think
> that's feasible.
> 
> -Nick
> 
> On Mon, Sep 20, 2010 at 5:05 PM, Jeremy Hinegardner
> <jeremy at hinegardner.org>wrote:
> 
> > Hi all,
> >
> > You might have seen this announced on ruby-talk, and I figured it might
> > be of use to some of you.  I've just pushed the latest release of stickler.
> >
> > Stickler is a tool to organize and maintain an internal gem repository.
> > Similar to running your own instance of gemcutter, or maybe geminabox, in
> > that
> > it responds to push and yank requests and you can use it as a gem source.
> >
> > It also adds the capability to mirror gems from rubygems.org or another
> > upstream
> > gem server.
> >
> > Documentation: http://www.copiousfreetime.org/projects/stickler/
> > Github       : http://github.com/copiousfreetime/stickler
> >
> > thanks,
> >
> > -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
> >

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


From noreply at rubyforge.org  Thu Sep 23 18:57:09 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Sep 2010 18:57:09 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with
	rubygems1.3.7 fails on running with ruby version 1.9.2,
	see traceback.
Message-ID: <20100923225709.1224C185837A@rubyforge.org>

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

Category: RubyGems installer (setup.rb)
Group: v1.3.x
Status: Open
Resolution: None
Priority: 3
Submitted By: Dinesh Arora (dinesharora)
Assigned to: Nobody (None)
Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback.

Initial Comment:

C:\RubyGems\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

C:\RubyGems\rubygems-1.3.7>

C:\RubyGems\rubygems-1.3.7>ruby setup.rb
C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di
rectories': undefined method `path' for Gem:Module (NoMethodError)
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from
_installed_gems'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in
`init_gemspecs'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in
`initialize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche
r'
        from <internal:prelude>:10:in `synchronize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)
>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'

C:\RubyGems\rubygems-1.3.7>


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

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

From noreply at rubyforge.org  Thu Sep 23 19:07:13 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Sep 2010 19:07:13 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with
	rubygems1.3.7 fails on running with ruby version 1.9.2,
	see traceback.
Message-ID: <20100923230713.AD1C71678310@rubyforge.org>

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

Category: RubyGems installer (setup.rb)
Group: v1.3.x
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Dinesh Arora (dinesharora)
Assigned to: Nobody (None)
Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback.

Initial Comment:

C:\RubyGems\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

C:\RubyGems\rubygems-1.3.7>

C:\RubyGems\rubygems-1.3.7>ruby setup.rb
C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di
rectories': undefined method `path' for Gem:Module (NoMethodError)
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from
_installed_gems'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in
`init_gemspecs'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in
`initialize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche
r'
        from <internal:prelude>:10:in `synchronize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)
>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'

C:\RubyGems\rubygems-1.3.7>


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

>Comment By: Luis Lavena (luislavena)
Date: 2010-09-23 20:07

Message:
You should not be attempting to install RubyGems on Ruby 1.9.1 or 1.9.2

RubyGems is bundled with Ruby since 1.9.1

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

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

From noreply at rubyforge.org  Thu Sep 23 19:16:52 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Sep 2010 19:16:52 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with
	rubygems1.3.7 fails on running with ruby version 1.9.2,
	see traceback.
Message-ID: <20100923231653.0C5701779944@rubyforge.org>

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

Category: RubyGems installer (setup.rb)
Group: v1.3.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Dinesh Arora (dinesharora)
Assigned to: Nobody (None)
Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback.

Initial Comment:

C:\RubyGems\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

C:\RubyGems\rubygems-1.3.7>

C:\RubyGems\rubygems-1.3.7>ruby setup.rb
C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di
rectories': undefined method `path' for Gem:Module (NoMethodError)
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from
_installed_gems'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in
`init_gemspecs'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in
`initialize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche
r'
        from <internal:prelude>:10:in `synchronize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)
>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'

C:\RubyGems\rubygems-1.3.7>


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

>Comment By: Dinesh Arora (dinesharora)
Date: 2010-09-23 16:16

Message:
Thank you Luis for the quick reply. The documentation at 
rubyonrails.org is incorrect. It says to install ruby and 
then rubygems. Does not differentiate between versions 
1.8.x or 1.9.x. See http://rubyonrails.org/download 

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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-23 16:07

Message:
You should not be attempting to install RubyGems on Ruby 1.9.1 or 1.9.2

RubyGems is bundled with Ruby since 1.9.1

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

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

From noreply at rubyforge.org  Thu Sep 23 19:21:00 2010
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Sep 2010 19:21:00 -0400 (EDT)
Subject: [Rubygems-developers] [ rubygems-Bugs-28597 ] setup.rb with
	rubygems1.3.7 fails on running with ruby version 1.9.2,
	see traceback.
Message-ID: <20100923232100.19FE11678310@rubyforge.org>

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

Category: RubyGems installer (setup.rb)
Group: v1.3.x
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Dinesh Arora (dinesharora)
Assigned to: Nobody (None)
Summary: setup.rb with rubygems1.3.7 fails on running with ruby version 1.9.2, see traceback.

Initial Comment:

C:\RubyGems\rubygems-1.3.7>ruby -v
ruby 1.9.2p0 (2010-08-18) [i386-mingw32]

C:\RubyGems\rubygems-1.3.7>

C:\RubyGems\rubygems-1.3.7>ruby setup.rb
C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:68:in `installed_spec_di
rectories': undefined method `path' for Gem:Module (NoMethodError)
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/source_index.rb:58:in `from
_installed_gems'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:883:in `source_index'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:81:in
`init_gemspecs'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems/gem_path_searcher.rb:13:in
`initialize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `new'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:841:in `block in searche
r'
        from <internal:prelude>:10:in `synchronize'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:840:in `searcher'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:479:in `find_files'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:983:in `load_plugins'
        from C:/RubyGems/rubygems-1.3.7/lib/rubygems.rb:1139:in `<top (required)
>'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from <internal:lib/rubygems/custom_require>:29:in `require'
        from setup.rb:24:in `<main>'

C:\RubyGems\rubygems-1.3.7>


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

>Comment By: Luis Lavena (luislavena)
Date: 2010-09-23 20:20

Message:
Ah, I see

I would recommend you open a ticket with Ruby on Rails website maintainers to improve these pages.

RubyGems is needed for 1.8.x version of Ruby. A clear omission in the step.
(And that is not 100% true as RubyInstaller actually bundle it for you ;-)

Regards.

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

Comment By: Dinesh Arora (dinesharora)
Date: 2010-09-23 20:16

Message:
Thank you Luis for the quick reply. The documentation at 
rubyonrails.org is incorrect. It says to install ruby and 
then rubygems. Does not differentiate between versions 
1.8.x or 1.9.x. See http://rubyonrails.org/download 

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

Comment By: Luis Lavena (luislavena)
Date: 2010-09-23 20:07

Message:
You should not be attempting to install RubyGems on Ruby 1.9.1 or 1.9.2

RubyGems is bundled with Ruby since 1.9.1

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

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

From luislavena at gmail.com  Sun Sep 26 17:20:56 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Sep 2010 18:20:56 -0300
Subject: [Rubygems-developers] Current state of master
Message-ID: <AANLkTik6bYk1S5pLSdmuBSMNshW-iyYT4uaHOKnndCQd@mail.gmail.com>

Hey guys, wanted to check what is the state of master.

Right now I'm having some weird failures in test_gem_command_manager.rb:

C:\Users\Luis\Projects\oss\rubygems>ruby -Ilib test\test_gem_command_manager.rb
Test run options: --seed 64614

Loaded suite test/test_gem_command_manager
Started
....F...F
Finished in 0.231013 seconds.

  1) Failure:
test_run_crash_command(TestGemCommandManager)
[test/test_gem_command_manager.rb:32]:
Expected "ERROR:  Loading command: crash (RuntimeError)", not "ERROR:
Loading command: crash (LoadError)".

  2) Failure:
test_run_interrupt(TestGemCommandManager) [test/test_gem_command_manager.rb:20]:
Expected "ERROR:  Interrupted\n", not "ERROR:  While executing gem ...
(RuntimeError)\n    Unknown command interrupt\n".

9 tests, 49 assertions, 2 failures, 0 errors, 0 skips

====

And others.

Nothing has changed in my setup for me to question it, so wanted to
check with you guys before do anything weird.

Thank you.
-- 
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 luislavena at gmail.com  Sun Sep 26 17:24:43 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Sep 2010 18:24:43 -0300
Subject: [Rubygems-developers] Current state of master
In-Reply-To: <AANLkTik6bYk1S5pLSdmuBSMNshW-iyYT4uaHOKnndCQd@mail.gmail.com>
References: <AANLkTik6bYk1S5pLSdmuBSMNshW-iyYT4uaHOKnndCQd@mail.gmail.com>
Message-ID: <AANLkTikKFCCFOwudV2A3pyrDtTuN+hLGk0geQMRR7ibq@mail.gmail.com>

Please ignore this, stupidity has been raising lately in my brain.

ruby -Ilib;test solve that individual test. will get the real ones
with problems and post again.

-- 
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 luislavena at gmail.com  Sun Sep 26 17:44:07 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Sep 2010 18:44:07 -0300
Subject: [Rubygems-developers] Pull Request #2: progress downloader
Message-ID: <AANLkTi=WOY0GBT7kAJ6LE44sJ=DPRr82nB5ShzUioK2Y@mail.gmail.com>

Hello guys,

In case you didn't see the pull request #2:

http://github.com/rubygems/rubygems/pull/2

I wanted to bring it to attention.

Basically the problem is raised due big gems, particularly QtBindings
which Windows binaries weight 49MB and the pure-ruby one is 1.6MB

The problem with such gems is evident: there is no 'clue' on what is going on.

Over the pull request I mentioned that adding ProgressBar class is not ideal:

1) makes RubyGems depend on another piece of code

2) It clashes with another definition of ProgressBar

I suggested do a clean and simple implementation as Rubinius guys did
for the downloader.

Is there any other point of concerns I should think off? Any UI that
will be broken by this? Also, any recommendation to properly fake this
out?

This affects mostly binary gems or jruby ones that bundle big .jar files in it.

Thank you for your time and looking forward your comments.
-- 
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 Sep 26 22:26:29 2010
From: jftucker at gmail.com (James Tucker)
Date: Sun, 26 Sep 2010 23:26:29 -0300
Subject: [Rubygems-developers] Pull Request #2: progress downloader
In-Reply-To: <AANLkTi=WOY0GBT7kAJ6LE44sJ=DPRr82nB5ShzUioK2Y@mail.gmail.com>
References: <AANLkTi=WOY0GBT7kAJ6LE44sJ=DPRr82nB5ShzUioK2Y@mail.gmail.com>
Message-ID: <C671AA5C-0377-4793-83B1-C9E5507FA0F5@gmail.com>

spinner = %w[|/-\]
class << spinner; def next; @s||=0; self[@s]; ensure; @s = @s + 1 == size ? 0 : @s + 1; end
t = Thread.new do
while true
	sleep 0.5
	$stdout.sync = true
	ui.print "\r#{spinner.next}"
end
end


# when done:
t.kill

seems cheap and portable enough, with a bit more work, would this do?

(sorry for bugs, 5 mins whilst wine'd up)

On 26 Sep 2010, at 18:44, Luis Lavena wrote:

> Hello guys,
> 
> In case you didn't see the pull request #2:
> 
> http://github.com/rubygems/rubygems/pull/2
> 
> I wanted to bring it to attention.
> 
> Basically the problem is raised due big gems, particularly QtBindings
> which Windows binaries weight 49MB and the pure-ruby one is 1.6MB
> 
> The problem with such gems is evident: there is no 'clue' on what is going on.
> 
> Over the pull request I mentioned that adding ProgressBar class is not ideal:
> 
> 1) makes RubyGems depend on another piece of code
> 
> 2) It clashes with another definition of ProgressBar
> 
> I suggested do a clean and simple implementation as Rubinius guys did
> for the downloader.
> 
> Is there any other point of concerns I should think off? Any UI that
> will be broken by this? Also, any recommendation to properly fake this
> out?
> 
> This affects mostly binary gems or jruby ones that bundle big .jar files in it.
> 
> Thank you for your time and looking forward your comments.
> -- 
> 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
> _______________________________________________
> 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 Sep 26 22:34:20 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 26 Sep 2010 23:34:20 -0300
Subject: [Rubygems-developers] Pull Request #2: progress downloader
In-Reply-To: <C671AA5C-0377-4793-83B1-C9E5507FA0F5@gmail.com>
References: <AANLkTi=WOY0GBT7kAJ6LE44sJ=DPRr82nB5ShzUioK2Y@mail.gmail.com>
	<C671AA5C-0377-4793-83B1-C9E5507FA0F5@gmail.com>
Message-ID: <AANLkTimu3wPp-91UZ3wRKk7yQpw_0+PvBGFzUQ0q42vR@mail.gmail.com>

On Sun, Sep 26, 2010 at 11:26 PM, James Tucker <jftucker at gmail.com> wrote:
> spinner = %w[|/-\]
> class << spinner; def next; @s||=0; self[@s]; ensure; @s = @s + 1 == size ? 0 : @s + 1; end
> t = Thread.new do
> while true
> ? ? ? ?sleep 0.5
> ? ? ? ?$stdout.sync = true
> ? ? ? ?ui.print "\r#{spinner.next}"
> end
> end
>
>
> # when done:
> t.kill
>
> seems cheap and portable enough, with a bit more work, would this do?
>
> (sorry for bugs, 5 mins whilst wine'd up)
>

Hehe,

I think the spinner will just spin, it will not give you a feedback of
what is going on.

Having a more progress-like bar/status (heck, even a simple
percentage) will be way more useful.

-- 
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 luislavena at gmail.com  Wed Sep 29 00:22:20 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 29 Sep 2010 01:22:20 -0300
Subject: [Rubygems-developers] Pull Request #2: progress downloader
In-Reply-To: <AANLkTimu3wPp-91UZ3wRKk7yQpw_0+PvBGFzUQ0q42vR@mail.gmail.com>
References: <AANLkTi=WOY0GBT7kAJ6LE44sJ=DPRr82nB5ShzUioK2Y@mail.gmail.com>
	<C671AA5C-0377-4793-83B1-C9E5507FA0F5@gmail.com>
	<AANLkTimu3wPp-91UZ3wRKk7yQpw_0+PvBGFzUQ0q42vR@mail.gmail.com>
Message-ID: <AANLkTinP98VoxZvbQZqKAL0qgu7EU7-v6HBzV1y5ncOP@mail.gmail.com>

Kicking this again.

Ryan melt worked out the quirks I mentioned in the pull request:

http://github.com/rubygems/rubygems/pull/2

I just ran all the test and none is broken.

However, while I believe this particular feature is hard to test, I'm
not confortable with the UI interation.

For example, we have 'say' and 'ask' to deal with stream / UI
redirection and automation, but having those print and STDOUT.flush
will not help.

Was thinking that perhaps this should be exposed by a helper instead?
Something like:

progress file_name, current_bytes, total_bytes
(during chunk download)

progress :complete
(to erase the progress report)

I cannot stress how this is becoming important lately with more and
more developers packaging gems that are way more than just simple ruby
files (jar, dlls, compiled extensions, even documentation).

Just installing Rails 3 is a bliss knowing what is going on:

http://screenr.com/CU4

Thoughts?
-- 
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  Wed Sep 29 05:12:16 2010
From: transfire at gmail.com (Trans)
Date: Wed, 29 Sep 2010 02:12:16 -0700 (PDT)
Subject: [Rubygems-developers] gem lock
Message-ID: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>

I recently noticed that `gem` had a `lock` command. I played around
with it and found it mostly useless. First, one has to provide it the
name and version of an installed gem. It would be much more useful if
it could take a gemspec file instead. Also, it does not appear to
utilize remote gem source(s) to resolve best dependencies, but simply
uses the versions of gems installed locally. It would be much more
useful if it recognized the --remote option and acted accordingly.
Also, it could use an option to include/not-include development
dependencies.


From jftucker at gmail.com  Wed Sep 29 07:24:20 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 29 Sep 2010 08:24:20 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
Message-ID: <3BCBA3E8-BAF5-4A45-8146-FF35EAA103FA@gmail.com>


On 29 Sep 2010, at 06:12, Trans wrote:

> I recently noticed that `gem` had a `lock` command. I played around
> with it and found it mostly useless. First, one has to provide it the
> name and version of an installed gem. It would be much more useful if
> it could take a gemspec file instead. Also, it does not appear to
> utilize remote gem source(s) to resolve best dependencies, but simply
> uses the versions of gems installed locally. It would be much more
> useful if it recognized the --remote option and acted accordingly.
> Also, it could use an option to include/not-include development
> dependencies.

This is a simple manifest generator that could have been used to solve a small handful of the problems that Isolate and Bundler solve, but rubyists don't seem to like maintaining their own manifests. The other unfortunate thing is that it doesn't actually isolate in any way, still allowing for other gems to be loaded, and so on.

Outputting a gemspec would not be useful unless that could be loaded at runtime, as it's really designed to solve the problem of ensuring a consistent environment at runtime. Gemspecs need only specify the top level dependencies in the dependency heirachy, not an expanded list such as this.

The resolver system used here is actually not fully correct either, I've tried to explain this to some folks on IRC a while back when they were accusing Bundler of bloat, but I was shot down, anyway, here's some output to be considered (spot the rack versions):

raggi at mbk: ~ % gem dep actionpack -v 2.3.5
Gem actionpack-2.3.5
  activesupport (= 2.3.5, runtime)
  rack (~> 1.0.0, runtime)

raggi at mbk: ~ % gem lock thin-1.2.7 rails-2.3.5
require 'rubygems'
gem 'thin', '= 1.2.7'
gem 'rails', '= 2.3.5'
gem 'rack', '= 1.2.1'
gem 'eventmachine', '= 0.12.11'
gem 'daemons', '= 1.1.0'
gem 'rake', '= 0.8.7'
gem 'activesupport', '= 2.3.5'
gem 'activerecord', '= 2.3.5'
gem 'actionpack', '= 2.3.5'
gem 'actionmailer', '= 2.3.5'
gem 'activeresource', '= 2.3.5'

raggi at mbk: ~ % gem lock rails-2.3.5 thin-1.2.7 | ruby
/opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:233:in `activate': can't activate rack (= 1.2.1, runtime) for [], already activated rack-1.0.1 for ["actionpack-2.3.5", "rails-2.3.5"] (Gem::LoadError)
	from /opt/local/lib/ruby/site_ruby/1.8/rubygems.rb:1082:in `gem'
	from -:10


I would strongly recommend this feature be deprecated soon.

From luislavena at gmail.com  Wed Sep 29 15:19:04 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 29 Sep 2010 16:19:04 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
Message-ID: <AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>

On Wed, Sep 29, 2010 at 6:12 AM, Trans <transfire at gmail.com> wrote:
> I recently noticed that `gem` had a `lock` command. I played around
> with it and found it mostly useless. First, one has to provide it the
> name and version of an installed gem. It would be much more useful if
> it could take a gemspec file instead. Also, it does not appear to
> utilize remote gem source(s) to resolve best dependencies, but simply
> uses the versions of gems installed locally. It would be much more
> useful if it recognized the --remote option and acted accordingly.
> Also, it could use an option to include/not-include development
> dependencies.
>

I actually don't remember the last time I used that command and
discarded by ~> in my gem dependencies

Do we have a 1.4.x Roadmap? If not, this for sure can be removed then.

Eric? Comments?

-- 
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  Wed Sep 29 17:28:58 2010
From: transfire at gmail.com (Trans)
Date: Wed, 29 Sep 2010 14:28:58 -0700 (PDT)
Subject: [Rubygems-developers] gem lock
In-Reply-To: <AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
Message-ID: <492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>

On Sep 29, 3:19?pm, Luis Lavena <luislav... at gmail.com> wrote:
> On Wed, Sep 29, 2010 at 6:12 AM, Trans <transf... at gmail.com> wrote:
> > I recently noticed that `gem` had a `lock` command. I played around
> > with it and found it mostly useless. First, one has to provide it the
> > name and version of an installed gem. It would be much more useful if
> > it could take a gemspec file instead. Also, it does not appear to
> > utilize remote gem source(s) to resolve best dependencies, but simply
> > uses the versions of gems installed locally. It would be much more
> > useful if it recognized the --remote option and acted accordingly.
> > Also, it could use an option to include/not-include development
> > dependencies.
>
> I actually don't remember the last time I used that command and
> discarded by ~> in my gem dependencies
>
> Do we have a 1.4.x Roadmap? If not, this for sure can be removed then.

Why remove it? Why not just fix it?

From luislavena at gmail.com  Wed Sep 29 17:31:36 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 29 Sep 2010 18:31:36 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
Message-ID: <AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>

On Wed, Sep 29, 2010 at 6:28 PM, Trans <transfire at gmail.com> wrote:
> On Sep 29, 3:19?pm, Luis Lavena <luislav... at gmail.com> wrote:
>> On Wed, Sep 29, 2010 at 6:12 AM, Trans <transf... at gmail.com> wrote:
>> > I recently noticed that `gem` had a `lock` command. I played around
>> > with it and found it mostly useless. First, one has to provide it the
>> > name and version of an installed gem. It would be much more useful if
>> > it could take a gemspec file instead. Also, it does not appear to
>> > utilize remote gem source(s) to resolve best dependencies, but simply
>> > uses the versions of gems installed locally. It would be much more
>> > useful if it recognized the --remote option and acted accordingly.
>> > Also, it could use an option to include/not-include development
>> > dependencies.
>>
>> I actually don't remember the last time I used that command and
>> discarded by ~> in my gem dependencies
>>
>> Do we have a 1.4.x Roadmap? If not, this for sure can be removed then.
>
> Why remove it? Why not just fix it?

The logic for dependency resolution (ala: bundler AOT) is not easy
stuff which could grow our codebase and maintenance requirements.

IMHO with Bundler and Isolate out there, posible usefulness of lock
has disappeared.

But, if you want it fixed, you can fork it and send the pull request,
I would love to review it and if it works, happy to merge it.

--
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  Wed Sep 29 17:51:06 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 29 Sep 2010 18:51:06 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
Message-ID: <FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>


On 29 Sep 2010, at 18:31, Luis Lavena wrote:

> On Wed, Sep 29, 2010 at 6:28 PM, Trans <transfire at gmail.com> wrote:
>> On Sep 29, 3:19 pm, Luis Lavena <luislav... at gmail.com> wrote:
>>> On Wed, Sep 29, 2010 at 6:12 AM, Trans <transf... at gmail.com> wrote:
>>>> I recently noticed that `gem` had a `lock` command. I played around
>>>> with it and found it mostly useless. First, one has to provide it the
>>>> name and version of an installed gem. It would be much more useful if
>>>> it could take a gemspec file instead. Also, it does not appear to
>>>> utilize remote gem source(s) to resolve best dependencies, but simply
>>>> uses the versions of gems installed locally. It would be much more
>>>> useful if it recognized the --remote option and acted accordingly.
>>>> Also, it could use an option to include/not-include development
>>>> dependencies.
>>> 
>>> I actually don't remember the last time I used that command and
>>> discarded by ~> in my gem dependencies
>>> 
>>> Do we have a 1.4.x Roadmap? If not, this for sure can be removed then.
>> 
>> Why remove it? Why not just fix it?
> 
> The logic for dependency resolution (ala: bundler AOT) is not easy
> stuff which could grow our codebase and maintenance requirements.
> 
> IMHO with Bundler and Isolate out there, posible usefulness of lock
> has disappeared.
> 
> But, if you want it fixed, you can fork it and send the pull request,
> I would love to review it and if it works, happy to merge it.

I would be wary to merge in any update to this feature that doesn't fix the issues of the style I just highlighted. In fact, it should pass all of the dependency collision spec examples that you might find in the bundler resolver tests. If it doesn't, it's basically broken.

As we don't have users using this feature, and it's broken, I would suggest it should be removed by the next major release unless someone has fixed it.

From luislavena at gmail.com  Wed Sep 29 17:55:15 2010
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 29 Sep 2010 18:55:15 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
Message-ID: <AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>

On Wed, Sep 29, 2010 at 6:51 PM, James Tucker <jftucker at gmail.com> wrote:
>
> On 29 Sep 2010, at 18:31, Luis Lavena wrote:
>>
>> But, if you want it fixed, you can fork it and send the pull request,
>> I would love to review it and if it works, happy to merge it.
>
> I would be wary to merge in any update to this feature that doesn't fix the issues of the style I just highlighted. In fact, it should pass all of the dependency collision spec examples that you might find in the bundler resolver tests. If it doesn't, it's basically broken.
>
> As we don't have users using this feature, and it's broken, I would suggest it should be removed by the next major release unless someone has fixed it.

Point taken, I believe it was obvious but just to clarify: review will
use bundler complex dependency resolution as comparison for approval.

-- 
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 ryand-ruby at zenspider.com  Wed Sep 29 21:00:14 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 29 Sep 2010 18:00:14 -0700
Subject: [Rubygems-developers] gem lock
In-Reply-To: <AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
Message-ID: <E8146B52-A090-4890-AD5A-452864029123@zenspider.com>


On Sep 29, 2010, at 14:55 , Luis Lavena wrote:

> On Wed, Sep 29, 2010 at 6:51 PM, James Tucker <jftucker at gmail.com> wrote:
>> 
>> On 29 Sep 2010, at 18:31, Luis Lavena wrote:
>>> 
>>> But, if you want it fixed, you can fork it and send the pull request,
>>> I would love to review it and if it works, happy to merge it.
>> 
>> I would be wary to merge in any update to this feature that doesn't fix the issues of the style I just highlighted. In fact, it should pass all of the dependency collision spec examples that you might find in the bundler resolver tests. If it doesn't, it's basically broken.
>> 
>> As we don't have users using this feature, and it's broken, I would suggest it should be removed by the next major release unless someone has fixed it.
> 
> Point taken, I believe it was obvious but just to clarify: review will
> use bundler complex dependency resolution as comparison for approval.

I've been talking to Eric about the possibility of merging Isolate into rubygems and he's agreed that it is a good idea. I think in light of that we can remove gem lock entirely and have a cleaner overall impl. It is old and busted and nobody actually uses it to the best of our knowledge so me might as well put a bullet in it.


From jftucker at gmail.com  Wed Sep 29 22:57:19 2010
From: jftucker at gmail.com (James Tucker)
Date: Wed, 29 Sep 2010 23:57:19 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
Message-ID: <3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>


On 29 Sep 2010, at 22:00, Ryan Davis wrote:
> I've been talking to Eric about the possibility of merging Isolate into rubygems and he's agreed that it is a good idea.

Why?


From ryand-ruby at zenspider.com  Wed Sep 29 23:12:46 2010
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 29 Sep 2010 20:12:46 -0700
Subject: [Rubygems-developers] gem lock
In-Reply-To: <3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
	<3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
Message-ID: <6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>


On Sep 29, 2010, at 19:57 , James Tucker wrote:

> 
> On 29 Sep 2010, at 22:00, Ryan Davis wrote:
>> I've been talking to Eric about the possibility of merging Isolate into rubygems and he's agreed that it is a good idea.
> 
> Why?

for the same reason that `gem lock` exists, only it works and people use it.

From jftucker at gmail.com  Wed Sep 29 23:26:30 2010
From: jftucker at gmail.com (James Tucker)
Date: Thu, 30 Sep 2010 00:26:30 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
	<3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
	<6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>
Message-ID: <41A44E91-EA17-427E-87FA-72DBB24BE98B@gmail.com>


On 30 Sep 2010, at 00:12, Ryan Davis wrote:

> 
> On Sep 29, 2010, at 19:57 , James Tucker wrote:
> 
>> 
>> On 29 Sep 2010, at 22:00, Ryan Davis wrote:
>>> I've been talking to Eric about the possibility of merging Isolate into rubygems and he's agreed that it is a good idea.
>> 
>> Why?
> 
> for the same reason that `gem lock` exists, only it works and people use it.

Not why does Isolate exist, I mean why merge this into RubyGems?

Isolate has the same bugs already described earlier in this thread. I know it's "simple" by comparison to other offerings that have a feature or two in common, I get that, but that is not a reason for RubyGems to merge it in, especially if it doesn't actually solve bugs already described.


From nick at quaran.to  Wed Sep 29 23:29:48 2010
From: nick at quaran.to (Nick Quaranto)
Date: Wed, 29 Sep 2010 23:29:48 -0400
Subject: [Rubygems-developers] gem lock
In-Reply-To: <41A44E91-EA17-427E-87FA-72DBB24BE98B@gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
	<3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
	<6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>
	<41A44E91-EA17-427E-87FA-72DBB24BE98B@gmail.com>
Message-ID: <AANLkTi=Eb0zoO5-h2AbXfyCec75oeYukmutQqijRy86n@mail.gmail.com>

This conversation is about to take a horrible turn and I'd rather it not go
that way. Let's just deprecate the command and recommend using Bundler.
There's more important issues to solve with the rubygems client, such as
mirroring, the progress bar, and performance enhancements if at all
possible. Oh yeah, and what happened to gem metadata?

I'd love to see a roadmap and feature list laid down for 1.4 as soon as
possible. Target it for RubyConf week.

-Nick

On Wed, Sep 29, 2010 at 11:26 PM, James Tucker <jftucker at gmail.com> wrote:

>
> On 30 Sep 2010, at 00:12, Ryan Davis wrote:
>
> >
> > On Sep 29, 2010, at 19:57 , James Tucker wrote:
> >
> >>
> >> On 29 Sep 2010, at 22:00, Ryan Davis wrote:
> >>> I've been talking to Eric about the possibility of merging Isolate into
> rubygems and he's agreed that it is a good idea.
> >>
> >> Why?
> >
> > for the same reason that `gem lock` exists, only it works and people use
> it.
>
> Not why does Isolate exist, I mean why merge this into RubyGems?
>
> Isolate has the same bugs already described earlier in this thread. I know
> it's "simple" by comparison to other offerings that have a feature or two in
> common, I get that, but that is not a reason for RubyGems to merge it in,
> especially if it doesn't actually solve bugs already described.
>
> _______________________________________________
> 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  Thu Sep 30 01:02:07 2010
From: jbarnette at gmail.com (John Barnette)
Date: Wed, 29 Sep 2010 22:02:07 -0700
Subject: [Rubygems-developers] gem lock
In-Reply-To: <AANLkTi=Eb0zoO5-h2AbXfyCec75oeYukmutQqijRy86n@mail.gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
	<3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
	<6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>
	<41A44E91-EA17-427E-87FA-72DBB24BE98B@gmail.com>
	<AANLkTi=Eb0zoO5-h2AbXfyCec75oeYukmutQqijRy86n@mail.gmail.com>
Message-ID: <77C6AC1C-9B03-49D8-88A0-10DB62E4F5A8@gmail.com>

On Sep 29, 2010, at 8:29 PM, Nick Quaranto wrote:
> This conversation is about to take a horrible turn and I'd rather it not go
> that way. Let's just deprecate the command and recommend using Bundler.
> There's more important issues to solve with the rubygems client, such as
> mirroring, the progress bar, and performance enhancements if at all
> possible. Oh yeah, and what happened to gem metadata?

I'd like to see `gem lock` deprecated and then removed. It's simply not good code. I'd prefer not to add any sandbox management (Isolate or anything else) features to RubyGems without solving the full-graph dependency resolution problem in a non-hacky way, which will require quite a bit of work on the way gem sources work, as well as potential changes/additions to source servers. This feels like a 2.0 kinda thing.


~ j.


> 
> I'd love to see a roadmap and feature list laid down for 1.4 as soon as
> possible. Target it for RubyConf week.
> 
> -Nick
> 
> On Wed, Sep 29, 2010 at 11:26 PM, James Tucker <jftucker at gmail.com> wrote:
> 
>> 
>> On 30 Sep 2010, at 00:12, Ryan Davis wrote:
>> 
>>> 
>>> On Sep 29, 2010, at 19:57 , James Tucker wrote:
>>> 
>>>> 
>>>> On 29 Sep 2010, at 22:00, Ryan Davis wrote:
>>>>> I've been talking to Eric about the possibility of merging Isolate into
>> rubygems and he's agreed that it is a good idea.
>>>> 
>>>> Why?
>>> 
>>> for the same reason that `gem lock` exists, only it works and people use
>> it.
>> 
>> Not why does Isolate exist, I mean why merge this into RubyGems?
>> 
>> Isolate has the same bugs already described earlier in this thread. I know
>> it's "simple" by comparison to other offerings that have a feature or two in
>> common, I get that, but that is not a reason for RubyGems to merge it in,
>> especially if it doesn't actually solve bugs already described.
>> 
>> _______________________________________________
>> Rubygems-developers mailing list
>> http://rubyforge.org/projects/rubygems
>> Rubygems-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rubygems-developers
>> 
> _______________________________________________
> 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  Thu Sep 30 07:48:37 2010
From: jftucker at gmail.com (James Tucker)
Date: Thu, 30 Sep 2010 08:48:37 -0300
Subject: [Rubygems-developers] gem lock
In-Reply-To: <77C6AC1C-9B03-49D8-88A0-10DB62E4F5A8@gmail.com>
References: <353184e8-8020-467f-a822-4673a124ab80@a36g2000yqc.googlegroups.com>
	<AANLkTina4VAKKBDAjjrLebNX-cq8_SV_wzSMQtDF6VTQ@mail.gmail.com>
	<492a6174-8cdf-4442-a3cc-76524bab53bd@30g2000yqm.googlegroups.com>
	<AANLkTi=pd1k=PTDZQHtjLmUe7=9+Wgmi4CYKqn7hNfyu@mail.gmail.com>
	<FCD1A632-56F8-4512-AA49-4922016B3FA9@gmail.com>
	<AANLkTinLkUEdzbJdY5vygyQkGpwvud9xzRnc8kcxb=oe@mail.gmail.com>
	<E8146B52-A090-4890-AD5A-452864029123@zenspider.com>
	<3E88DB43-672E-4144-86B5-4388781EFA8B@gmail.com>
	<6283CB64-50A7-45D4-91D2-E3097B4BDA1B@zenspider.com>
	<41A44E91-EA17-427E-87FA-72DBB24BE98B@gmail.com>
	<AANLkTi=Eb0zoO5-h2AbXfyCec75oeYukmutQqijRy86n@mail.gmail.com>
	<77C6AC1C-9B03-49D8-88A0-10DB62E4F5A8@gmail.com>
Message-ID: <1C01715B-7981-43BA-AB21-E54A6290C1A6@gmail.com>


On 30 Sep 2010, at 02:02, John Barnette wrote:

> On Sep 29, 2010, at 8:29 PM, Nick Quaranto wrote:
>> This conversation is about to take a horrible turn and I'd rather it not go
>> that way. Let's just deprecate the command and recommend using Bundler.
>> There's more important issues to solve with the rubygems client, such as
>> mirroring, the progress bar, and performance enhancements if at all
>> possible. Oh yeah, and what happened to gem metadata?
> 
> I'd like to see `gem lock` deprecated and then removed. It's simply not good code. I'd prefer not to add any sandbox management (Isolate or anything else) features to RubyGems without solving the full-graph dependency resolution problem in a non-hacky way, which will require quite a bit of work on the way gem sources work, as well as potential changes/additions to source servers. This feels like a 2.0 kinda thing.

Thank you, both of you, these are my sentiments also.

Nick, I started up the Wiki again to start documenting some of the things I have planned to sort out platform integration issues and performance issues that are keeping gem_prelude alive (including plugin architecture). I'm hoping to be at Rubyconf this year as well, so it'd be nice if as you suggest we could maybe nail a large portion of these issues around that time. I'm really hoping I can get back to some of these issues soon, but I really don't have many chunks of focus time available right now. There are also important integration issues with the ruby-core stdlib gems discussion which tie into both the plugins and the platform integration discussions in important ways, and some of these things can be seen in my ruby-core posts on the topic. The concerns of system level packagers (and no, I am not just talking about Debian) are genuinely important, and if we don't address them there will be yet more hacks coming as a consequence. Furthermore, as someone seems to have once again picked up on Gem.datadir (which involves using the Gem library API), if this is re-popularised, some of the current hacks around these issues (such as gem2rpm) will become less appropriate in future. There's more research to be done in this area, and I'm happy for anyone who wants to, to come in and help. What I don't want to see though, is for someone to come in and create a load of patches that are unique to their platform, break backward compatibility, oversimplify the myriad of issues, or based on insufficient understanding of the problem domain (as per existing tickets that also contain important factors / information on this topic).