From noreply at rubyforge.org Tue Sep 1 15:41:24 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Sep 2009 15:41:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27035 ] JRuby hooks need one-line change for --1.9 mode Message-ID: <20090901194124.9B2061858207@rubyforge.org> Bugs item #27035, was opened at 2009-09-01 14:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Thomas Enebo (enebo) Assigned to: Nobody (None) Summary: JRuby hooks need one-line change for --1.9 mode Initial Comment: gemdir is an object now in 1.9, but if we to_s the object then this works for us in both 1.8 and 1.9 modes on JRuby. Sorry that I am showing a diff from our installed version of rubygems, but it is only a 5 character patch :| -Tom diff --git a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb index 7f32229..b676586 100644 --- a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb +++ b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb @@ -9,7 +9,7 @@ module Gem class << self alias_method :original_ensure_gem_subdirectories, :ensure_gem_subdirectories def ensure_gem_subdirectories(gemdir) - original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir + original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir.to_s end alias_method :original_set_paths, :set_paths ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 From noreply at rubyforge.org Tue Sep 1 17:08:29 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 1 Sep 2009 17:08:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27035 ] JRuby hooks need one-line change for --1.9 mode Message-ID: <20090901210829.9E5EC1978285@rubyforge.org> Bugs item #27035, was opened at 2009-09-01 14:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Thomas Enebo (enebo) Assigned to: Nobody (None) Summary: JRuby hooks need one-line change for --1.9 mode Initial Comment: gemdir is an object now in 1.9, but if we to_s the object then this works for us in both 1.8 and 1.9 modes on JRuby. Sorry that I am showing a diff from our installed version of rubygems, but it is only a 5 character patch :| -Tom diff --git a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb index 7f32229..b676586 100644 --- a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb +++ b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb @@ -9,7 +9,7 @@ module Gem class << self alias_method :original_ensure_gem_subdirectories, :ensure_gem_subdirectories def ensure_gem_subdirectories(gemdir) - original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir + original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir.to_s end alias_method :original_set_paths, :set_paths ---------------------------------------------------------------------- >Comment By: Thomas Enebo (enebo) Date: 2009-09-01 16:08 Message: Sorry, this is not your bug at all. I was under the impression we rolled defaults/jruby.rb into rubygems source. I would just close this bug, but I don't want to screw up anyones process... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 From noreply at rubyforge.org Wed Sep 2 01:15:37 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Sep 2009 01:15:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25998 ] Had > instead of ~> in docs for specifying a pessimist Message-ID: <20090902051537.BD10A18581FC@rubyforge.org> Bugs item #25998, was opened at 2009-05-22 01:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25998&group_id=126 Category: documentation Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: David Miani (nanothief) Assigned to: Nobody (None) Summary: Had > instead of ~> in docs for specifying a pessimist Initial Comment: While reading chapter 5 of the user guide (http://rubygems.org/read/chapter/16), in the section about PessimisticVersionContraints, I came across this: ----- ...Doing this is cumbersome, so RubyGems provides a pessimistic operator ~~> (read: approximately greater than). Using the pessimistic operator, we get: gem 'library', '> 2.2' ----- The pessimistic operators is first said to be '~~>', but the example uses '>'. From trying these examples in irb, I think both are wrong, and the correct operator is '~>'. So I think the section should read: ----- ...Doing this is cumbersome, so RubyGems provides a pessimistic operator ~> (read: approximately greater than). Using the pessimistic operator, we get: gem 'library', '~> 2.2' ----- Also there is a minor formatting problem, the text "(read: approximately greater than). Using the pessimistic operator, we get:" uses the coding style instead of the normal style. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 15:18 Message: Documentation corrected. Formatting issue is a problem in the textile rendering. ~something~ would make something subscript. Textile does include escaping (\) but it doesn't seem to be implemented in this implementation, and then even it is for a whole text block, so it would not be possible to use on a code section. recommend close ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25998&group_id=126 From noreply at rubyforge.org Wed Sep 2 01:20:15 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Sep 2009 01:20:15 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090902052016.4012D18581FC@rubyforge.org> Bugs item #26936, was opened at 2009-08-17 19:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26936&group_id=126 Category: `gem install` command Group: v1.3.x >Status: Closed Resolution: None Priority: 3 Submitted By: Dr Nic Williams (nicwilliams) Assigned to: Nobody (None) Summary: undefined method `prerelease?' for nil:NilClass Initial Comment: In both ruby18 and ruby19, rubygems 1.3.5 gives off "undefined method `prerelease?' for nil:NilClass" errors a lot. I can't isolate exactly what is causing it. How do I rollback to an old rubygems version? ---------------------------------------------------------------------- Comment By: Dr Nic Williams (nicwilliams) Date: 2009-08-17 23:28 Message: Ah, it turns out it was another gem source that caused the issues. I removed it and "gem install rails" + merb works. Thanks. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-08-17 23:15 Message: Sounds more like a corrupt index than a bug in the gem dependencies. Did you have by change github as a source repository? There are a couple of bugs over there that are making gem installation a real pain. Please try: sudo gem install rails --debug -V ---------------------------------------------------------------------- Comment By: Dr Nic Williams (nicwilliams) Date: 2009-08-17 23:13 Message: I think the bug is related to gems with dependencies: ~$ sudo gem install rails Password: ERROR: While executing gem ... (NoMethodError) undefined method `prerelease?' for nil:NilClass ~$ sudo gem install activerecord ERROR: While executing gem ... (NoMethodError) undefined method `prerelease?' for nil:NilClass ~$ sudo gem install activesupport Successfully installed activesupport-2.3.3 1 gem installed ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-08-17 23:08 Message: You can rollback by running setup.rb from an old version - it has worked for me. ---------------------------------------------------------------------- Comment By: Dr Nic Williams (nicwilliams) Date: 2009-08-17 20:35 Message: An example of the bug vs no bug: gem install merb - causes the bug gem install merb-core - no bug ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26936&group_id=126 From noreply at rubyforge.org Wed Sep 2 01:20:55 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 2 Sep 2009 01:20:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27035 ] JRuby hooks need one-line change for --1.9 mode Message-ID: <20090902052055.9D71818581FC@rubyforge.org> Bugs item #27035, was opened at 2009-09-01 12:41 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 Category: None Group: None >Status: Closed Resolution: None Priority: 3 Submitted By: Thomas Enebo (enebo) Assigned to: Nobody (None) Summary: JRuby hooks need one-line change for --1.9 mode Initial Comment: gemdir is an object now in 1.9, but if we to_s the object then this works for us in both 1.8 and 1.9 modes on JRuby. Sorry that I am showing a diff from our installed version of rubygems, but it is only a 5 character patch :| -Tom diff --git a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb index 7f32229..b676586 100644 --- a/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb +++ b/lib/ruby/site_ruby/1.8/rubygems/defaults/jruby.rb @@ -9,7 +9,7 @@ module Gem class << self alias_method :original_ensure_gem_subdirectories, :ensure_gem_subdirectories def ensure_gem_subdirectories(gemdir) - original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir + original_ensure_gem_subdirectories(gemdir) if writable_path? gemdir.to_s end alias_method :original_set_paths, :set_paths ---------------------------------------------------------------------- Comment By: Thomas Enebo (enebo) Date: 2009-09-01 14:08 Message: Sorry, this is not your bug at all. I was under the impression we rolled defaults/jruby.rb into rubygems source. I would just close this bug, but I don't want to screw up anyones process... ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27035&group_id=126 From rick.denatale at gmail.com Wed Sep 2 18:41:54 2009 From: rick.denatale at gmail.com (Rick DeNatale) Date: Wed, 2 Sep 2009 18:41:54 -0400 Subject: [Rubygems-developers] Using both the new rvm Ruby Version Manager, AND multiruby from ZenTest Message-ID: The new Ruby Version Manager http://rvm.beginrescueend.com/ seems great for having multiple ruby installations to USE, while the multiruby feature in the ZenTest gem is great for running tests/specs under a bunch of different ruby versions. So I see them as both useful for different purposes, and I'm trying to use both. I ran into a few issues trying to use them together and just wrote an article about them, and my current workaround. http://talklikeaduck.denhaven2.com/2009/09/02/ruby-version-management-multiruby-and-rvm -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale From noreply at rubyforge.org Thu Sep 3 08:42:53 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Sep 2009 08:42:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27045 ] The What happens is that the 'display:none' style is applied to the rest of the page, since there there is no . ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27045&group_id=126 From noreply at rubyforge.org Thu Sep 3 18:20:33 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 3 Sep 2009 18:20:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-27046 ] Update all commands to have consistent way to specify GEMNAME Message-ID: <20090903222033.C9FEA1858125@rubyforge.org> Feature Requests item #27046, was opened at 2009-09-03 15:20 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27046&group_id=126 Category: `gem` commands Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Louie Sherwin (sherwin) Assigned to: Nobody (None) Summary: Update all commands to have consistent way to specify GEMNAME Initial Comment: It would really be helpful if all of the commands had identical methods to input GEMNAME For example three commonly used commands have three different ways to search. gem query needs -n REGEX gem list STRING gem dependency GEMNAME REGEX works as expected but it would be nice to have a shorthand to match just "rails" or just mongrel' STRING as a bare word matches the sub-string but also responds to REGEX if in quotes ie. '^mongrel$' GEMNAME seems to always match any sub-string in the target name. I cannot find a a way to just search for "mongrel" with out getting all gems with "mongrel" somewhere in the name. tks, louie ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27046&group_id=126 From noreply at rubyforge.org Fri Sep 4 03:10:42 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 Sep 2009 03:10:42 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27048 ] Cannot use rubygems-update 1.3.5 to update from rubygems 1.2.x installation Message-ID: <20090904071043.17CF51858260@rubyforge.org> Bugs item #27048, was opened at 2009-09-04 16:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27048&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alain Hoang (hoanga) Assigned to: Nobody (None) Summary: Cannot use rubygems-update 1.3.5 to update from rubygems 1.2.x installation Initial Comment: Hi, I ran into a case where if had an older installation of Rubygems 1.2.0 then tried to install rubygems-update 1.3.5 and tried to use the update_rubygems command you would get an error like the following: `report-activate-error': Could not find RubyGem session (>= 0) (Gem::LoadError) This makes it impossible to update rubygems from version 1.3.5 of rubygems-update. But it IS possible with version 1.3.4 of rubygems-update. I consider this behavior extremely unfriendly for people who are on rubygems 1.2.x and want to use a provided mechanism for upgrading I believe in the email thread below. Someone else also gets a similar stack trace and their solution was to upgrade from source: http://www.pubbs.net/ruby/200907/68654/ It would be much more preferred to be able to update rubygems via version 1.3.5 (and beyond) of rubygems-update. But what is considered the canonical way to upgrade? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27048&group_id=126 From noreply at rubyforge.org Fri Sep 4 14:56:13 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 4 Sep 2009 14:56:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Feature Requests-27053 ] gem which gem_name should work Message-ID: <20090904185613.773711978277@rubyforge.org> Feature Requests item #27053, was opened at 2009-09-04 18:56 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27053&group_id=126 Category: other Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: gem which gem_name should work Initial Comment: Currently if you do a gem which gem_name and that gem does not have a file called "gem_name.rb" it outputs nothing. Proposal is for "gem which" to also display gem paths. Thanks. -r ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=578&aid=27053&group_id=126 From noreply at rubyforge.org Thu Sep 10 16:34:05 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Sep 2009 16:34:05 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090910203405.D8ADA1D78805@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 15:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Nobody (None) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Thu Sep 10 16:53:08 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Sep 2009 16:53:08 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090910205308.4CD321D78809@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 >Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) >Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Thu Sep 10 16:54:52 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Sep 2009 16:54:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090910205452.693B61D78805@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Thu Sep 10 21:47:41 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 10 Sep 2009 21:47:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090911014741.DADE01D78805@rubyforge.org> Bugs item #27087, was opened at 2009-09-11 06:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 11:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Fri Sep 11 02:08:41 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Sep 2009 02:08:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090911060841.2BC741858254@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-10 23:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-10 18:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Fri Sep 11 02:33:46 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Sep 2009 02:33:46 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090911063346.C394816782AC@rubyforge.org> Bugs item #27087, was opened at 2009-09-11 06:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 16:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 16:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-11 11:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-11 06:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Fri Sep 11 03:30:38 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 11 Sep 2009 03:30:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27087 ] Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Message-ID: <20090911073038.393EF16782A9@rubyforge.org> Bugs item #27087, was opened at 2009-09-10 13:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Rob Sanheim (rsanheim) Assigned to: Eric Hodel (drbrain) Summary: Rubygems 1.3.5 and Ruby 1.9 breaks hard after require 'rubygems/specification' Initial Comment: Please see the repo: http://github.com/rsanheim/ruby19_rubygems_bug/tree/master The build is here: http://runcoderun.com/rsanheim/ruby19_rubygems_bug The failing build on Ruby 1.9.1 p243: http://runcoderun.com/rsanheim/ruby19_rubygems_bug http://runcoderun.com/rsanheim/ruby19_rubygems_bug/builds/09a9f683fe7848980e10ac7bd2291040ec11ea17/1/ruby_191 Here is the simplest code to illustrate: require 'hoe' gem 'hoe' # these should work puts "about to break 'gem'" require 'rubygems/specification' gem 'hoe' # exception thrown here when it shouldn't be ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-11 00:30 Message: We've already tracked down the problem. The workaround as described is to remove your manually installed rubygems from 1.9.x. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-10 23:33 Message: Ryan: Sorry about that. I (too) am working on several projects, busy and wanted to throw in my helpful comments... I find problems can get fixed quicker if the devs know how many people are affected. I misunderstood your initial comment: '0 failures out of 4' sounds like no failures, which could certainly be assumed to be a good thing - except we are trying to track down a problem. +1 biting off a much ruder comment and looking to the future with hope and optimism. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 23:08 Message: Please don't +1. That shit is obnoxious. We don't need to test this against jeweler if we have a much cleaner smaller repro that is standalone. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-10 18:47 Message: +1 please fix... Not exactly 'urgent' but annoying. I raised a bug on the 'jeweler' gem because of this: http://github.com/technicalpickles/jeweler/issues#issue/34 I'm sure that the code i provide there: Rakefile: require 'jeweler' rake -T will trigger issue. ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:54 Message: Huh! % sudo gem uninstall rubygems-update % multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ... TOTAL RESULT = 0 failures out of 4 Passed: 1.9.1-p129, 1.8.7-p72, 1.8.7-p160, 1.8.6-p368 ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-10 13:53 Message: Easier repro of the warnings: multiruby -rubygems -rrubygems/specification -e 0 and: multiruby -rubygems -rrubygems/specification -e 'gem "hoe"' ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27087&group_id=126 From noreply at rubyforge.org Sun Sep 13 18:00:13 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 Sep 2009 18:00:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27099 ] Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Message-ID: <20090913220016.D8BC015B8022@rubyforge.org> Bugs item #27099, was opened at 2009-09-14 00:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 Category: #gem and #require methods Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Cezary Baginski (czarek) Assigned to: Nobody (None) Summary: Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Initial Comment: I filed it initially as a bug in Lighthouse (cucumber): https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/445-patch-cucumber-cannot-find-treetop-if-all-gems-are-in-homegem#ticket-445-4 It seems like adding: gem 'foo-bar' fixes things for some gems, others need: Gem.activate('foo-bar') The Lighthouse ticket has a specific, detailed example in cucumber. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 From noreply at rubyforge.org Sun Sep 13 18:56:55 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sun, 13 Sep 2009 18:56:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27099 ] Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Message-ID: <20090913225655.9CD1815B8023@rubyforge.org> Bugs item #27099, was opened at 2009-09-14 00:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 Category: #gem and #require methods Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Cezary Baginski (czarek) Assigned to: Nobody (None) Summary: Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Initial Comment: I filed it initially as a bug in Lighthouse (cucumber): https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/445-patch-cucumber-cannot-find-treetop-if-all-gems-are-in-homegem#ticket-445-4 It seems like adding: gem 'foo-bar' fixes things for some gems, others need: Gem.activate('foo-bar') The Lighthouse ticket has a specific, detailed example in cucumber. ---------------------------------------------------------------------- >Comment By: Cezary Baginski (czarek) Date: 2009-09-14 00:56 Message: Just to make sure, I tried trunk (r2296), but it wouldn't let me even install gems in $HOME, even with --user-install (exception with Requirement being Nil in <=>() ). Maybe I'll submit a bug tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 From noreply at rubyforge.org Tue Sep 15 04:32:30 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Sep 2009 04:32:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25935 ] module installed by gem does not load when installation directory path contains space Message-ID: <20090915083230.EFBB31779933@rubyforge.org> Bugs item #25935, was opened at 2009-05-16 09:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25935&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.3.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: bazz bazz (bazz) Assigned to: Luis Lavena (luislavena) Summary: module installed by gem does not load when installation directory path contains space Initial Comment: * The following is example. I install RoR through gem. "rails" command does not work. --- C:\>rails C:/Program Files/ruby-1.8/bin/rails:19:in `load': no such file to load -- "C:/Pr ogram Files/ruby-1.8/lib/ruby/gems/1.8/gems/rails-2.3.2/bin/rails" (LoadError) from C:/Program Files/ruby-1.8/bin/rails:19 --- * The investigation line #386 in "rubygems.rb" File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') #=> Gem.bin_path returns "\C:/Program Files/ruby-1.8/lib/ruby/gems/1.8/gems/rails-2.3.2/bin/rails\" line #19 in "rails" this file is installed by gem load Gem.bin_path('rails', 'rails', version) #=> Load error * Workaround line #386 in "rubygems.rb" -File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') +File.join(spec.full_gem_path, spec.bindir, exec_name) This way was confirmed only my environment. * The following is my environment. --- RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32] - INSTALLATION DIRECTORY: C:/Program Files/ruby-1.8/lib/ruby/gems/1.8 - RUBY EXECUTABLE: "C:/Program Files/ruby-1.8/bin/ruby.exe" - EXECUTABLE DIRECTORY: C:/Program Files/ruby-1.8/bin - RUBYGEMS PLATFORMS: - ruby - x86-mswin32-60 - GEM PATHS: - C:/Program Files/ruby-1.8/lib/ruby/gems/1.8 - C:/Documents and Settings/Administrator/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org/ --- ---------------------------------------------------------------------- Comment By: Alex Ju (aju) Date: 2009-09-15 04:32 Message: This issue happens to me again. RubyGems Environment: - Ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] - Gem 1.3.5 - WinXP 32bit Still getting this error, I have verified that the Workaround is there on line #386 in "rubygems.rb" -File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') +File.join(spec.full_gem_path, spec.bindir, exec_name) Exception `NameError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:161 - uninitialized constant Gem::Commands::UpdateCommand Updating installed gems Exception `Gem::LoadError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:827 - C ould not find RubyGem sources (> 0.0.1) Exception `Zlib::BufError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578 - b uffer error ERROR: While executing gem ... (Zlib::BufError) buffer error D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578:in `read' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578:in `gunzip' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:165:in `fetch_ path' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:219:in `load_spe cs' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:192:in `list' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:188:in `each' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:188:in `list' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:123:in `find_mat ching' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:169:i n `which_to_update' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:161:i n `each' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:161:i n `which_to_update' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:75:in `execute' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:257:in `invoke' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `proce ss_args' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run' D:/Ruby/bin/gem:21 " ---------------------------------------------------------------------- Comment By: bazz bazz (bazz) Date: 2009-07-06 13:59 Message: Many thanks. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-07-05 13:27 Message: Fix applied in revision 2272. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25935&group_id=126 From noreply at rubyforge.org Tue Sep 15 04:50:04 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Sep 2009 04:50:04 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25935 ] module installed by gem does not load when installation directory path contains space Message-ID: <20090915085005.B665915B8022@rubyforge.org> Bugs item #25935, was opened at 2009-05-16 10:40 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25935&group_id=126 Category: RubyGems installer (setup.rb) Group: v1.3.x Status: Closed Resolution: Accepted Priority: 3 Submitted By: bazz bazz (bazz) Assigned to: Luis Lavena (luislavena) Summary: module installed by gem does not load when installation directory path contains space Initial Comment: * The following is example. I install RoR through gem. "rails" command does not work. --- C:\>rails C:/Program Files/ruby-1.8/bin/rails:19:in `load': no such file to load -- "C:/Pr ogram Files/ruby-1.8/lib/ruby/gems/1.8/gems/rails-2.3.2/bin/rails" (LoadError) from C:/Program Files/ruby-1.8/bin/rails:19 --- * The investigation line #386 in "rubygems.rb" File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') #=> Gem.bin_path returns "\C:/Program Files/ruby-1.8/lib/ruby/gems/1.8/gems/rails-2.3.2/bin/rails\" line #19 in "rails" this file is installed by gem load Gem.bin_path('rails', 'rails', version) #=> Load error * Workaround line #386 in "rubygems.rb" -File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') +File.join(spec.full_gem_path, spec.bindir, exec_name) This way was confirmed only my environment. * The following is my environment. --- RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2008-08-11 patchlevel 72) [i386-mswin32] - INSTALLATION DIRECTORY: C:/Program Files/ruby-1.8/lib/ruby/gems/1.8 - RUBY EXECUTABLE: "C:/Program Files/ruby-1.8/bin/ruby.exe" - EXECUTABLE DIRECTORY: C:/Program Files/ruby-1.8/bin - RUBYGEMS PLATFORMS: - ruby - x86-mswin32-60 - GEM PATHS: - C:/Program Files/ruby-1.8/lib/ruby/gems/1.8 - C:/Documents and Settings/Administrator/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org/ --- ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2009-09-15 05:50 Message: Alex, What you copied isn't the same issue, please report it properly, including the output of your gem env and the gem install --debug -V command ---------------------------------------------------------------------- Comment By: Alex Ju (aju) Date: 2009-09-15 05:32 Message: This issue happens to me again. RubyGems Environment: - Ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32] - Gem 1.3.5 - WinXP 32bit Still getting this error, I have verified that the Workaround is there on line #386 in "rubygems.rb" -File.join(spec.full_gem_path, spec.bindir, exec_name).sub(/.*\s.*/m, '"\&"') +File.join(spec.full_gem_path, spec.bindir, exec_name) Exception `NameError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:161 - uninitialized constant Gem::Commands::UpdateCommand Updating installed gems Exception `Gem::LoadError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:827 - C ould not find RubyGem sources (> 0.0.1) Exception `Zlib::BufError' at D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578 - b uffer error ERROR: While executing gem ... (Zlib::BufError) buffer error D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578:in `read' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems.rb:578:in `gunzip' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:165:in `fetch_ path' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:219:in `load_spe cs' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:192:in `list' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:188:in `each' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:188:in `list' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:123:in `find_mat ching' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:169:i n `which_to_update' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:161:i n `each' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:161:i n `which_to_update' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:75:in `execute' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:257:in `invoke' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:132:in `proce ss_args' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:102:in `run' D:/Ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:58:in `run' D:/Ruby/bin/gem:21 " ---------------------------------------------------------------------- Comment By: bazz bazz (bazz) Date: 2009-07-06 14:59 Message: Many thanks. ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-07-05 14:27 Message: Fix applied in revision 2272. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25935&group_id=126 From jbarnette at gmail.com Tue Sep 15 15:53:03 2009 From: jbarnette at gmail.com (John Barnette) Date: Tue, 15 Sep 2009 12:53:03 -0700 Subject: [Rubygems-developers] [Cucumber:1385] Re: Problems installing cucumber from gemcutter and github repositories In-Reply-To: <8d961d900909151221q27482949k7ff3885facc5d1c7@mail.gmail.com> References: <5f0ebf17-1920-4932-8709-1467299803ac@o35g2000vbi.googlegroups.com> <8d961d900909151203k225716f1kef1040c021e2eae4@mail.gmail.com> <8d961d900909151221q27482949k7ff3885facc5d1c7@mail.gmail.com> Message-ID: <1BFC3E25-9DEA-4B63-9985-6693FF74E4C7@gmail.com> On Sep 15, 2009, at 12:21 PM, aslak hellesoy wrote: > From rubygems' perspective though, I wish it didn't query *all* of > the .gemspec.rz's though :/ > > > Thanks for dealing with this so quickly Nick! > > I'll still add the workaround, since rubygems will bail if *one* > server (even if it is the last one in the --source list) doesn't > have a gem. > Is this a known issue, rubygems folks? Should I file a bug? A very brief look through the tracker led to this: http://rubyforge.org/tracker/index.php?func=detail&aid=25816&group_id=126&atid=575 Same issue? If so, please drop any extra info you have on that ticket. Thanks! ~ j. > > Aslak > > -Nick > > > On Tue, Sep 15, 2009 at 3:03 PM, aslak hellesoy > wrote: > > > On Tue, Sep 15, 2009 at 8:22 PM, darrinholst > wrote: > > I was having that problem earlier today, are you still getting that > error? I'm not anymore, but I'm on a different internet connection > now. I suppose if rubyforge was have some problems you would see that, > but 0.3.100 is out on gemcutter too, so both of them would have to be > down (assuming you're using 0.3.100). > > > This seems to be a combination of unreliable gem servers and a bug > in rubygems (at least with rubygems 1.3.3, which is bundled with > jruby 1.3.1): > > jruby -S gem install --source http://gems.rubyforge.org celerity - > v0.0.7 -V > GET 304 Not Modified: http://gems.rubyforge.org/specs.4.8.gz > Installing gem celerity-0.0.7 > /usr/local/jruby-1.3.1/lib/ruby/gems/1.8/gems/celerity-0.0.7/ > History.txt > /usr/local/jruby-1.3.1/lib/ruby/gems/1.8/gems/celerity-0.0.7/ > License.txt > (snip) > Successfully installed celerity-0.0.7 > 1 gem installed > Installing ri documentation for celerity-0.0.7... > Installing RDoc documentation for celerity-0.0.7... > Could not find main page README.rdoc > Could not find main page README.rdoc > Could not find main page README.rdoc > Could not find main page README.rdoc > > OK! > > jruby -S gem install --source http://gems.rubyforge.org --source http://gemcutter.org > celerity -v0.0.7 -V > GET 304 Not Modified: http://gems.rubyforge.org/specs.4.8.gz > GET 200 OK: http://gemcutter.org/specs.4.8.gz > connection reset after 2 requests, retrying > GET 500 Internal Server Error: http://gemcutter.org/quick/Marshal.4.8/celerity-0.0.7.gemspec.rz > Error fetching remote data: bad response Internal Server > Error 500 (http://gemcutter.org/quick/Marshal.4.8/celerity-0.0.7.gemspec.rz > ) > Falling back to local-only install > ERROR: could not find gem celerity locally or in a repository > > FAIL! > > IMO, this is a bug in rubygems because it bails on the first 500 > from one of the servers, not even trying the other one. It doesn't > help that it attempts the last server first. There is also something > wrong with gemcutter - it reports that the celerity gem is there: http://gemcutter.org/gems/celerity > . Still, download fails. While I'm at it - it might be wise to add > some 304 to gemcutter for improved performance... > > I will resurrect the cuke4duke maven plugin syntax that lets > you specify *where* to get the gem from as a workaround for this > until rubygems and gemcutter are fixed... > > Apologies to ittyad, whose ticket (http://github.com/aslakhellesoy/cuke4duke/issues/closed#issue/ > 22) I dismissed as user error. > > Aslak > > Darrin > > On Sep 15, 5:57 am, torbjornvatn wrote: > > My cuke4duke project won't build any more when run with the - > > Dcucumber.installGems=true option. > > > > I found that the reason is an "ERROR: could not find gem cucumber > > locally or in a repository" error that occurs during the gem > install. > > > > If I run gem install on the command line it works if I remove the -- > > source arguments all together or when I use the --sourcehttp://gems.rubyforge.org > . > > Both gemcutter and github source repos fail when use alone, but > > strangely the github one works in combination with rubyforge. > > > > Anyone got any ideas about what's causing this? > > > > /torbj?rn > > > > From noreply at rubyforge.org Tue Sep 15 16:18:32 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Sep 2009 16:18:32 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090915201832.EC1D51978277@rubyforge.org> Bugs item #25816, was opened at 2009-05-06 22:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25816&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Larry Kyrala (coldnebo) Assigned to: Nobody (None) Summary: misleading error message when one of many sources unreachable. Initial Comment: I puzzled over the following for about half an hour: $ sudo gem install hoe ERROR: While executing gem ... (Zlib::GzipFile::Error) not in gzip format Until I finally figured out that one of my sources (aka 'gem sources') was a address only accessible on my company's VPN. (I wasn't on the VPN at the time.) e.g: $ gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org/ http://rubygems.xxx.xxx/ <-- vpn address This error was confusing, because I was attempting to get 'hoe' which is clearly at gems.rubyforge.org, however apparently gem attempts to ping ALL the sources, even if one isn't available, it croaks with this obscure error. At least this should be documented. At most, gem should return a meaningful error if one of the gem sources is unreachable. Ideally, if the install name is found in one of the gem sources that IS available, it shouldn't matter, and should simply install the gem from the available source. Other info: using Mac OSX 10.5 Macports: $ port installed | grep ruby rb-rubygems @1.3.1_0 (active) ruby @1.8.7-p72_2+thread_hooks ruby @1.8.7-p160_1+thread_hooks (active) ruby186 @1.8.6-p287_0+darwin_9+thread_hooks Hope this helps! -lk ---------------------------------------------------------------------- Comment By: Aslak Helles?y (aslak_hellesoy) Date: 2009-09-15 16:18 Message: The same issue is described here: http://groups.google.com/group/cukes/browse_thread/thread/fc9809247b3369f5 If multiple --source arguments are passed, rubygems will start to download from tha last one first. (Not sure if that's deterministic or semi-random). On the first failure, rubygems will bail, not even trying the remaining sources. ---------------------------------------------------------------------- Comment By: Larry Kyrala (coldnebo) Date: 2009-08-27 16:51 Message: Ah, I see your point. I was focusing on the invalid host first and foremost -- I'm not sure why in linux it reports a problem with the domain, while under Mac it reports a fictitious GZip error.. perhaps they are different code paths on the different platforms? The original reported problem on the Mac seemed to be due to vpn disconnect, because removing the gem source corresponding to the vpn also worked in that case. I think the expected behavior (IMHO) should be: sources.each do |source| begin source.connect next unless source.connected? gem = source.search gem_name next if gem.nil? source.install gem break ensure source.disconnect end end In this way, rubygems iterates over all the sources configured until it has searched all the active sources or finds the gem, whichever comes first. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-27 15:06 Message: I thought you meant this: > $ sudo gem install hoe > ERROR: While executing gem ... (Zlib::GzipFile::Error) > not in gzip format was a misleading error message. -------- If we consider: ERROR: could not find gem locally or in a repository to be misleading, when there is only a dead host in the sources list, then we can look at that. So... Gem::SpecFetcher#legacy_repos tries a couple rescues and then raises when _any_ source is not available, regardless if there are more to try, or there are already known good ones. It is requested that rubygems continue if there is at least one good source in the list. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-27 14:53 Message: I thought you meant this: > $ sudo gem install hoe > ERROR: While executing gem ... (Zlib::GzipFile::Error) > not in gzip format was a misleading error message. -------- If we consider: ERROR: could not find gem locally or in a repository to be misleading, when there is only a dead host in the sources list, then we can look at that. So... Gem::SpecFetcher#legacy_repos tries a couple rescues and then raises when _any_ source is not available, regardless if there are more to try, or there are already known good ones. It is requested that rubygems continue if there is at least one good source in the list. ---------------------------------------------------------------------- Comment By: Larry Kyrala (coldnebo) Date: 2009-08-27 07:49 Message: I'm still getting that error. I think maybe you only tested with one source or two bogus sources. The problem manifests with one valid and one bogus. let me show you an example under linux: lkyrala at lkyrala-ibex-64:~$ gem -v 1.3.4 lkyrala at lkyrala-ibex-64:~$ ruby -v ruby 1.8.6 (2009-06-08 patchlevel 369) [x86_64-linux] # first, I edit sources... lkyrala at lkyrala-ibex-64:~$ gem sources *** CURRENT SOURCES *** # notice the FIRST entry is valid and correct: http://gems.rubyforge.org/ # it's the second entry that is bogus or unreachable: http://rubygems.nodomain.com/ lkyrala at lkyrala-ibex-64:~$ gem install smoke ERROR: http://rubygems.nodomain.com/ does not appear to be a repository ERROR: could not find gem smoke locally or in a repository # notice how gem INCORRECTLY failed to find smoke on rubyforge even though it was the FIRST source entry and valid. Instead, it INCORRECTLY goes to the second source and reports an error even though rubyforge works fine. # so, changing the SECOND source to a valid source... lkyrala at lkyrala-ibex-64:~$ gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org/ # note: I only changed the SECOND source: http://rubygems.mathworks.com/ lkyrala at lkyrala-ibex-64:~$ gem install smoke Successfully installed smoke-0.0.6 1 gem installed # notice that the gem installs from the FIRST source ok now even though it was the second source that had the problem. # note: the second source does not have "smoke" in it's repo. ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 17:36 Message: Proper error message is displayed on two linux boxes: RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - RUBY VERSION: 1.8.5 (2006-08-25) [i386-linux] RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] ERROR: http://gems.nosuchdomain.com does not appear to be a repository ERROR: could not find gem utility_belt locally or in a repository Larry suggests: simply install the gem from the available source If this is accepted, this should be a feature. As a bug, i can not reproduce. ---------------------------------------------------------------------- Comment By: Larry Kyrala (coldnebo) Date: 2009-05-06 22:43 Message: BTW, I forgot to mention the workaround: Simply remove the source that is unreachable and gem works fine. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25816&group_id=126 From noreply at rubyforge.org Tue Sep 15 21:44:21 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 15 Sep 2009 21:44:21 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916014422.2070F18581EB@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 04:23:38 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 04:23:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916082339.1626C18581EF@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 04:24:37 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 04:24:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916082437.45F121858253@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Open >Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 04:25:22 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 04:25:22 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916082522.7EDA31858253@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 05:07:37 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 05:07:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916090737.AABB2185824F@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Adam Salter (aqsalter) Date: 2009-09-16 19:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 18:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 05:17:49 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 05:17:49 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916091749.BB1991858255@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 05:20:23 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 05:20:23 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916092024.126191858255@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 05:38:09 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 05:38:09 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916093810.4A3E71858255@rubyforge.org> Bugs item #27109, was opened at 2009-09-15 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-16 02:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 02:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 02:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 02:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 01:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 06:47:59 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 06:47:59 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090916104759.E65901858258@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-16 10:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 09:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 23:36:01 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 23:36:01 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917033601.37B57167829F@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 20:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 19:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 19:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 18:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Wed Sep 16 23:50:11 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 16 Sep 2009 23:50:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917035016.07FB4167829F@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 20:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 19:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 19:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 18:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 00:40:32 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 00:40:32 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917044032.87302185824C@rubyforge.org> Bugs item #27109, was opened at 2009-09-15 18:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: John Barnette (jbarnette) Date: 2009-09-16 21:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 20:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 20:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 03:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 02:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 02:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 02:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 02:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 01:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 01:39:12 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 01:39:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917053912.D7A5E16782A9@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Adam Salter (aqsalter) Date: 2009-09-17 15:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 14:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 20:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 19:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 19:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 18:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 04:03:43 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 04:03:43 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917080343.3F1BE167829F@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-17 08:03 Message: Adam - what you don't seem to understand is that sources are completely separate from gems. My gems are available from gemcutter, rubyforge and github, for example. You could do: gem install subload --source http://gems.rubyforge.org/ gem install subload --source http://gems.gemcutter.org gem install raggi-subload --source http://gems.github.com Any of which will work. Rubygems can store these, and my .gemrc looks like this: :sources: - http://gems.rubyforge.org/ - http://gemcutter.org - http://gems.github.com So when I type gem install it will try rubyforge first, then gemcutter.org, then gems.github.com. Dependencies could be on any or *all* of the three sources, I see no reason to to put restriction on this flexibility. All that would lead to is a "weakest link" problem, and over time as gem servers are deprecated or come into disservice those gems that have dependencies forcefully relying on them will be broken due to this feature you request. The resolution at this point would be to fetch the gem, unpack it, strip any signatures, open the gemspec, remove the dependency source, then repack the gem. Why would we ever want to do this? As for gemcutter, it's not finished, and still has issues, for example rspec is currently publishing prerelease gems to it, but they are not marked as prerelease by gemcutter, because the product is unfinished. Fact of life, new things take time to be completed. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 05:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 04:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 10:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 09:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 04:07:53 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 04:07:53 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090917080753.404BF16782AB@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-17 08:07 Message: Just for accuracies sake, I notice a commit went in for support of prerelease gems into gemcutter last night. I'm not sure if it's complete or deployed though, and this isn't the only thing. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-17 08:03 Message: Adam - what you don't seem to understand is that sources are completely separate from gems. My gems are available from gemcutter, rubyforge and github, for example. You could do: gem install subload --source http://gems.rubyforge.org/ gem install subload --source http://gems.gemcutter.org gem install raggi-subload --source http://gems.github.com Any of which will work. Rubygems can store these, and my .gemrc looks like this: :sources: - http://gems.rubyforge.org/ - http://gemcutter.org - http://gems.github.com So when I type gem install it will try rubyforge first, then gemcutter.org, then gems.github.com. Dependencies could be on any or *all* of the three sources, I see no reason to to put restriction on this flexibility. All that would lead to is a "weakest link" problem, and over time as gem servers are deprecated or come into disservice those gems that have dependencies forcefully relying on them will be broken due to this feature you request. The resolution at this point would be to fetch the gem, unpack it, strip any signatures, open the gemspec, remove the dependency source, then repack the gem. Why would we ever want to do this? As for gemcutter, it's not finished, and still has issues, for example rspec is currently publishing prerelease gems to it, but they are not marked as prerelease by gemcutter, because the product is unfinished. Fact of life, new things take time to be completed. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 05:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 04:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 10:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 09:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 10:55:15 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 10:55:15 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Message-ID: <20090917145516.048CD177992E@rubyforge.org> Bugs item #26740, was opened at 2009-07-24 03:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 Category: None Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Initial Comment: Does system installer not delete old files? If someone happens to load this file, they get a warning, then get the wrong version. Can't we just move the version back into this file and avoid the issue altogether? chadmac:1.8 woolley$ pwd /Library/Ruby/Site/1.8 chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb RubyGemsVersion = VERSION = '1.3.5' chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb rubygems/rubygems_version.rb chadmac:~ woolley$ irb >> Gem::RubyGemsVersion => "1.3.5" >> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true >> Gem::RubyGemsVersion => "1.3.4" chadmac:~ woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 10:55 Message: I just want to point out that this exact bug bit us pretty badly again. The scenario is this (and I'm surprised it hasn't happened more frequently): We're running a rails 2.3.4 app. The rails 2.3.x branch requires rubygems 1.3.2 or greater. On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5. As a result, this left the rubygems_version.rb file specifying version 1.3.1. As a result, we could never actually run the rails app because of the version checking code in config/boot.rb. It took us quite awhile to track down what the issue really was. Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 16:53 Message: Agreed, a very low priority. I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs. However, this should probably get turned into a bug with the system install command, because it isn't deleting old files. This could come back to bite us in a more serious way in the future. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-07-24 16:51 Message: I can confirm the odd behavior on a default Leopard install: john-mbp:1.8 john$ irb irb(main):001:0> Gem::RubyGemsVersion => "1.3.5" irb(main):002:0> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true irb(main):003:0> Gem::RubyGemsVersion => "1.3.4" -John ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-07-24 15:16 Message: I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 15:01 Message: Rejected with no comment, huh? Classy. You ignore the fact that there are actual bugs: * RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution * This file contains an outdated and conflicting RubyGems version number * If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version. * There is a bug with the system update command that does not delete old files, at least on the default Leopard install. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 From noreply at rubyforge.org Thu Sep 17 14:23:30 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 14:23:30 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Message-ID: <20090917182330.E16481779934@rubyforge.org> Bugs item #26740, was opened at 2009-07-24 00:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 Category: None Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Initial Comment: Does system installer not delete old files? If someone happens to load this file, they get a warning, then get the wrong version. Can't we just move the version back into this file and avoid the issue altogether? chadmac:1.8 woolley$ pwd /Library/Ruby/Site/1.8 chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb RubyGemsVersion = VERSION = '1.3.5' chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb rubygems/rubygems_version.rb chadmac:~ woolley$ irb >> Gem::RubyGemsVersion => "1.3.5" >> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true >> Gem::RubyGemsVersion => "1.3.4" chadmac:~ woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- >Comment By: Ryan Davis (zenspider) Date: 2009-09-17 11:23 Message: I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion. How did you get bit by this bug? ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 07:55 Message: I just want to point out that this exact bug bit us pretty badly again. The scenario is this (and I'm surprised it hasn't happened more frequently): We're running a rails 2.3.4 app. The rails 2.3.x branch requires rubygems 1.3.2 or greater. On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5. As a result, this left the rubygems_version.rb file specifying version 1.3.1. As a result, we could never actually run the rails app because of the version checking code in config/boot.rb. It took us quite awhile to track down what the issue really was. Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 13:53 Message: Agreed, a very low priority. I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs. However, this should probably get turned into a bug with the system install command, because it isn't deleting old files. This could come back to bite us in a more serious way in the future. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-07-24 13:51 Message: I can confirm the odd behavior on a default Leopard install: john-mbp:1.8 john$ irb irb(main):001:0> Gem::RubyGemsVersion => "1.3.5" irb(main):002:0> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true irb(main):003:0> Gem::RubyGemsVersion => "1.3.4" -John ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-07-24 12:16 Message: I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 12:01 Message: Rejected with no comment, huh? Classy. You ignore the fact that there are actual bugs: * RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution * This file contains an outdated and conflicting RubyGems version number * If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version. * There is a bug with the system update command that does not delete old files, at least on the default Leopard install. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 From noreply at rubyforge.org Thu Sep 17 14:44:02 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 14:44:02 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Message-ID: <20090917184402.68C591779934@rubyforge.org> Bugs item #26740, was opened at 2009-07-24 03:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 Category: None Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Initial Comment: Does system installer not delete old files? If someone happens to load this file, they get a warning, then get the wrong version. Can't we just move the version back into this file and avoid the issue altogether? chadmac:1.8 woolley$ pwd /Library/Ruby/Site/1.8 chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb RubyGemsVersion = VERSION = '1.3.5' chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb rubygems/rubygems_version.rb chadmac:~ woolley$ irb >> Gem::RubyGemsVersion => "1.3.5" >> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true >> Gem::RubyGemsVersion => "1.3.4" chadmac:~ woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 14:44 Message: Hey Ryan, You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb. As a result, the "require 'rubygems'" call on line 86 of config/boot.rb was actually returning false and consequently not setting the RubyGemsVersion to 1.3.5 appropriately. This explains why I could not reproduce the problem in irb. My apologies for the noise. In any case, manually deleting the file did do the trick. -John ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-17 14:23 Message: I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion. How did you get bit by this bug? ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 10:55 Message: I just want to point out that this exact bug bit us pretty badly again. The scenario is this (and I'm surprised it hasn't happened more frequently): We're running a rails 2.3.4 app. The rails 2.3.x branch requires rubygems 1.3.2 or greater. On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5. As a result, this left the rubygems_version.rb file specifying version 1.3.1. As a result, we could never actually run the rails app because of the version checking code in config/boot.rb. It took us quite awhile to track down what the issue really was. Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 16:53 Message: Agreed, a very low priority. I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs. However, this should probably get turned into a bug with the system install command, because it isn't deleting old files. This could come back to bite us in a more serious way in the future. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-07-24 16:51 Message: I can confirm the odd behavior on a default Leopard install: john-mbp:1.8 john$ irb irb(main):001:0> Gem::RubyGemsVersion => "1.3.5" irb(main):002:0> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true irb(main):003:0> Gem::RubyGemsVersion => "1.3.4" -John ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-07-24 15:16 Message: I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 15:01 Message: Rejected with no comment, huh? Classy. You ignore the fact that there are actual bugs: * RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution * This file contains an outdated and conflicting RubyGems version number * If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version. * There is a bug with the system update command that does not delete old files, at least on the default Leopard install. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 From noreply at rubyforge.org Thu Sep 17 17:08:47 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 17:08:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Message-ID: <20090917210847.87AC81779937@rubyforge.org> Bugs item #26740, was opened at 2009-07-24 00:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 Category: None Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Initial Comment: Does system installer not delete old files? If someone happens to load this file, they get a warning, then get the wrong version. Can't we just move the version back into this file and avoid the issue altogether? chadmac:1.8 woolley$ pwd /Library/Ruby/Site/1.8 chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb RubyGemsVersion = VERSION = '1.3.5' chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb rubygems/rubygems_version.rb chadmac:~ woolley$ irb >> Gem::RubyGemsVersion => "1.3.5" >> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true >> Gem::RubyGemsVersion => "1.3.4" chadmac:~ woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- >Comment By: Chad Woolley (thewoolleyman) Date: 2009-09-17 14:08 Message: "You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb." I'm sure I fixed this in the latest geminstaller release. Please open a bug if I didn't. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 11:44 Message: Hey Ryan, You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb. As a result, the "require 'rubygems'" call on line 86 of config/boot.rb was actually returning false and consequently not setting the RubyGemsVersion to 1.3.5 appropriately. This explains why I could not reproduce the problem in irb. My apologies for the noise. In any case, manually deleting the file did do the trick. -John ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-17 11:23 Message: I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion. How did you get bit by this bug? ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 07:55 Message: I just want to point out that this exact bug bit us pretty badly again. The scenario is this (and I'm surprised it hasn't happened more frequently): We're running a rails 2.3.4 app. The rails 2.3.x branch requires rubygems 1.3.2 or greater. On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5. As a result, this left the rubygems_version.rb file specifying version 1.3.1. As a result, we could never actually run the rails app because of the version checking code in config/boot.rb. It took us quite awhile to track down what the issue really was. Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 13:53 Message: Agreed, a very low priority. I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs. However, this should probably get turned into a bug with the system install command, because it isn't deleting old files. This could come back to bite us in a more serious way in the future. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-07-24 13:51 Message: I can confirm the odd behavior on a default Leopard install: john-mbp:1.8 john$ irb irb(main):001:0> Gem::RubyGemsVersion => "1.3.5" irb(main):002:0> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true irb(main):003:0> Gem::RubyGemsVersion => "1.3.4" -John ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-07-24 12:16 Message: I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 12:01 Message: Rejected with no comment, huh? Classy. You ignore the fact that there are actual bugs: * RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution * This file contains an outdated and conflicting RubyGems version number * If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version. * There is a bug with the system update command that does not delete old files, at least on the default Leopard install. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 From noreply at rubyforge.org Thu Sep 17 21:34:54 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 21:34:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090918013454.CD39616782A8@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 11:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: Adam Salter (aqsalter) Date: 2009-09-18 11:34 Message: As I said I'm no longer really trying to chase this. I have solved my own issue in this regard, but I want to clarify a few things after thinking some more about this. OK, so firstly, you can install a gem from a specific source right? Why not then have dependencies from a specific source? Remember this all arose because I couldn't publish my gem to rubyforge and have a gem published to gemcutter as a dependency, and have it 'just work'(tm). When somebody tried to install my gem it would fail with a 'dependency not found'. Now, hopefully the user would read my documentation which states that my gem requires gemcutter, but that's not exactly a perfect solution. I _do_ understand that gems are not ideally source specific, otherwise it becomes "github-hpricot-1.2.3" vs "gemcutter-hpricot-1.2.3", but maybe they _should_ be... can't two gems of the same name be published with the same version to different sources? yes, potentially they can. The first solution to allowing people to publish gems to multiple sources is to allow them to have gems with multiple source dependencies. The _other_ solution is to act like there aren't multiple sources. Ie Rubyforge is the canonical and only gem source. If you want your gem to work you _have_ to publish to rubyforge... which is pretty much summed up by "If you find a gem that isn't on rubyforge... submit that as a bug report." I have a philosophical aversion to raising a bug report on a gem because it wasn't published to rubyforge. So I've published my gem to the same source, thereby requiring the user to install gemcutter. I'm assured my gem will work as long as it doesn't depend on a gem from a third gem source (which in this case it doesn't). I also realised that some confusion my have arose from my suggestion because I didn't clarify exactly what I was asking for in code... Iif no source is specified (as currently) every dependency will be resolved as currently, _so no current gems will break_. I think this might have been a misunderstanding. But for any single dependency that you (as the gem owner) know will not be resolved automatically you can specify a source. Obviously rubygem would try this source and raise an error (or maybe just warning and then try the default) if not found. No current gems broken. But also my own gem would 'just work'. Obviously if the gem server that my gem relies on disappears I would have to fix my gem. Yes I know that.... What is the difference between that and having 'gem install adamsalter-hpricot --source=http://gems.github.com' in my docs no longer work? The internet changes and websites come up and go down. Life goes on. Technically multiple gem sources seems to be a problem. Do we fully support multiple gem sources? In which case there is no way to be 100% sure that a gem is the right one without md5 hashing and checking the hashes. Name and version doesn't ensure you have the right gem. Perhaps if you do put a source in a dependency you also have to put a md5 hash? That way if it was mirrored the correct gem could still be found. Or even you could just have an extra option of md5 hash, using that you don't need the version either. (AT&T could still mirror multiple sources and be confident everything was going to work) Thanks everybody for all your great work on RubyGems. It is a great system for managing installation of ruby code. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-17 18:07 Message: Just for accuracies sake, I notice a commit went in for support of prerelease gems into gemcutter last night. I'm not sure if it's complete or deployed though, and this isn't the only thing. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-17 18:03 Message: Adam - what you don't seem to understand is that sources are completely separate from gems. My gems are available from gemcutter, rubyforge and github, for example. You could do: gem install subload --source http://gems.rubyforge.org/ gem install subload --source http://gems.gemcutter.org gem install raggi-subload --source http://gems.github.com Any of which will work. Rubygems can store these, and my .gemrc looks like this: :sources: - http://gems.rubyforge.org/ - http://gemcutter.org - http://gems.github.com So when I type gem install it will try rubyforge first, then gemcutter.org, then gems.github.com. Dependencies could be on any or *all* of the three sources, I see no reason to to put restriction on this flexibility. All that would lead to is a "weakest link" problem, and over time as gem servers are deprecated or come into disservice those gems that have dependencies forcefully relying on them will be broken due to this feature you request. The resolution at this point would be to fetch the gem, unpack it, strip any signatures, open the gemspec, remove the dependency source, then repack the gem. Why would we ever want to do this? As for gemcutter, it's not finished, and still has issues, for example rspec is currently publishing prerelease gems to it, but they are not marked as prerelease by gemcutter, because the product is unfinished. Fact of life, new things take time to be completed. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 15:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 14:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 13:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 20:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 19:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 19:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 19:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 18:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Thu Sep 17 21:53:57 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 17 Sep 2009 21:53:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26740 ] outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Message-ID: <20090918015357.243FA16782A8@rubyforge.org> Bugs item #26740, was opened at 2009-07-24 03:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 Category: None Group: None Status: Open Resolution: Rejected Priority: 3 Submitted By: Chad Woolley (thewoolleyman) Assigned to: Nobody (None) Summary: outdated rubygems/rubygems_version.rb still exists on Leopard default ruby install even though it was removed in 1.3.5 Initial Comment: Does system installer not delete old files? If someone happens to load this file, they get a warning, then get the wrong version. Can't we just move the version back into this file and avoid the issue altogether? chadmac:1.8 woolley$ pwd /Library/Ruby/Site/1.8 chadmac:1.8 woolley$ grep RubyGemsVersion rubygems.rb RubyGemsVersion = VERSION = '1.3.5' chadmac:1.8 woolley$ ls rubygems/rubygems_version.rb rubygems/rubygems_version.rb chadmac:~ woolley$ irb >> Gem::RubyGemsVersion => "1.3.5" >> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true >> Gem::RubyGemsVersion => "1.3.4" chadmac:~ woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.5 - RUBY VERSION: 1.8.6 (2008-08-11 patchlevel 287) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 21:53 Message: You have fixed it Chad-- our preinit wasn't enforcing 0.5.3 or greater, and this particular box did not yet have 0.5.3 installed. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-09-17 17:08 Message: "You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb." I'm sure I fixed this in the latest geminstaller release. Please open a bug if I didn't. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 14:44 Message: Hey Ryan, You know what, I just realized that I was loading geminstaller in the preinitializer, which was in turn loading rubygems_version.rb. As a result, the "require 'rubygems'" call on line 86 of config/boot.rb was actually returning false and consequently not setting the RubyGemsVersion to 1.3.5 appropriately. This explains why I could not reproduce the problem in irb. My apologies for the noise. In any case, manually deleting the file did do the trick. -John ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-17 14:23 Message: I just looked at rails 2.3.4 and don't see any place that rubygems_version is being required. The version checking code requires rubygems and then uses RubyGemsVersion. How did you get bit by this bug? ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-09-17 10:55 Message: I just want to point out that this exact bug bit us pretty badly again. The scenario is this (and I'm surprised it hasn't happened more frequently): We're running a rails 2.3.4 app. The rails 2.3.x branch requires rubygems 1.3.2 or greater. On this particular OSX machine, we jumped from RubyGems 1.3.1 directly to 1.3.5. As a result, this left the rubygems_version.rb file specifying version 1.3.1. As a result, we could never actually run the rails app because of the version checking code in config/boot.rb. It took us quite awhile to track down what the issue really was. Others not so in tune with RubyGems development are surely to lose a whole lot more time than we did. ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 16:53 Message: Agreed, a very low priority. I was only requiring explicitly as a side effect of my regression tests - normally you should rely on rubygems to require what it needs. However, this should probably get turned into a bug with the system install command, because it isn't deleting old files. This could come back to bite us in a more serious way in the future. ---------------------------------------------------------------------- Comment By: John Trupiano (jtrupiano) Date: 2009-07-24 16:51 Message: I can confirm the odd behavior on a default Leopard install: john-mbp:1.8 john$ irb irb(main):001:0> Gem::RubyGemsVersion => "1.3.5" irb(main):002:0> require 'rubygems/rubygems_version' /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:12: warning: already initialized constant RubyGemsVersion /Library/Ruby/Site/1.8/rubygems/rubygems_version.rb:17: warning: already initialized constant VERSION => true irb(main):003:0> Gem::RubyGemsVersion => "1.3.4" -John ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-07-24 15:16 Message: I agree, the rubygems_version.rb file should be deleted on update if possible. Mind you, I've never heard of anyone explicitly require'ing that file, so it strikes me as a very low priority item, but it's still something we could fix. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-07-24 15:01 Message: Rejected with no comment, huh? Classy. You ignore the fact that there are actual bugs: * RubyGems 1.3.5 introduced an obsolete file on the Leopard distribution * This file contains an outdated and conflicting RubyGems version number * If any existing rubygems API clients happen to still load this file, they will get a warning, and rubygems will subsequently report the incorrect and outdated version. * There is a bug with the system update command that does not delete old files, at least on the default Leopard install. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26740&group_id=126 From noreply at rubyforge.org Fri Sep 18 04:25:28 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 Sep 2009 04:25:28 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27109 ] Should be able to specify gem source in gemspec file Message-ID: <20090918082533.A72CD1978277@rubyforge.org> Bugs item #27109, was opened at 2009-09-16 01:44 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 Category: None Group: None Status: Closed Resolution: Rejected Priority: 3 Submitted By: Adam Salter (aqsalter) Assigned to: Nobody (None) Summary: Should be able to specify gem source in gemspec file Initial Comment: Since there are now at least 3 different 'major' gem hosts - rubyforge, github, gemcutter - it would be nice if a gem dependency's source could be specified in the gemspec file. It might be really nice if _all_ the options supported by 'gem install' were supported but at least being able to specify a non-rubyforge source would be great. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-09-18 08:25 Message: You're not understanding what I've told you. Your description of your problem is incorrect. "When somebody tried to install my gem it would fail with a 'dependency not found'. Now, hopefully the user would read my documentation which states that my gem requires gemcutter, but that's not exactly a perfect solution." So, let me get this straight. Your gem is only available on gemcutter, and you're telling me rubygems will report 'dependency not found' when someone tries to install it without the gemcutter source. I don't believe that. I repeat, on my setup, where I have rubyforge, github, and gemcutter permanently in my source list, when I install a gem, it will find dependencies on any one of those three gem servers - as long as the name matches. I've also told you, that gem sources will come and go. The problem you incorrectly describe will happen 100% guaranteed in the future if you bind gems to specific sources, as the sources WILL go away before the gems do. Binding gems to sources also REQUIRES access to the internet to install the gems, for example, you would be stopping local installs of gems, or gem servers living inside walled gardens. As far as "having the right gem" is concerned, this is one of my BIG BIG BIG issues with all these gemservers popping up. Gem::Security exists for *some* of this purpose but it is seldom used properly by gem authors, just as you are not using rubyforge properly, because you're lazy. It is not (contrary to recent hype) difficult to publish gems to rubyforge, the rubyforge gem (available on rubyforge and gemcutter) allows one to do so with a single command. It also allows one to manage file packages for ruby libraries suitable for those who do not use rubygems (of which there are still some people). The --source argument semantics seem to be the actual cause of your issue, but I'd suggest you're doing it wrong. You have an implicit configuration dependency on the user having two sources in their gem configuration. Your users must have rubyforge and gemcutter as individual sources in their configuration. You made this requirement. Don't introduce coupling as a solution to requirements YOU invented. Github is a complete misrepresentation of "a good way" to release gems in the sense of documentation failing, due to the username coupling. I've disagreed with their approach from the start, and I allowing people to be this lazy *already* causes massive issues for the sinatra community who jumped on that bandwagon like crazy. Their dependency stacks are very broken and sometimes completely unresolvable. That's their fault for not doing it right. End of story. gem install gemname The above should work, forever, as long as the user running the command has valid, well populated gem sources in their gem configuration. Those sources may be on the internet, they may be on a lan, they may be your mates laptop next to you running `gem server`. Coupling will only break many very valid use cases that *you* are just unaware of. The bug in your approach is using the --source argument. Stop using this in documentation, and start using your tools right, and stop telling your users to do it the wrong way too. Please please please try to understand several things: 1. Your gem requires configuration of rubygems. 2. Your gem is only available at an immature source because of you and you alone. 3. Your dependencies are not available at the immature source because the source is immature, and not a complete mirror. 4. Duplicating gem names is a security risk, and Gem::Security is already in existence to solve this issue, but poorly educated users think that coupling with specific sources is security (MiTM anyone?) 5. Sources will die - and your idea of MD5 publishings will fail when the same gem, wiht the same name and version, is rebuilt removing the source specific dependency you describe (bug). 6. All of your problems can be solved by proper use of the tools already provided, and correcting your documentation. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-18 01:34 Message: As I said I'm no longer really trying to chase this. I have solved my own issue in this regard, but I want to clarify a few things after thinking some more about this. OK, so firstly, you can install a gem from a specific source right? Why not then have dependencies from a specific source? Remember this all arose because I couldn't publish my gem to rubyforge and have a gem published to gemcutter as a dependency, and have it 'just work'(tm). When somebody tried to install my gem it would fail with a 'dependency not found'. Now, hopefully the user would read my documentation which states that my gem requires gemcutter, but that's not exactly a perfect solution. I _do_ understand that gems are not ideally source specific, otherwise it becomes "github-hpricot-1.2.3" vs "gemcutter-hpricot-1.2.3", but maybe they _should_ be... can't two gems of the same name be published with the same version to different sources? yes, potentially they can. The first solution to allowing people to publish gems to multiple sources is to allow them to have gems with multiple source dependencies. The _other_ solution is to act like there aren't multiple sources. Ie Rubyforge is the canonical and only gem source. If you want your gem to work you _have_ to publish to rubyforge... which is pretty much summed up by "If you find a gem that isn't on rubyforge... submit that as a bug report." I have a philosophical aversion to raising a bug report on a gem because it wasn't published to rubyforge. So I've published my gem to the same source, thereby requiring the user to install gemcutter. I'm assured my gem will work as long as it doesn't depend on a gem from a third gem source (which in this case it doesn't). I also realised that some confusion my have arose from my suggestion because I didn't clarify exactly what I was asking for in code... Iif no source is specified (as currently) every dependency will be resolved as currently, _so no current gems will break_. I think this might have been a misunderstanding. But for any single dependency that you (as the gem owner) know will not be resolved automatically you can specify a source. Obviously rubygem would try this source and raise an error (or maybe just warning and then try the default) if not found. No current gems broken. But also my own gem would 'just work'. Obviously if the gem server that my gem relies on disappears I would have to fix my gem. Yes I know that.... What is the difference between that and having 'gem install adamsalter-hpricot --source=http://gems.github.com' in my docs no longer work? The internet changes and websites come up and go down. Life goes on. Technically multiple gem sources seems to be a problem. Do we fully support multiple gem sources? In which case there is no way to be 100% sure that a gem is the right one without md5 hashing and checking the hashes. Name and version doesn't ensure you have the right gem. Perhaps if you do put a source in a dependency you also have to put a md5 hash? That way if it was mirrored the correct gem could still be found. Or even you could just have an extra option of md5 hash, using that you don't need the version either. (AT&T could still mirror multiple sources and be confident everything was going to work) Thanks everybody for all your great work on RubyGems. It is a great system for managing installation of ruby code. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-17 08:07 Message: Just for accuracies sake, I notice a commit went in for support of prerelease gems into gemcutter last night. I'm not sure if it's complete or deployed though, and this isn't the only thing. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-17 08:03 Message: Adam - what you don't seem to understand is that sources are completely separate from gems. My gems are available from gemcutter, rubyforge and github, for example. You could do: gem install subload --source http://gems.rubyforge.org/ gem install subload --source http://gems.gemcutter.org gem install raggi-subload --source http://gems.github.com Any of which will work. Rubygems can store these, and my .gemrc looks like this: :sources: - http://gems.rubyforge.org/ - http://gemcutter.org - http://gems.github.com So when I type gem install it will try rubyforge first, then gemcutter.org, then gems.github.com. Dependencies could be on any or *all* of the three sources, I see no reason to to put restriction on this flexibility. All that would lead to is a "weakest link" problem, and over time as gem servers are deprecated or come into disservice those gems that have dependencies forcefully relying on them will be broken due to this feature you request. The resolution at this point would be to fetch the gem, unpack it, strip any signatures, open the gemspec, remove the dependency source, then repack the gem. Why would we ever want to do this? As for gemcutter, it's not finished, and still has issues, for example rspec is currently publishing prerelease gems to it, but they are not marked as prerelease by gemcutter, because the product is unfinished. Fact of life, new things take time to be completed. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 05:39 Message: OK guys. I'll leave it in your capable hands. If, a) no two differing gems can have the same name (I actually really like github's solution to this) and b) other gem sources are at least able to compete as 'legitimate' external gem sources (by which adding a source to the .gemrc seems as good a solution as any) I guess I can't really complain. I probably won't publish my gem to rubyforge as everything will work for me as setup on gemcutter. The users have to install gemcutter to install my gem anyway. I just raised this issue here because it seemed like a solution to a problem I was trying to forsee (and that I haven't actually encountered yet, admittedly). Cheers, ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2009-09-17 04:40 Message: Specifying dependency sources would also break a significant number of companies who run combined internal gem servers. AT&T, for example, runs an internal gem server which mirrors *all* GitHub and Rubyforge gems, and all deploys use the internal mirror. If gems could specify dependency sources, mirrors like this would have to find a way to override those sources. Cross-source dependency resolution is definitely something we need to smooth out, but explicit dependency sources isn't the way to do it. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:50 Message: OK. Just to clarify. I do understand that it will complicate things, but I still think the large gem publishers will always find ways to make life easier for their users. i.e. publish to rubyforge... but no... I can't say I agree that no gem should ever have a specific source dependency. Small gem publishers might come and go, but gems already break because of version changes... it's the same thing (in my mind). The larger projects will probably never use source dependencies, but source dependency helps encourage change and competition for smaller gems (again in my mind). As the gem grows they will have to work out any issues.... Hopefully haven't offended anybody. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-17 03:36 Message: I understand the want to have gems work by default, but really think this is overcomplicating a simple issue. People are and will continue to want to publish gems to various gem providers. It's the way people are. This all started because I asked for somebody to publish a gem as a dependency and that gem got published to gemcutter. I was essentially forced to publish my gem to gemcutter so that I could use that dependency. I like the idea that other gem sources should be allowed to flourish. The (best) major ones will always win out... I don't see this gem apocalypse you envision. It is _not_ a bug (in my mind) that somebody didn't release their gem to rubyforge. No matter how easy or friendly it is. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 10:47 Message: Ryan - lol, sorry :-( It's useful, as a minimal starting point, for me. My main gripe of hoe is the task names, which i know is totally minor, but anyway, that's another discussion for somewhere else... ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2009-09-16 09:38 Message: Don't fool yourself. That isn't even close to what Hoe is capable of. :P ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:20 Message: Here is a rakefile that's largely as capable as hoe.rb, but self contained, and a single file. This would help with releasing to rubyforge, and also supports maintaining a .gemspec for github, making releasing on both systems trivial. http://github.com/raggi/subload/blob/master/Rakefile ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 09:17 Message: Several things here: 1. Rubyforge is the authorative source for rubygems. 2. Gemcutter although functional is not finished, and the discussion of merging it with the rubyforge source is underway - but only when it's ready. 3. Gemcutter requires gems be authorised for name clobber 4. Github won't publish gems that have the same name as a rubyforge gem 5. Gem security policies could be used to solve the auth problem 6. Contrary to popular (uneducated) belief, it is remarkably easy to publish gems to rubyforge using the rubyforge gem. 7. Despite it's php roots, rubyforge is very useful. 8. Gem files are not tied to a source, and never should be, that's centralisation and coupling that will be utterly destructive in future. 9. Github gem hosting is likely to leave soon, according to chris. 10. If you find a gem that isn't on rubyforge, then I recommend you submit that as a bug report. In my opinion that's *very* bad release policy. ---------------------------------------------------------------------- Comment By: Adam Salter (aqsalter) Date: 2009-09-16 09:07 Message: perhaps you're right... I do think that fully supporting other gem sources is a good idea. I regularly need a gem that isn't on rubyforge as a dependency. There is also the issue whereby a gem of the same name exists on two providers. I don't want my users to have their install break in strange ways because they got the wrong/different gem... It is a real issue. There are multiple gem providers and not all people are publishing to rubyforge as a default choice. Would you like me to raise it on the mailing list? ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-09-16 08:23 Message: Add the sources to your .gemrc and you're done. This is a really bad idea in the long run, as at least one of these services will disappear this year, then you'll have a lot of broken gems. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27109&group_id=126 From noreply at rubyforge.org Fri Sep 18 14:21:14 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 18 Sep 2009 14:21:14 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27099 ] Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Message-ID: <20090918182114.9D064185826A@rubyforge.org> Bugs item #27099, was opened at 2009-09-14 00:00 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 Category: #gem and #require methods Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: Cezary Baginski (czarek) Assigned to: Nobody (None) Summary: Problems with gems (treetop, polyglot, test-unit) installed in $HOME/.gem instead of /usr/local/... Initial Comment: I filed it initially as a bug in Lighthouse (cucumber): https://rspec.lighthouseapp.com/projects/16211-cucumber/tickets/445-patch-cucumber-cannot-find-treetop-if-all-gems-are-in-homegem#ticket-445-4 It seems like adding: gem 'foo-bar' fixes things for some gems, others need: Gem.activate('foo-bar') The Lighthouse ticket has a specific, detailed example in cucumber. ---------------------------------------------------------------------- >Comment By: Cezary Baginski (czarek) Date: 2009-09-18 20:21 Message: Workaround - add a version requirement, e.g.: gem 'foo-bar', '>=0' Ticket on redmine / ruby-core: http://redmine.ruby-lang.org/issues/show/2119 ---------------------------------------------------------------------- Comment By: Cezary Baginski (czarek) Date: 2009-09-14 00:56 Message: Just to make sure, I tried trunk (r2296), but it wouldn't let me even install gems in $HOME, even with --user-install (exception with Requirement being Nil in <=>() ). Maybe I'll submit a bug tomorrow. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27099&group_id=126 From noreply at rubyforge.org Mon Sep 21 10:39:12 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 Sep 2009 10:39:12 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26840 ] Computed hash in dependency.rb and specification.rb is sometimes too large. Message-ID: <20090921143912.459BF185825D@rubyforge.org> Bugs item #26840, was opened at 2009-08-04 13:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26840&group_id=126 Category: other Group: None >Status: Closed Resolution: Rejected Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: Eric Hodel (drbrain) Summary: Computed hash in dependency.rb and specification.rb is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. In particular, this is causing problems in IronRuby gems, but this is also possible in MRI. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- Comment By: Ryan Riley (panesofglass) Date: 2009-08-21 18:04 Message: I reset state and resolution in hopes of getting a response. ---------------------------------------------------------------------- Comment By: Ryan Riley (panesofglass) Date: 2009-08-11 06:56 Message: Not sure how when rb_hash is used, but Array#hash in MRI can misbehave too if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-08-10 17:02 Message: It's not too large, see rb_hash(). IronRuby should be casting the value down to something it can accept. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26840&group_id=126 From noreply at rubyforge.org Mon Sep 21 10:42:41 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 21 Sep 2009 10:42:41 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27154 ] Computed hash is sometimes too large. Message-ID: <20090921144242.122F6167829F@rubyforge.org> Bugs item #27154, was opened at 2009-09-21 09:42 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: Nobody (None) Summary: Computed hash is sometimes too large. Initial Comment: The current hash algorithm in dependency.rb (line 138) and specification.rb (line 658) can sometimes create a hash that is too large. This is also possible with Array#hash in MRI, which can also misbehave if one of the array elements returns a large hash value: class C def hash 100000000000000000000 end end [C.new].hash # => in `hash': bignum too big to convert into `long' (RangeError) REXML has a similar issue. http://redmine.ruby- lang.org/issues/show/1883 tracks the issue, and MRI will be fixing the issue. Suggested fixes are: edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 File: dependency.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb;C840659 (server) 6/23/2009 1:21 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/dependency.rb @@ -112,7 +112,7 @@ end def hash # :nodoc: - name.hash + type.hash + version_requirements.hash + name.hash ^ type.hash ^ version_requirements.hash end end =================================================================== edit: c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 File: specification.rb =================================================================== --- c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb;C908357 (server) 6/23/2009 1:24 PM +++ c:/ruby/libs/ruby/site_ruby/1.8/rubygems/specification.rb @@ -661,9 +661,8 @@ private :same_attributes? def hash # :nodoc: - @@attributes.inject(0) { |hash_code, (name, default_value)| - n = self.send(name).hash - hash_code + n + @@attributes.inject(612553) { |hash_code, (name, default_value)| + hash_code ^ self.send(name).hash } end =================================================================== ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27154&group_id=126 From noreply at rubyforge.org Wed Sep 23 14:53:24 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 Sep 2009 14:53:24 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27169 ] unable to resolve transitive dependencies? Message-ID: <20090923185324.6F90A18582B9@rubyforge.org> Bugs item #27169, was opened at 2009-09-23 18:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: unable to resolve transitive dependencies? Initial Comment: Appears that if you have a gem on github which depends on gems from rubyforge, which gems from rubyforge also have dependencies on gems from rubyforge, the install fails. Ex: (a fresh install of ruby) $ gem install rogerdpack-desc_method -v0.1.5 ERROR: Error installing rogerdpack-desc_method: ruby2ruby requires ruby_parser (~> 2.0, runtime) Thanks. -r [1] http://osdir.com/ml/ruby-talk/2009-08/msg00955.html ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 From noreply at rubyforge.org Wed Sep 23 14:55:51 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 23 Sep 2009 14:55:51 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27169 ] unable to resolve transitive dependencies? Message-ID: <20090923185551.ABA93185825D@rubyforge.org> Bugs item #27169, was opened at 2009-09-23 15:53 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: Roger Pack (rogerdpack) Assigned to: Nobody (None) Summary: unable to resolve transitive dependencies? Initial Comment: Appears that if you have a gem on github which depends on gems from rubyforge, which gems from rubyforge also have dependencies on gems from rubyforge, the install fails. Ex: (a fresh install of ruby) $ gem install rogerdpack-desc_method -v0.1.5 ERROR: Error installing rogerdpack-desc_method: ruby2ruby requires ruby_parser (~> 2.0, runtime) Thanks. -r [1] http://osdir.com/ml/ruby-talk/2009-08/msg00955.html ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2009-09-23 15:55 Message: That is a known issue: there is no cross repository gem dependency resolution. Patches are welcome. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27169&group_id=126 From noreply at rubyforge.org Tue Sep 29 04:39:47 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 29 Sep 2009 04:39:47 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27211 ] gem contents does not show prefix by default Message-ID: <20090929083947.8B2DE16782AA@rubyforge.org> Bugs item #27211, was opened at 2009-09-29 17:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27211&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: gem contents does not show prefix by default Initial Comment: On Fedora, with rubygems-1.3.5-1.fc12.noarch ruby-1.8.6.369-3.fc12.i686 $ gem contents --help shows: ------------------------------------------------ Defaults: --no-lib-only --prefix ------------------------------------------------ However prefix is not shown by default: ------------------------------------------------ $ gem contents --lib-only gettext lib lib/gettext lib/gettext/tools.rb lib/gettext/poparser.rb lib/gettext/textdomain.rb lib/gettext/textdomain_manager.rb ..... ------------------------------------------------ The attached patch seems to work. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27211&group_id=126 From noreply at rubyforge.org Tue Sep 29 06:05:37 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 29 Sep 2009 06:05:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27211 ] gem contents does not show prefix by default Message-ID: <20090929100537.EC6E51858279@rubyforge.org> Bugs item #27211, was opened at 2009-09-29 17:39 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27211&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Mamoru Tasaka (mtasaka) Assigned to: Nobody (None) Summary: gem contents does not show prefix by default Initial Comment: On Fedora, with rubygems-1.3.5-1.fc12.noarch ruby-1.8.6.369-3.fc12.i686 $ gem contents --help shows: ------------------------------------------------ Defaults: --no-lib-only --prefix ------------------------------------------------ However prefix is not shown by default: ------------------------------------------------ $ gem contents --lib-only gettext lib lib/gettext lib/gettext/tools.rb lib/gettext/poparser.rb lib/gettext/textdomain.rb lib/gettext/textdomain_manager.rb ..... ------------------------------------------------ The attached patch seems to work. ---------------------------------------------------------------------- >Comment By: Mamoru Tasaka (mtasaka) Date: 2009-09-29 19:05 Message: Also I think the explanation of $ gem contents: ------------------------------------------------ --[no-]prefix Don't include installed path prefix ------------------------------------------------ is confusing because actually with "--prefix" prefix _is_ shown. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27211&group_id=126 From noreply at rubyforge.org Wed Sep 30 05:18:46 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 30 Sep 2009 05:18:46 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-27216 ] R1.9 require does not work when ENV['GEM_PATH'] specified Message-ID: <20090930091846.94BC816782AB@rubyforge.org> Bugs item #27216, was opened at 2009-09-30 11:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27216&group_id=126 Category: #gem and #require methods Group: v1.3.x Status: Open Resolution: None Priority: 3 Submitted By: V?t Ondruch (voxik) Assigned to: Nobody (None) Summary: R1.9 require does not work when ENV['GEM_PATH'] specified Initial Comment: Hello, I'm trying to modify GEM_PATH variable from ruby script. However, modification of GEM_PATH environment variable has no effect since rubygems/custom_require is not required for Ruby 1.9. What was the intention here? Of course I can use Kernel.gem method which will populate $LOAD_PATH properly and then regular require works well, but is not consistent, since you don't have to do it for regular gem directories. Cheers Vit ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27216&group_id=126