From noreply at rubyforge.org Tue Aug 4 14:16:52 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 Aug 2009 14:16:52 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26840 ] Computed hash in dependency.rb and specification.rb is sometimes too large. Message-ID: <20090804181652.5918F1858125@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: Open Resolution: None Priority: 3 Submitted By: Ryan Riley (panesofglass) Assigned to: Nobody (None) 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 =================================================================== ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26840&group_id=126 From noreply at rubyforge.org Tue Aug 4 19:27:25 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 4 Aug 2009 19:27:25 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-22617 ] Gem.loaded_specs does not work on 1.9 Message-ID: <20090804232725.5AD0C19785A3@rubyforge.org> Bugs item #22617, was opened at 2008-10-30 10:32 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126 Category: other Group: v1.3.x Status: Open Resolution: Accepted Priority: 3 Submitted By: Paul Brannan (cout) Assigned to: Eric Hodel (drbrain) Summary: Gem.loaded_specs does not work on 1.9 Initial Comment: The loaded_specs attribute seems to always be empty on 1.9: [pbrannan at zem ruby]$ ruby -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs' {"ruby-prof"=>#=", #]]>, @version=#, @files=["Rakefile", "README", "LICENSE", "CHANGES", "bin/ruby-prof", "lib/ruby-prof", "lib/ruby-prof.rb", "lib/unprof.rb", "lib/ruby-prof/abstract_printer.rb", "lib/ruby-prof/call_tree_printer.rb", "lib/ruby-prof/call_tree_printer.rb.rej", "lib/ruby-prof/flat_printer.rb", "lib/ruby-prof/graph_html_printer.rb", "lib/ruby-prof/graph_printer.rb", "lib/ruby-prof/profile_test_case.rb", "lib/ruby-prof/task.rb", "rails_plugin/ruby-prof", "rails_plugin/ruby-prof/init.rb", "rails_plugin/ruby-prof/lib", "rails_plugin/ruby-prof/lib/profiling.rb", "examples/flat.txt", "examples/graph.html", "examples/graph.txt", "ext/extconf.rb", "ext/extconf.rb.rej", "ext/measure_allocations.h", "ext/measure_cpu_time.h", "ext/measure_memory.h", "ext/measure_process_time.h", "ext/measure_wall_time.h", "ext/ruby_prof.c", "test/basic_test.rb", "test/duplicate_names_test.rb", "test/line_number_test.rb", "test/measure_mode_test.rb", "test/module_test.rb", "test/no_method_class_test.rb", "test/prime.rb", "test/prime1.rb", "test/prime2.rb", "test/prime3.rb", "test/prime_test.rb", "test/printers_test.rb", "test/profile_unit_test.rb", "test/recursive_test.rb", "test/singleton_test.rb", "test/start_test.rb", "test/test_helper.rb", "test/test_suite.rb", "test/thread_test.rb", "test/timing_test.rb"], @has_rdoc=true, @specification_version=2, @loaded=true, @requirements=[], @signing_key=nil, @default_executable="ruby-prof", @email="shugo at ruby-lang.org and cfis at savagexi.com", @required_ruby_version=#=", #]]>, @rdoc_options=["--title", "ruby-prof", "--inline-source", "--line-numbers", "--main", "README"], @bindir="bin", @rubygems_version="1.2.0", @homepage="http://rubyforge.org/projects/ruby-prof/", @name="ruby-prof", @platform="ruby", @autorequire=nil, @rubyforge_project="ruby-prof", @extensions=["ext/extconf.rb"], @summary="Fast Ruby profiler", @loaded_from="/usr/local/lib/ruby/gems/1.8/specifications/ruby-prof-0.6.0.gemspec", @original_platform=nil, @post_install_message=nil, @description="ruby-prof is a fast code profiler for Ruby. It is a C extension and therefore is many times faster than the standard Ruby profiler. It supports both flat and graph profiles. For each method, graph profiles show how long the method ran, which methods called it and which methods it called. RubyProf generate both text and html and can output it to standard out or to a file.", @dependencies=[], @test_files=["test/test_helper.rb", "test/test_suite.rb"], @require_paths=["bin", "lib"]>} [pbrannan at zem ruby]$ ruby1.9 -rubygems -e 'gem("ruby-prof"); p Gem.loaded_specs' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 216:'def' and line 218:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 231:'def' and line 233:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 246:'def' and line 248:'end' /usr/local/lib/ruby/gems/1.9.0/gems/rubygems-update-1.3.1/lib/rubygems/config_file.rb:7: warning: mismatched indentations: line 261:'def' and line 263:'end' {} ---------------------------------------------------------------------- Comment By: Matt Hulse (mhulse) Date: 2009-08-04 17:27 Message: Yes, this is still happening in 1.9.1-p129. I'm on WinXP Pro using the mingw32 build from rubyinstaller.org/downloads. I just updated to rubygems 1.3.5 using gem update --system and Gem.loaded_specs is still empty until I call gem('') or gem('nokogiri') (the gem I'm looking for). ---------------------------------------------------------------------- Comment By: Joeri Samson (joeri) Date: 2009-03-29 12:42 Message: with 1.9.1p0 and rubygems 1.3.1 I get the same error as Eric Hodel, except if I print/access Gem.loaded_specs before calling gem "rake": joeri at alpha ~ $ ruby19 -rubygems -e 'p Gem.loaded_specs; gem("rake"); p Gem.loaded_specs' {} {"rake"=>#, @summary="Ruby based make-like utility.", @email="jim at weirichhouse.org", @homepage="http://rake.rubyforge.org", @rubyforge_project="rake", @description="Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax.", @autorequire=nil, @default_executable="rake", @signing_key=nil, @post_install_message=nil, @original_platform=nil, @rubygems_version="1.3.1", @specification_version=2, @date=2009-03-04 00:00:00 +0100, @require_paths=["bin", "lib"], @bindir="bin", @has_rdoc=true, @required_ruby_version=#=", #]], @version=nil>, @required_rubygems_version=#=", #]], @version=nil>, @platform="ruby", @cert_chain=[], @authors=["Jim Weirich"], @files=["install.rb", "CHANGES", "MIT-LICENSE", "Rakefile", "README", "TODO", "bin/rake", "lib/rake/classic_namespace.rb", "lib/rake/clean.rb", "lib/rake/contrib/compositepublisher.rb", "lib/rake/contrib/ftptools.rb", "lib/rake/contrib/publisher.rb", "lib/rake/contrib/rubyforgepublisher.rb", "lib/rake/contrib/sshpublisher.rb", "lib/rake/contrib/sys.rb", "lib/rake/gempackagetask.rb", "lib/rake/loaders/makefile.rb", "lib/rake/packagetask.rb", "lib/rake/rake_test_loader.rb", "lib/rake/rdoctask.rb", "lib/rake/repaired_system.rb", "lib/rake/ruby182_test_unit_fix.rb", "lib/rake/runtest.rb", "lib/rake/tasklib.rb", "lib/rake/testtask.rb", "lib/rake/win32.rb", "lib/rake.rb", "test/capture_stdout.rb", "test/check_expansion.rb", "test/contrib/test_sys.rb", "test/data/rakelib/test1.rb", "test/data/rbext/rakefile.rb", "test/filecreation.rb", "test/functional.rb", "test/in_environment.rb", "test/rake_test_setup.rb", "test/reqfile.rb", "test/reqfile2.rb", "test/session_functional.rb", "test/shellcommand.rb", "test/test_application.rb", "test/test_clean.rb", "test/test_definitions.rb", "test/test_earlytime.rb", "test/test_extension.rb", "test/test_file_creation_task.rb", "test/test_file_task.rb", "test/test_filelist.rb", "test/test_fileutils.rb", "test/test_ftp.rb", "test/test_invocation_chain.rb", "test/test_makefile_loader.rb", "test/test_multitask.rb", "test/test_namespace.rb", "test/test_package_task.rb", "test/test_pathmap.rb", "test/test_rake.rb", "test/test_rdoc_task.rb", "test/test_require.rb", "test/test_rules.rb", "test/test_task_arguments.rb", "test/test_task_manager.rb", "test/test_tasklib.rb", "test/test_tasks.rb", "test/test_test_task.rb", "test/test_top_level_functions.rb", "test/test_win32.rb", "test/data/imports/deps.mf", "test/data/sample.mf", "test/data/chains/Rakefile", "test/data/default/Rakefile", "test/data/dryrun/Rakefile", "test/data/file_creation_task/Rakefile", "test/data/imports/Rakefile", "test/data/multidesc/Rakefile", "test/data/namespace/Rakefile", "test/data/statusreturn/Rakefile", "test/data/unittest/Rakefile", "test/data/unittest/subdir", "doc/command_line_usage.rdoc", "doc/example", "doc/example/a.c", "doc/example/b.c", "doc/example/main.c", "doc/example/Rakefile1", "doc/example/Rakefile2", "doc/glossary.rdoc", "doc/jamis.rb", "doc/proto_rake.rdoc", "doc/rake.1.gz", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @test_files=[], @rdoc_options=["--line-numbers", "--inline-source", "--main", "README", "--title", "Rake -- Ruby Make"], @extra_rdoc_files=["README", "MIT-LICENSE", "TODO", "CHANGES", "doc/command_line_usage.rdoc", "doc/glossary.rdoc", "doc/proto_rake.rdoc", "doc/rakefile.rdoc", "doc/rational.rdoc", "doc/release_notes/rake-0.4.14.rdoc", "doc/release_notes/rake-0.4.15.rdoc", "doc/release_notes/rake-0.5.0.rdoc", "doc/release_notes/rake-0.5.3.rdoc", "doc/release_notes/rake-0.5.4.rdoc", "doc/release_notes/rake-0.6.0.rdoc", "doc/release_notes/rake-0.7.0.rdoc", "doc/release_notes/rake-0.7.1.rdoc", "doc/release_notes/rake-0.7.2.rdoc", "doc/release_notes/rake-0.7.3.rdoc", "doc/release_notes/rake-0.8.0.rdoc", "doc/release_notes/rake-0.8.2.rdoc", "doc/release_notes/rake-0.8.3.rdoc", "doc/release_notes/rake-0.8.4.rdoc"], @executables=["rake"], @extensions=[], @requirements=[], @dependencies=[], @loaded=true, @loaded_from="/home/joeri/.gem/ruby/1.9.1/specifications/rake-0.8.4.gemspec">} ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-03-27 15:29 Message: With 1.9.1p0 and 1.9.2dev I see: $ ruby19 -v -rubygems -e 'gem "rake"; p Gem.loaded_specs' ruby 1.9.2dev (2009-03-28 trunk 23085) [i386-darwin9.6.0] :234:in `push_gem_version_on_load_path': Could not find RubyGem rake (>= 0) (Gem::LoadError) from :14:in `gem' from -e:1:in `
' This will take a bit more work than I planned for 1.3.1, and may require changes to gem_prelude :/ ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-03-16 04:50 Message: Ah, no, I hit .activate, which hits source_index. ---------------------------------------------------------------------- Comment By: James Tucker (raggi) Date: 2009-03-16 04:48 Message: works for me ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-01-02 08:59 Message: Is this still happening in 1.9.1? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=22617&group_id=126 From noreply at rubyforge.org Fri Aug 7 15:16:26 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 7 Aug 2009 15:16:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26892 ] Gem::Ext::RakeBuilder can't execute Rake on JRuby if Rake gem isn't installed Message-ID: <20090807191627.05E111858121@rubyforge.org> Bugs item #26892, was opened at 2009-08-07 12:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126 Category: `gem install` command (extensions) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jake Douglas (yakischloba) Assigned to: Nobody (None) Summary: Gem::Ext::RakeBuilder can't execute Rake on JRuby if Rake gem isn't installed Initial Comment: On JRuby, when installing a gem that has 'extensions = "Rakefile"' as part of it's specification, Gem::Ext::RakeBuilder tries to run 'jrake' which does not exist in JRuby. This occurs when the actual Rake gem is not installed. This can be worked around by requiring the rake gem as a dependency, but the desired behavior would be for it to find the rake that is bundled with JRuby. This line, in the "1.8" compatible rubygems, is the culprit: cmd = ENV['rake'] || "#{Gem.ruby} -rubygems #{Gem.bin_path('rake')}" rescue Gem.default_exec_format % 'rake' In the "1.9" rubygems, its like this: cmd = ENV['rake'] || 'rake' which probably wouldn't work either unless JRuby is the default Ruby or the JRuby rake points it to the jruby executable. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126 From docwhat at gmail.com Fri Aug 7 15:51:30 2009 From: docwhat at gmail.com (Doctor What) Date: Fri, 7 Aug 2009 15:51:30 -0400 Subject: [Rubygems-developers] --format-executable should be the default In-Reply-To: References: <1095EA03-2A0C-451F-84FF-1A9B024687A6@gmail.com> <90681D1F-18E7-469C-81C7-D880C113E616@segment7.net> <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> Message-ID: On Sat, Jul 25, 2009 at 6:32 PM, Chad Woolley wrote: > OK. ?Reverted and made a patch: > http://rubyforge.org/tracker/index.php?func=detail&aid=26754&group_id=126&atid=577 > - I thought when you said "I would like" it meant "make it so". > > I'd like to get feedback from JRuby or anyone else about required changes to > this, because this is a blocker to multiple MRI interpreters coexisting > [1]. ?Also, I'm pretty sure there's a bug in the existing code [2] > > Thanks, > -- Chad > > [1] http://github.com/thewoolleyman/bootstrap-ruby > [2] incorrect symbol name :no_format_executable in > Gem::Commands::UpdateCommand#do_rubygems_update line 142. Is there anything I can do to help push this forward? Ciao! -- Computers are useless. They can only give you answers. -- Pablo Picasso The Doctor What: http://docwhat.gerf.org/ docwhat *at* gmail *dot* com KF6VNC From headius at headius.com Fri Aug 7 16:38:01 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 7 Aug 2009 16:38:01 -0400 Subject: [Rubygems-developers] --format-executable should be the default In-Reply-To: <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> References: <1095EA03-2A0C-451F-84FF-1A9B024687A6@gmail.com> <90681D1F-18E7-469C-81C7-D880C113E616@segment7.net> <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> Message-ID: On Fri, Jul 24, 2009 at 4:58 PM, Eric Hodel wrote: > Please revert this change. ?There wasn't even 24 hours of discussion on this > before you made it. > > When the feature was introduced there was a fairly lengthy discussion with > the JRuby folks. ?I doubt they've even had a change to check this list. Hey, my *jruby* search picked this up. I have no general objection to --format-executables being on by default, except that it will mean a whole lot of tutorials out there get a bit more confusing ("rails myapp" will now be "jrails myapp"). A specific concern, however, is that Rails, for example, even today does not behave nicely with nonstandard-named binaries. For example, it has hardcoded "rake" and "ruby" in many places, and as a result a lot of those things would start breaking. I think this change needs to be tested with at least Rails and probably any other libraries/apps/frameworks that launch Ruby-related commands. Perhaps this will also drive people to stop hardcoding things like "ruby" or "rake" or "irb", since this often basically breaks them for JRuby or any other Ruby impl with a non-standard name. - Charlie From jftucker at gmail.com Sat Aug 8 14:30:24 2009 From: jftucker at gmail.com (James Tucker) Date: Sat, 8 Aug 2009 19:30:24 +0100 Subject: [Rubygems-developers] --format-executable should be the default In-Reply-To: References: <1095EA03-2A0C-451F-84FF-1A9B024687A6@gmail.com> <90681D1F-18E7-469C-81C7-D880C113E616@segment7.net> <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> Message-ID: <4A00401D-F650-4BAA-8523-49D299E29F30@gmail.com> On 7 Aug 2009, at 21:38, Charles Oliver Nutter wrote: > On Fri, Jul 24, 2009 at 4:58 PM, Eric Hodel > wrote: >> Please revert this change. There wasn't even 24 hours of >> discussion on this >> before you made it. >> >> When the feature was introduced there was a fairly lengthy >> discussion with >> the JRuby folks. I doubt they've even had a change to check this >> list. > > Hey, my *jruby* search picked this up. > > I have no general objection to --format-executables being on by > default, except that it will mean a whole lot of tutorials out there > get a bit more confusing ("rails myapp" will now be "jrails myapp"). As a user who uses multiple interpreters regularly, I would find this to be both more consistent, and very useful. I won't claim to be representative of most users though. The addition of Gem.bin_path should aid actually launching applications with Kernel#system etc, although I don't know if this can be made to fit more gracefully with jruby's special casing for such methods? I would certainly expect, other than old habits, consistent use of this wouldn't be too confusing for users after the initial change over? From alex.vollmer at gmail.com Mon Aug 10 14:08:03 2009 From: alex.vollmer at gmail.com (Alex Vollmer) Date: Mon, 10 Aug 2009 11:08:03 -0700 Subject: [Rubygems-developers] zsh completion Message-ID: <939A776E-14D4-4773-836D-137A5D0F1006@gmail.com> I did a little trolling around this weekend and didn't see that anyone else had come up with a satisfactory zsh completion scheme for the "gem" command. So, since I'm some kind of sadist, I jumped into the exciting world of zsh-completion and cooked up a completion script that is about 95% of the way there. It uses the newer "compsys" completion style mechanism. If you have that available, you should be able to download the script from http://gist.github.com/164465 into a directory in your $fpath, name it "_gem" and start a new shell. Would this make sense to distribute in the gem somehow, or should I send it to the zsh team instead? Thoughts? Opinions? Cheers, Alex V. ---- http://alexvollmer.com http://moochbot.com From noreply at rubyforge.org Mon Aug 10 18:02:31 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 10 Aug 2009 18:02:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26840 ] Computed hash in dependency.rb and specification.rb is sometimes too large. Message-ID: <20090810220231.E56E018581F0@rubyforge.org> Bugs item #26840, was opened at 2009-08-04 11: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: Eric Hodel (drbrain) Date: 2009-08-10 15: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 drbrain at segment7.net Mon Aug 10 18:04:35 2009 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Aug 2009 15:04:35 -0700 Subject: [Rubygems-developers] --format-executable should be the default In-Reply-To: <4A00401D-F650-4BAA-8523-49D299E29F30@gmail.com> References: <1095EA03-2A0C-451F-84FF-1A9B024687A6@gmail.com> <90681D1F-18E7-469C-81C7-D880C113E616@segment7.net> <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> <4A00401D-F650-4BAA-8523-49D299E29F30@gmail.com> Message-ID: <6C7380D0-E241-42BE-873B-4B23037DEFBE@segment7.net> On Aug 8, 2009, at 11:30, James Tucker wrote: > On 7 Aug 2009, at 21:38, Charles Oliver Nutter wrote: > On Fri, Jul 24, 2009 at 4:58 PM, Eric Hodel > wrote: >>> Please revert this change. There wasn't even 24 hours of >>> discussion on this >>> before you made it. >>> >>> When the feature was introduced there was a fairly lengthy >>> discussion with >>> the JRuby folks. I doubt they've even had a change to check this >>> list. >> >> Hey, my *jruby* search picked this up. >> >> I have no general objection to --format-executables being on by >> default, except that it will mean a whole lot of tutorials out there >> get a bit more confusing ("rails myapp" will now be "jrails myapp"). > > As a user who uses multiple interpreters regularly, I would find > this to be both more consistent, and very useful. I won't claim to > be representative of most users though. > > The addition of Gem.bin_path should aid actually launching > applications with Kernel#system etc, although I don't know if this > can be made to fit more gracefully with jruby's special casing for > such methods? Agreed. I think, at least for bug 26892, this can easily be fixed for RubyGems-internal use of standard tools like rake. > I would certainly expect, other than old habits, consistent use of > this wouldn't be too confusing for users after the initial change > over? From stephen.bannasch at deanbrook.org Mon Aug 10 21:03:22 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 10 Aug 2009 21:03:22 -0400 Subject: [Rubygems-developers] --format-executable should be the default In-Reply-To: <6C7380D0-E241-42BE-873B-4B23037DEFBE@segment7.net> References: <1095EA03-2A0C-451F-84FF-1A9B024687A6@gmail.com> <90681D1F-18E7-469C-81C7-D880C113E616@segment7.net> <88D81C45-8C7F-4A69-9BD6-CFEDB0DA2FC2@segment7.net> <4A00401D-F650-4BAA-8523-49D299E29F30@gmail.com> <6C7380D0-E241-42BE-873B-4B23037DEFBE@segment7.net> Message-ID: I work with both MRI and JRuby extensively and often at the same time (and often multiple JRubys with different gem configurations) and I like having the same names for the executable commands. I prefix all of the jruby use of an executable with: jruby -S <...> Which works great -- I don't know if this works with other Ruby vm's however. Will I be able to set --no-format-executable in a global location to preserve this behavior? From noreply at rubyforge.org Tue Aug 11 07:56:58 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 11 Aug 2009 07:56:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26840 ] Computed hash in dependency.rb and specification.rb is sometimes too large. Message-ID: <20090811115658.9DDB71858121@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-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 Fri Aug 14 04:46:04 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 14 Aug 2009 04:46:04 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26920 ] LOTS of unnecessary specs pulled on fetch Message-ID: <20090814084604.249641978117@rubyforge.org> Bugs item #26920, was opened at 2009-08-14 01:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26920&group_id=126 Category: `gem` commands (other) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Eric Hodel (drbrain) Summary: LOTS of unnecessary specs pulled on fetch Initial Comment: shouldn't it only fetch the latest? 507 % rm ~/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.* 508 % rm twitter-0.6.13.gem 509 % gem fetch twitter Downloaded twitter-0.6.13 510 % find ~/.gem | grep twitter /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.0.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.0.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.0.3.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.0.4.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.0.5.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.1.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.1.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.3.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.4.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.5.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.6.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.2.7.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.3.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.4.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.5.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.6.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.7.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.3.8.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.4.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.4.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.4.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.4.4.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.5.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.5.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.5.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.5.3.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.0.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.1.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.10.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.11.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.12.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.13.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.2.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.3.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.4.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.5.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.6.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.7.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.8.gemspec /Users/ryan/.gem/specs/gems.rubyforge.org%80/quick/Marshal.4.8/twitter-0.6.9.gemspec ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26920&group_id=126 From noreply at rubyforge.org Sat Aug 15 18:20:55 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 15 Aug 2009 18:20:55 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26801 ] gem update --system: breaks rubygems under Windows XP using & quot; mingw32-ruby-1.9.1-wxruby-2.0.0-setup.exe& quot; Message-ID: <20090815222055.464D716782A3@rubyforge.org> Bugs item #26801, was opened at 2009-07-30 11:27 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26801&group_id=126 Category: `gem` commands (other) Group: v1.3.x >Status: Closed Resolution: None Priority: 3 Submitted By: Rainer Wolf (rainer42) Assigned to: Nobody (None) Summary: gem update --system: breaks rubygems under Windows XP using &quot;mingw32-ruby-1.9.1-wxruby-2.0.0-setup.exe&quot; Initial Comment: I have a Ruby installation with wxRuby on Windows XP using this installer: mingw32-ruby-1.9.1-wxruby-2.0.0-setup.exe I typed gem -v and found out that I was rubygems 1.3.1. So I typed: gem update --system This was the result: ---begin--- Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.3.5 :0:Warning: Gem::SourceIndex#search support for String patterns is deprecated Updating RubyGems to 1.3.5 Installing RubyGems 1.3.5 c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/ config_file. rb:39:in `new': wrong number of arguments (5 for 4) (ArgumentError) from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /config_file.rb:39:in `' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /config_file.rb:12:in `' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /gem_runner.rb:8:in `require' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /gem_runner.rb:8:in `' from setup.rb:25:in `require' from setup.rb:25:in `
' RubyGems system software updated --end-- Now, when I type gem -v I get this: ---begin--- c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/lib/rubygems/ config_file. rb:39:in `new': wrong number of arguments (5 for 4) (ArgumentError) from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /config_file.rb:39:in `' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /config_file.rb:12:in `' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /gem_runner.rb:8:in `require' from c:/ruby/lib/ruby/gems/1.9.1/gems/rubygems-update-1.3.5/ lib/rubygems /gem_runner.rb:8:in `' from c:/ruby/bin/gem.bat:17:in `require' from c:/ruby/bin/gem.bat:17:in `
' ---end--- Does this mean I have broken rubygems on mingw32 by typing "gem update --system"? Typing "gem search wxruby-ruby19 --remote" or trying to install a gem - any gem - gives me the same argument error. Since rubygems was unusable, I uninstalled and reinstalled Ruby, using rubygems 1.3.1 for the time being. So this bug is not "lethal". Kind regards, Rainer ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2009-08-15 19:20 Message: Hello Rainer, I'm closing this now since this doesn't seems something to be reproducible outside that scenario. Feel free to reopen if you believe this still an issue. Regards. Luis Lavena ---------------------------------------------------------------------- Comment By: Rainer Wolf (rainer42) Date: 2009-07-30 16:22 Message: Thanks for the answer, Luis. You're really fast! ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-07-30 12:13 Message: As stated by wxRuby developers, there were some C API changes or similar that made things not to work between patchlevels (in similar fashion with 1.8.7). Is safe to manually install RubyGems on top of 1.9.1. In my experience RubyGems never installed properly on 1.9 using gem update --system. For The official One-Click Installer we update it using ruby setup.rb and works, so should work over wxRuby installer too. Cheers. ---------------------------------------------------------------------- Comment By: Rainer Wolf (rainer42) Date: 2009-07-30 12:09 Message: Hello Luis, thanks for the quick reply. Two questions about this: Up until now, I never ever had a problem with updating rubygems. In your opinion, is it wise to do a manual installation of rubygems as described in your first link? Second: Thanks for the link to the proper installer, but I have used p129 before. Couldn't get the wxRuby gem to work with that under Windows XP: http://www.ruby-forum.com/topic/187872#new So I switched to p0 with the unsupported installer mentioned above. Is your installer of p129 known to work with the wxRuby gem? ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2009-07-30 11:40 Message: When automatic installation fails, you can fall back to manual installation. http://blog.mmediasys.com/2008/08/04/problems-with-rubygems-find-here-some-handy-tips/ Keep in mind that Ruby version built by wxRuby team is not supported and is an old patchlevel (not latest stable). Please use proper new One-Click Ruby Installers for 1.9.1: http://blog.mmediasys.com/2009/06/28/rubyinstaller-preview1-released/ ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26801&group_id=126 From noreply at rubyforge.org Mon Aug 17 22:57:58 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Aug 2009 22:57:58 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818025758.2759618581E5@rubyforge.org> Bugs item #26936, was opened at 2009-08-18 12: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: Open 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? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26936&group_id=126 From noreply at rubyforge.org Mon Aug 17 23:35:38 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Mon, 17 Aug 2009 23:35:38 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818033538.2E4281858120@rubyforge.org> Bugs item #26936, was opened at 2009-08-18 12: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: Open 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-18 13: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 Tue Aug 18 02:08:31 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Aug 2009 02:08:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818060831.AB1A918581F3@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: Open 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: 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 Tue Aug 18 02:13:57 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Aug 2009 02:13:57 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818061357.8AF4119780E7@rubyforge.org> Bugs item #26936, was opened at 2009-08-18 12: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: Open 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-18 16: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-18 16: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-18 13: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 Tue Aug 18 02:15:54 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Aug 2009 02:15:54 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818061554.93AC218581F4@rubyforge.org> Bugs item #26936, was opened at 2009-08-17 23: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: Open 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: Luis Lavena (luislavena) Date: 2009-08-18 03: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-18 03: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-18 03: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-18 00: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 Tue Aug 18 02:28:11 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 18 Aug 2009 02:28:11 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26936 ] undefined method `prerelease?' for nil:NilClass Message-ID: <20090818062812.09DF318581F8@rubyforge.org> Bugs item #26936, was opened at 2009-08-18 12: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: Open 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-18 16: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-18 16: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-18 16: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-18 16: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-18 13: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 jftucker at gmail.com Tue Aug 18 04:34:49 2009 From: jftucker at gmail.com (James Tucker) Date: Tue, 18 Aug 2009 09:34:49 +0100 Subject: [Rubygems-developers] rubygems.org Message-ID: Good day all, rubygems.org is in renewal, and is currently redirecting to an advertising holding page. Regards, James From jftucker at gmail.com Tue Aug 18 12:49:18 2009 From: jftucker at gmail.com (James Tucker) Date: Tue, 18 Aug 2009 17:49:18 +0100 Subject: [Rubygems-developers] rubygems.org In-Reply-To: References: Message-ID: <9C5919C5-496B-4D1F-9BEF-A4A1299DF712@gmail.com> On 18 Aug 2009, at 16:02, Chad Fowler wrote: > Got it, thanks. We've been trying to transfer it to Eric with not > much luck. I let it run out but ended up just going ahead and paying > to renew it. As always, for so many things, thank you Chad :-) > > Chad > > On Tue, Aug 18, 2009 at 2:34 AM, James Tucker > wrote: >> Good day all, >> >> rubygems.org is in renewal, and is currently redirecting to an >> advertising >> holding page. >> >> Regards, >> >> James >> From luislavena at gmail.com Tue Aug 18 12:58:18 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Aug 2009 13:58:18 -0300 Subject: [Rubygems-developers] rubygems.org In-Reply-To: <9C5919C5-496B-4D1F-9BEF-A4A1299DF712@gmail.com> References: <9C5919C5-496B-4D1F-9BEF-A4A1299DF712@gmail.com> Message-ID: <71166b3b0908180958r79305d21p3a4e0eb79872e090@mail.gmail.com> On Tue, Aug 18, 2009 at 1:49 PM, James Tucker wrote: > > On 18 Aug 2009, at 16:02, Chad Fowler wrote: > >> Got it, thanks. ?We've been trying to transfer it to Eric with not >> much luck. I let it run out but ended up just going ahead and paying >> to renew it. What Registrar are you using Chad? Transfer of ownership has become really easy these days, without risking the domain during expiration period. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From drbrain at segment7.net Tue Aug 18 14:13:38 2009 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 18 Aug 2009 11:13:38 -0700 Subject: [Rubygems-developers] rubygems.org In-Reply-To: <71166b3b0908180958r79305d21p3a4e0eb79872e090@mail.gmail.com> References: <9C5919C5-496B-4D1F-9BEF-A4A1299DF712@gmail.com> <71166b3b0908180958r79305d21p3a4e0eb79872e090@mail.gmail.com> Message-ID: <21C1EC35-1175-44FD-8ADD-8D999DD54D69@segment7.net> On Aug 18, 2009, at 09:58, Luis Lavena wrote: > On Tue, Aug 18, 2009 at 1:49 PM, James Tucker > wrote: >> >> On 18 Aug 2009, at 16:02, Chad Fowler wrote: >> >>> Got it, thanks. We've been trying to transfer it to Eric with not >>> much luck. I let it run out but ended up just going ahead and paying >>> to renew it. > > What Registrar are you using Chad? Transfer of ownership has become > really easy these days, without risking the domain during expiration > period. Chad and I tried to transfer it over to me, but we failed to make it happen. His registrar seems pretty terrible in this regard. From ryand-ruby at zenspider.com Wed Aug 19 04:00:26 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 19 Aug 2009 01:00:26 -0700 Subject: [Rubygems-developers] Gem::Version::Part#inspect needs to return a string Message-ID: <26FBE3AC-E1B0-4AAF-A96A-16C9DA6233AA@zenspider.com> Unless there are any objections, I'd like to submit the following: Index: test/test_gem_version.rb =================================================================== --- test/test_gem_version.rb (revision 2284) +++ test/test_gem_version.rb (working copy) @@ -308,6 +308,18 @@ assert_equal( 1, Gem::Version::Part.new(1) <=> Gem::Version::Part.new("a")) end + def test_to_s + assert_equal "1", Gem::Version::Part.new(1).to_s + assert_equal "1", Gem::Version::Part.new("1").to_s + assert_equal "a", Gem::Version::Part.new("a").to_s + end + + def test_inspect + assert_equal "1", Gem::Version::Part.new( 1 ).inspect + assert_equal "1", Gem::Version::Part.new("1").inspect + assert_equal '"a"', Gem::Version::Part.new("a").inspect + end + def test_succ assert_equal 2, Gem::Version::Part.new(1).succ.value assert_equal "b", Gem::Version::Part.new("a").succ.value Index: lib/rubygems/version.rb =================================================================== --- lib/rubygems/version.rb (revision 2284) +++ lib/rubygems/version.rb (working copy) @@ -41,7 +41,7 @@ end def inspect - @value + @value.inspect end def alpha? From ryand-ruby at zenspider.com Wed Aug 19 18:36:01 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 19 Aug 2009 15:36:01 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation Message-ID: I just added this to Version: > def assert_spermy expect, version > assert_equal expect, > Gem::Version.new(version).spermy_recommendation > end > > def test_spermy_recommendation > assert_spermy "~> 1.0", "1" > assert_spermy "~> 1.0", "1.0" > assert_spermy "~> 1.2", "1.2" > assert_spermy "~> 1.2", "1.2.0" > assert_spermy "~> 1.2", "1.2.3" > assert_spermy "~> 1.2", "1.2.3.a.4" > end The idea being that tools like hoe and rubygems can use it to help recommend better dependency specifiers. Right now in hoe if you don't have a version specifier on a dependency it tells you that you should at least add "> 0" and this would offer a vast improvement. Eventually I'd like to push rubygems into if not deprecating then at least warning against using ">=" specifiers (when used alone). See also: http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html I also added part of that blog post to the doco on version and pointed to it from the top level rdoc. From djberg96 at gmail.com Wed Aug 19 19:48:51 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 19 Aug 2009 17:48:51 -0600 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: References: Message-ID: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> On Wed, Aug 19, 2009 at 4:36 PM, Ryan Davis wrote: > I just added this to Version: > >> ?def assert_spermy expect, version >> ? ?assert_equal expect, Gem::Version.new(version).spermy_recommendation >> ?end >> >> ?def test_spermy_recommendation >> ? ?assert_spermy "~> 1.0", "1" >> ? ?assert_spermy "~> 1.0", "1.0" >> ? ?assert_spermy "~> 1.2", "1.2" >> ? ?assert_spermy "~> 1.2", "1.2.0" >> ? ?assert_spermy "~> 1.2", "1.2.3" >> ? ?assert_spermy "~> 1.2", "1.2.3.a.4" >> ?end > > The idea being that tools like hoe and rubygems can use it to help recommend > better dependency specifiers. Right now in hoe if you don't have a version > specifier on a dependency it tells you that you should at least add "> 0" > and this would offer a vast improvement. Eventually I'd like to push > rubygems into ?if not deprecating then at least warning against using ">=" > specifiers (when used alone). > > See also: > http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html > > I also added part of that blog post to the doco on version and pointed to it > from the top level rdoc. Good idea, but I can't say I like the name much. I'd like to see it changed to something like "assert_version_range". Regards, Dan From ryand-ruby at zenspider.com Wed Aug 19 20:14:33 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 19 Aug 2009 17:14:33 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> Message-ID: <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> On Aug 19, 2009, at 16:48 , Daniel Berger wrote: > On Wed, Aug 19, 2009 at 4:36 PM, Ryan Davis ruby at zenspider.com> wrote: >> I just added this to Version: >> >>> def assert_spermy expect, version >>> assert_equal expect, >>> Gem::Version.new(version).spermy_recommendation >>> end >>> >>> def test_spermy_recommendation >>> assert_spermy "~> 1.0", "1" >>> assert_spermy "~> 1.0", "1.0" >>> assert_spermy "~> 1.2", "1.2" >>> assert_spermy "~> 1.2", "1.2.0" >>> assert_spermy "~> 1.2", "1.2.3" >>> assert_spermy "~> 1.2", "1.2.3.a.4" >>> end >> >> The idea being that tools like hoe and rubygems can use it to help >> recommend >> better dependency specifiers. Right now in hoe if you don't have a >> version >> specifier on a dependency it tells you that you should at least add >> "> 0" >> and this would offer a vast improvement. Eventually I'd like to push >> rubygems into if not deprecating then at least warning against >> using ">=" >> specifiers (when used alone). >> >> See also: >> http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html >> >> I also added part of that blog post to the doco on version and >> pointed to it >> from the top level rdoc. > > Good idea, but I can't say I like the name much. I'd like to see it > changed to something like "assert_version_range". I think you missed the point. assert_spermy is there to illustrate the API change to Version. I refactored the tests to be readable. From thewoolleyman at gmail.com Wed Aug 19 21:15:34 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Aug 2009 18:15:34 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> Message-ID: On Wed, Aug 19, 2009 at 5:14 PM, Ryan Davis wrote: > I think you missed the point. assert_spermy is there to illustrate the API > change to Version. I refactored the tests to be readable. I have no idea what you are talking about, or how sperm references are relevant to this patch. I think you need to err more on the side of clearer, more verbose explanations ("mentarbation" to use your term). Case in point with Hoe: http://rubyforge.org/tracker/index.php?func=detail&aid=26762&group_id=1513&atid=5923 Still waiting on a response for that, BTW. I was honestly trying to help there, and did above and beyond due diligence IMHO. Getting repeatedly blown off with cryptic terse rejections when trying to help patch your broken project is pretty lame. Thanks, -- Chad From djberg96 at gmail.com Wed Aug 19 22:26:22 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 19 Aug 2009 20:26:22 -0600 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> Message-ID: <4A8CB44E.6080304@gmail.com> Ryan Davis wrote: > > On Aug 19, 2009, at 16:48 , Daniel Berger wrote: > >> On Wed, Aug 19, 2009 at 4:36 PM, Ryan Davis >> wrote: >>> I just added this to Version: >>> >>>> def assert_spermy expect, version >>>> assert_equal expect, Gem::Version.new(version).spermy_recommendation >>>> end >>>> >>>> def test_spermy_recommendation >>>> assert_spermy "~> 1.0", "1" >>>> assert_spermy "~> 1.0", "1.0" >>>> assert_spermy "~> 1.2", "1.2" >>>> assert_spermy "~> 1.2", "1.2.0" >>>> assert_spermy "~> 1.2", "1.2.3" >>>> assert_spermy "~> 1.2", "1.2.3.a.4" >>>> end >>> >>> The idea being that tools like hoe and rubygems can use it to help >>> recommend >>> better dependency specifiers. Right now in hoe if you don't have a >>> version >>> specifier on a dependency it tells you that you should at least add >>> "> 0" >>> and this would offer a vast improvement. Eventually I'd like to push >>> rubygems into if not deprecating then at least warning against using >>> ">=" >>> specifiers (when used alone). >>> >>> See also: >>> http://blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html >>> >>> I also added part of that blog post to the doco on version and >>> pointed to it >>> from the top level rdoc. >> >> Good idea, but I can't say I like the name much. I'd like to see it >> changed to something like "assert_version_range". > > I think you missed the point. assert_spermy is there to illustrate the > API change to Version. I refactored the tests to be readable. I understand what you're doing. I just don't like the name "assert_spermy". Can we please change it? Regards, Dan From drbrain at segment7.net Wed Aug 19 23:21:43 2009 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Aug 2009 20:21:43 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> Message-ID: <71B96E07-D0FF-457B-B3FB-49CBEB8143AA@segment7.net> On Aug 19, 2009, at 18:15, Chad Woolley wrote: > Case in point with Hoe: > > http://rubyforge.org/tracker/index.php?func=detail&aid=26762&group_id=1513&atid=5923 > > Still waiting on a response for that, BTW. I was honestly trying to > help there, and did above and beyond due diligence IMHO. Getting > repeatedly blown off with cryptic terse rejections when trying to help > patch your broken project is pretty lame. I don't see what this has to do with RubyGems. Can you move such conflicts to a more appropriate place? From ryand-ruby at zenspider.com Wed Aug 19 23:42:35 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 19 Aug 2009 20:42:35 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <4A8CB44E.6080304@gmail.com> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> <4A8CB44E.6080304@gmail.com> Message-ID: <3EF5B555-E23B-4449-ABCA-81164C84B540@zenspider.com> On Aug 19, 2009, at 19:26 , Daniel Berger wrote: > I understand what you're doing. I just don't like the name > "assert_spermy". Can we please change it? to be clear: you want to change assert_spermy, but NOT spermy_recommendation?!?! do you see my confusion? From noreply at rubyforge.org Thu Aug 20 01:18:48 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Aug 2009 01:18:48 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ] Gem::Specification.hash can cause to_yaml RangeError Message-ID: <20090820051848.23C8F1858205@rubyforge.org> Bugs item #26958, was opened at 2009-08-20 05:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Chiang (prosperity) Assigned to: Nobody (None) Summary: Gem::Specification.hash can cause to_yaml RangeError Initial Comment: Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML. This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix. (see http://redmine.ruby-lang.org/issues/show/1883) ========================== RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - 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/simonchiang/.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 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 From djberg96 at gmail.com Thu Aug 20 08:03:04 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 20 Aug 2009 06:03:04 -0600 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <3EF5B555-E23B-4449-ABCA-81164C84B540@zenspider.com> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> <4A8CB44E.6080304@gmail.com> <3EF5B555-E23B-4449-ABCA-81164C84B540@zenspider.com> Message-ID: <6037b70c0908200503q134a2ea1ic0a89950f4305200@mail.gmail.com> On Wed, Aug 19, 2009 at 9:42 PM, Ryan Davis wrote: > > On Aug 19, 2009, at 19:26 , Daniel Berger wrote: > >> I understand what you're doing. I just don't like the name >> "assert_spermy". Can we please change it? > > to be clear: > > ?you want to change assert_spermy, but NOT spermy_recommendation?!?! > > do you see my confusion? I would like them both changed please. Regards, Dan From noreply at rubyforge.org Thu Aug 20 13:55:31 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Aug 2009 13:55:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ] Gem::Specification.hash can cause to_yaml RangeError Message-ID: <20090820175531.9C4A9185825D@rubyforge.org> Bugs item #26958, was opened at 2009-08-19 22:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Chiang (prosperity) Assigned to: Nobody (None) Summary: Gem::Specification.hash can cause to_yaml RangeError Initial Comment: Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML. This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix. (see http://redmine.ruby-lang.org/issues/show/1883) ========================== RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - 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/simonchiang/.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-08-20 10:55 Message: This looks reasonable and is reproducible, but I'm not sure what is dependent upon the current implementation of hash. Maybe someone else can weigh in... Regardless, can you please submit this as a proper patch, with your failing tests added to the appropriate file (test_gem_specification.rb) - and, of course, ensure nothing else in the test suite breaks? Thanks, -- Chad ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 From noreply at rubyforge.org Thu Aug 20 16:48:18 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Aug 2009 16:48:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ] Gem::Specification.hash can cause to_yaml RangeError Message-ID: <20090820204818.60B4B1858270@rubyforge.org> Bugs item #26958, was opened at 2009-08-19 22:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Chiang (prosperity) Assigned to: Nobody (None) Summary: Gem::Specification.hash can cause to_yaml RangeError Initial Comment: Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML. This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix. (see http://redmine.ruby-lang.org/issues/show/1883) ========================== RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - 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/simonchiang/.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: Eric Hodel (drbrain) Date: 2009-08-20 13:48 Message: Why are you converting specs to YAML in the first place? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-08-20 10:55 Message: This looks reasonable and is reproducible, but I'm not sure what is dependent upon the current implementation of hash. Maybe someone else can weigh in... Regardless, can you please submit this as a proper patch, with your failing tests added to the appropriate file (test_gem_specification.rb) - and, of course, ensure nothing else in the test suite breaks? Thanks, -- Chad ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 From noreply at rubyforge.org Thu Aug 20 18:25:18 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Aug 2009 18:25:18 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ] Gem::Specification.hash can cause to_yaml RangeError Message-ID: <20090820222518.9CE231858272@rubyforge.org> Bugs item #26958, was opened at 2009-08-20 05:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Chiang (prosperity) Assigned to: Nobody (None) Summary: Gem::Specification.hash can cause to_yaml RangeError Initial Comment: Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML. This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix. (see http://redmine.ruby-lang.org/issues/show/1883) ========================== RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - 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/simonchiang/.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: Simon Chiang (prosperity) Date: 2009-08-20 22:25 Message: @chad Ok, great. I'll work a little something up when I get a free minute. @eric A framework I'm working on (http://tap.rubyforge.org) discovers resources within gems and my environment ends up referencing an array of specs. At some point I dumped the environment and found the error. Honestly, it's just something I stumbled on. I don't actually have a specific need to convert the specs to YAML. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-08-20 20:48 Message: Why are you converting specs to YAML in the first place? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-08-20 17:55 Message: This looks reasonable and is reproducible, but I'm not sure what is dependent upon the current implementation of hash. Maybe someone else can weigh in... Regardless, can you please submit this as a proper patch, with your failing tests added to the appropriate file (test_gem_specification.rb) - and, of course, ensure nothing else in the test suite breaks? Thanks, -- Chad ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 From noreply at rubyforge.org Thu Aug 20 18:54:26 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 20 Aug 2009 18:54:26 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26958 ] Gem::Specification.hash can cause to_yaml RangeError Message-ID: <20090820225426.2C8EA1779936@rubyforge.org> Bugs item #26958, was opened at 2009-08-19 22:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Simon Chiang (prosperity) Assigned to: Nobody (None) Summary: Gem::Specification.hash can cause to_yaml RangeError Initial Comment: Array.hash for objects do not produce a Fixnum hash will blow up. Gem::Specification often produces a Bignum and this prevents an array of specifications from being converted to YAML. This issue (which is really a ruby issue) will be fixed in a future release but I thought you might like to know in case you wanted to patch RubyGems for versions prior to the fix. (see http://redmine.ruby-lang.org/issues/show/1883) ========================== RubyGems Environment: - RUBYGEMS VERSION: 1.3.1 - 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/simonchiang/.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: Eric Hodel (drbrain) Date: 2009-08-20 15:54 Message: You probably wanted to use pp then. ---------------------------------------------------------------------- Comment By: Simon Chiang (prosperity) Date: 2009-08-20 15:25 Message: @chad Ok, great. I'll work a little something up when I get a free minute. @eric A framework I'm working on (http://tap.rubyforge.org) discovers resources within gems and my environment ends up referencing an array of specs. At some point I dumped the environment and found the error. Honestly, it's just something I stumbled on. I don't actually have a specific need to convert the specs to YAML. ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-08-20 13:48 Message: Why are you converting specs to YAML in the first place? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-08-20 10:55 Message: This looks reasonable and is reproducible, but I'm not sure what is dependent upon the current implementation of hash. Maybe someone else can weigh in... Regardless, can you please submit this as a proper patch, with your failing tests added to the appropriate file (test_gem_specification.rb) - and, of course, ensure nothing else in the test suite breaks? Thanks, -- Chad ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26958&group_id=126 From thewoolleyman at gmail.com Fri Aug 21 03:39:25 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 21 Aug 2009 00:39:25 -0700 Subject: [Rubygems-developers] Added Gem::Version#spermy_recommendation In-Reply-To: <71B96E07-D0FF-457B-B3FB-49CBEB8143AA@segment7.net> References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> <71B96E07-D0FF-457B-B3FB-49CBEB8143AA@segment7.net> Message-ID: On Wed, Aug 19, 2009 at 8:21 PM, Eric Hodel wrote: >> http://rubyforge.org/tracker/index.php?func=detail&aid=26762&group_id=1513&atid=5923 > > I don't see what this has to do with RubyGems. ?Can you move such conflicts > to a more appropriate place? This bug is related to Rubygems. Ryan introduced Hoe to Rubygems, which broke the CI build by adding unspecified dependencies. I let him know, and he ignored it. So, I fixed it mysqlf by adding automated dependency installation. You reverted that (working) change, and replaced it with a call to Hoe's dependency installation mechanism (which did NOT work). I submitted this patch to Hoe which made it work. Ryan rejected the patch, asking for more info. I replied and reopened with more information. He rejected again with a cryptic message, and no indication if it was actually was or would be fixed. I asked him to clarify, or if I could help, and he has continued to ignore it. I've since worked around it, but the root problem remains unaddressed. This illustrates the often rude and dictatorial tone (and now, immature and persistent sexual references) on this list, and refusal to respond to valid technical criticism of questionable code and policies. Perhaps others tolerate this sort of behavior on a public development list, but I'd rather not. I believe ignoring it encourages more of the same, so I will keep pointing it out. Again, I have the utmost respect for your incredible and critical contributions to this project, but there's more to an open source project than code. Thanks, -- Chad From noreply at rubyforge.org Fri Aug 21 04:20:04 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 21 Aug 2009 04:20:04 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26892 ] Gem::Ext::RakeBuilder can't execute Rake on JRuby if Rake gem isn't installed Message-ID: <20090821082004.901241858111@rubyforge.org> Bugs item #26892, was opened at 2009-08-07 19:16 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126 Category: `gem install` command (extensions) Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jake Douglas (yakischloba) Assigned to: Nobody (None) Summary: Gem::Ext::RakeBuilder can't execute Rake on JRuby if Rake gem isn't installed Initial Comment: On JRuby, when installing a gem that has 'extensions = "Rakefile"' as part of it's specification, Gem::Ext::RakeBuilder tries to run 'jrake' which does not exist in JRuby. This occurs when the actual Rake gem is not installed. This can be worked around by requiring the rake gem as a dependency, but the desired behavior would be for it to find the rake that is bundled with JRuby. This line, in the "1.8" compatible rubygems, is the culprit: cmd = ENV['rake'] || "#{Gem.ruby} -rubygems #{Gem.bin_path('rake')}" rescue Gem.default_exec_format % 'rake' In the "1.9" rubygems, its like this: cmd = ENV['rake'] || 'rake' which probably wouldn't work either unless JRuby is the default Ruby or the JRuby rake points it to the jruby executable. ---------------------------------------------------------------------- >Comment By: James Tucker (raggi) Date: 2009-08-21 08:20 Message: This is a problem because of inconsistent policy. I strongly recommend "wontfix" until this is actually sat down and thought about some more. Gem.default_exec_format should really be the default so that we don't clobber multiple interpreters all the time. As more *applications* are available in the ruby space, this will become more common on open source platforms where apps are installed by package manager. The special casing of system and random selection of executable names under jruby makes it extremely hard to get this right in all situations, and the above at least attempts to make it work when things are installed by gem, which is the highest level of reliability I can guarantee at this time. Falling back to 'rake' on platforms where it is going to launch MRI has very strange impacts. I would love to have a non-bikeshed discussion with everyone involved on this topic - that includes Charlie, Eric, myself and if we can get it, Matz. The only reason I would like matz to chime in, is that this is also related to the bundling of rake, and the lack of correct binary prefix and postfix discovery in the main MRI packages. What we cannot do is keep making changes that fix one specific side of the problem, otherwise this will never go away. I also suspect that someone is going to have to suck it up and suffer a change, in order to reach consistency. Sadly I feel it is likely this will be the jruby project, and whilst I don't want to force that on them, I would like them to present some kind of reasonable alternative if they have one. I do not believe special casing system more will solve this issue. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26892&group_id=126 From jim.weirich at gmail.com Fri Aug 21 09:34:50 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 21 Aug 2009 09:34:50 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' Message-ID: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> I know some work was put into making require 'rubygems' as lightweight as possible, so I was a little surprised to find that requiring rubygems into my program will also load any gem plugins that might be defined. I thought the plugins were for the gem command, not for general rubygems usage. Demonstration: $ irb irb(main):001:0> URL NameError: uninitialized constant URL from (irb):1 irb(main):002:0> require 'rubygems' => true irb(main):003:0> URL => "http://gemcutter.org" URL is defined in the gemcutter gem's gem plugin so that's a good indication that gems plugins are loaded with require rubygems. (And yes, I consider a top level, non-namespaced constant to be a bug and have submitted a patch to gemcutter to fix that). Comments. Is this intended, or something that slipped through the cracks. -- -- Jim Weirich -- jim.weirich at gmail.com From jftucker at gmail.com Fri Aug 21 09:54:42 2009 From: jftucker at gmail.com (James Tucker) Date: Fri, 21 Aug 2009 14:54:42 +0100 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> Message-ID: On 21 Aug 2009, at 14:34, Jim Weirich wrote: > I know some work was put into making require 'rubygems' as > lightweight as possible, so I was a little surprised to find that > requiring rubygems into my program will also load any gem plugins > that might be defined. I thought the plugins were for the gem > command, not for general rubygems usage. 1.9? > > Demonstration: > > $ irb > irb(main):001:0> URL > NameError: uninitialized constant URL > from (irb):1 > irb(main):002:0> require 'rubygems' > => true > irb(main):003:0> URL > => "http://gemcutter.org" > > URL is defined in the gemcutter gem's gem plugin so that's a good > indication that gems plugins are loaded with require rubygems. > > (And yes, I consider a top level, non-namespaced constant to be a > bug and have submitted a patch to gemcutter to fix that). > > Comments. Is this intended, or something that slipped through the > cracks. > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From jim.weirich at gmail.com Fri Aug 21 10:30:38 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 21 Aug 2009 10:30:38 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> Message-ID: On Aug 21, 2009, at 9:54 AM, James Tucker wrote: > On 21 Aug 2009, at 14:34, Jim Weirich wrote: > >> I know some work was put into making require 'rubygems' as >> lightweight as possible, so I was a little surprised to find that >> requiring rubygems into my program will also load any gem plugins >> that might be defined. I thought the plugins were for the gem >> command, not for general rubygems usage. > > 1.9? Yes, I see this behavior on 1.8 only. -- -- Jim Weirich -- jim.weirich at gmail.com From ryand-ruby at zenspider.com Fri Aug 21 14:25:22 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 21 Aug 2009 11:25:22 -0700 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> Message-ID: <6314CEE4-0735-4BDD-8434-51415C6C7F12@zenspider.com> On Aug 21, 2009, at 06:34 , Jim Weirich wrote: > Comments. Is this intended, or something that slipped through the > cracks. not intended. I've discussed this aspect of plugins with eric before. we'll look at it after lunch. From mojombo at gmail.com Thu Aug 20 14:45:34 2009 From: mojombo at gmail.com (Tom Werner) Date: Thu, 20 Aug 2009 11:45:34 -0700 Subject: [Rubygems-developers] Namespaces for Rubygems Message-ID: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> We've been thinking a lot about our gem strategy here at GitHub, and after a discussion with Yehuda a number of weeks ago, I'd like to propose a possible solution that describes how GitHub gems and Rubyforge gems can live together in peace. The solution is to add the concept of namespaces to the gem server index. For example, if I publish my Jekyll gem on GitHub, it would be installed via Rubygems with the following invocation: gem install mojombo/jekyll This command would look in each source, in order, for a gem with the 'mojombo' namespace and the 'jekyll' name. The main benefit here is that the gem would be installed as just 'jekyll' instead of 'mojombo-jekyll' as in the current situation. This elegantly solves the problem that stems from a gemspec declaring 'jekyll' as a dependency, and even though the 'mojombo-jekyll' gem is installed, it is not detected as satisfying the dependency even though, logically, the user expects that it should. This also solves the problem of gem name collisions between Rubyforge and GitHub such as 'net-ssh'. To maintain backwards compatibility, Rubygems would still support un-namespaced gems in exactly the same manner that it does today. Rubyforge wouldn't need to use the namespace feature, but GitHub would, and in doing so, become a much better participant in the Rubygems world. Tom -- Tom Preston-Werner GitHub Cofounder http://tom.preston-werner.com github.com/mojombo From rogerdpack2 at gmail.com Tue Aug 18 12:38:00 2009 From: rogerdpack2 at gmail.com (Roger Pack) Date: Tue, 18 Aug 2009 10:38:00 -0600 Subject: [Rubygems-developers] gem uninstall with multiple versions doesn't uninstall binaries Message-ID: <87d974fd0908180938n45aa0c79y7ee455a982bc0df6@mail.gmail.com> Here's what happened recently... C:\installs\ruby191p243\bin>gem uninstall ruby2ruby Select gem to uninstall: 1. ruby2ruby-1.1.9 2. ruby2ruby-1.2.4 3. All versions > 3 You have requested to uninstall the gem: ruby2ruby-1.1.9 rogerdpack-arguments-0.4.7.9 depends on [ruby2ruby (= 1.1.9)] rogerdpack-desc_method-0.1.3 depends on [ruby2ruby (>= 0)] If you remove this gems, one or more dependencies will not be met. Continue with Uninstall? [Yn] y Successfully uninstalled ruby2ruby-1.1.9 Successfully uninstalled ruby2ruby-1.2.4 C:\installs\ruby191p243\bin>ls r2r_show r2r_show.bat rdoc.bat ... appears that uninstall them did not remove the binaries? Also as a follow-up question, I've noticed that if I install two gems that use the same binary name, on uninstall both of them prompt me to uninstall the executables--even if they don't exist--is this also expected, or a bug? Just wondering. Thanks much! -r From rogerdpack2 at gmail.com Tue Aug 18 12:39:43 2009 From: rogerdpack2 at gmail.com (Roger Pack) Date: Tue, 18 Aug 2009 10:39:43 -0600 Subject: [Rubygems-developers] doesn't seem to install all dependencies right? Message-ID: <87d974fd0908180939se3de97ra82d2a71e5cf8bf@mail.gmail.com> Question. Currently I have gems.github.com in my gem source, then run this C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method ERROR: Error installing rogerdpack-desc_method: ruby2ruby requires ruby_parser (~> 2.0, runtime) C:\installs\ruby191p243\bin>gem install ruby_parser Successfully installed ruby_parser-2.0.3 1 gem installed C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method ERROR: Error installing rogerdpack-desc_method: rogerdpack-arguments requires ruby2ruby (= 1.1.9, runtime) C:\installs\ruby191p243\bin>gem install ruby2ruby -v1.1.9 Successfully installed rubyforge-1.0.4 Successfully installed rake-0.8.7 Successfully installed hoe-2.3.3 Successfully installed ruby2ruby-1.1.9 4 gems installed C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method Successfully installed rogerdpack-arguments-0.4.7.9 Successfully installed rogerdpack-sane-0.1.2 Successfully installed rogerdpack-desc_method-0.1.3 3 gems installed Is this expected? Thanks. -r From nick at quaran.to Fri Aug 21 09:43:54 2009 From: nick at quaran.to (Nick Quaranto) Date: Fri, 21 Aug 2009 09:43:54 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> Message-ID: That constant should definitely be namespaced, I'll get a new version out today that doesn't do that. I have seen this behavior and it's made testing the gemcutter gem hard, since I have to uninstall all local versions in order to get my working copy loaded. -Nick On Fri, Aug 21, 2009 at 9:34 AM, Jim Weirich wrote: > I know some work was put into making require 'rubygems' as lightweight as > possible, so I was a little surprised to find that requiring rubygems into > my program will also load any gem plugins that might be defined. I thought > the plugins were for the gem command, not for general rubygems usage. > > Demonstration: > > $ irb > irb(main):001:0> URL > NameError: uninitialized constant URL > from (irb):1 > irb(main):002:0> require 'rubygems' > => true > irb(main):003:0> URL > => "http://gemcutter.org" > > URL is defined in the gemcutter gem's gem plugin so that's a good > indication that gems plugins are loaded with require rubygems. > > (And yes, I consider a top level, non-namespaced constant to be a bug and > have submitted a patch to gemcutter to fix that). > > Comments. Is this intended, or something that slipped through the cracks. > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jim.weirich at gmail.com Fri Aug 21 15:02:14 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 21 Aug 2009 15:02:14 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> Message-ID: <8EBBBC86-6DB8-4C1F-9A05-F0632FCD5B15@gmail.com> On Aug 21, 2009, at 9:43 AM, Nick Quaranto wrote: > That constant should definitely be namespaced, I'll get a new > version out > today that doesn't do that. I have seen this behavior and it's made > testing > the gemcutter gem hard, since I have to uninstall all local versions > in > order to get my working copy loaded. Nick, I sent you a pull request on github. -- -- Jim Weirich -- jim.weirich at gmail.com From luislavena at gmail.com Fri Aug 21 15:13:50 2009 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 21 Aug 2009 16:13:50 -0300 Subject: [Rubygems-developers] doesn't seem to install all dependencies right? In-Reply-To: <87d974fd0908180939se3de97ra82d2a71e5cf8bf@mail.gmail.com> References: <87d974fd0908180939se3de97ra82d2a71e5cf8bf@mail.gmail.com> Message-ID: <71166b3b0908211213y7f44d9dat9f863671f1ba763f@mail.gmail.com> On Tue, Aug 18, 2009 at 1:39 PM, Roger Pack wrote: > Question. > > Currently I have gems.github.com in my gem source, then run this > > C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method > ERROR: ?Error installing rogerdpack-desc_method: > ? ? ? ?ruby2ruby requires ruby_parser (~> 2.0, runtime) > > C:\installs\ruby191p243\bin>gem install ruby_parser > Successfully installed ruby_parser-2.0.3 > 1 gem installed > > C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method > ERROR: ?Error installing rogerdpack-desc_method: > ? ? ? ?rogerdpack-arguments requires ruby2ruby (= 1.1.9, runtime) > > C:\installs\ruby191p243\bin>gem install ruby2ruby -v1.1.9 > Successfully installed rubyforge-1.0.4 > Successfully installed rake-0.8.7 > Successfully installed hoe-2.3.3 > Successfully installed ruby2ruby-1.1.9 > 4 gems installed > > C:\installs\ruby191p243\bin>gem install rogerdpack-desc_method > Successfully installed rogerdpack-arguments-0.4.7.9 > Successfully installed rogerdpack-sane-0.1.2 > Successfully installed rogerdpack-desc_method-0.1.3 > 3 gems installed > > Is this expected? Cross sources dependency resolving is not implemented. Eric would say: Patches are welcome! :D -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From jbarnette at gmail.com Fri Aug 21 16:29:16 2009 From: jbarnette at gmail.com (John Barnette) Date: Fri, 21 Aug 2009 13:29:16 -0700 Subject: [Rubygems-developers] Namespaces for Rubygems In-Reply-To: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> References: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> Message-ID: <08B3545A-AC39-4582-9FAE-92925A97845A@gmail.com> Hey Tom, On Aug 20, 2009, at 11:45 AM, Tom Werner wrote: > This command would look in each source, in order, for a gem with the > 'mojombo' namespace and the 'jekyll' name. The main benefit here is > that the > gem would be installed as just 'jekyll' instead of 'mojombo-jekyll' > as in > the current situation. This elegantly solves the problem that stems > from a > gemspec declaring 'jekyll' as a dependency, and even though the > 'mojombo-jekyll' gem is installed, it is not detected as satisfying > the > dependency even though, logically, the user expects that it should. > This > also solves the problem of gem name collisions between Rubyforge and > GitHub > such as 'net-ssh'. I'll try and respond to this in more detail later, but one quick note as I read it: What happens with gem updates? If the gem is installed as "jekyll," how would RubyGems know where to pull updates? Are you thinking about a change in the gemspec? ~ j. > > To maintain backwards compatibility, Rubygems would still support > un-namespaced gems in exactly the same manner that it does today. > Rubyforge > wouldn't need to use the namespace feature, but GitHub would, and in > doing > so, become a much better participant in the Rubygems world. > > Tom > > -- > Tom Preston-Werner > GitHub Cofounder > http://tom.preston-werner.com > github.com/mojombo > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From noreply at rubyforge.org Fri Aug 21 19:04:33 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 21 Aug 2009 19:04:33 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26840 ] Computed hash in dependency.rb and specification.rb is sometimes too large. Message-ID: <20090821230433.9F1951D780F2@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: Open 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 ryand-ruby at zenspider.com Fri Aug 21 19:29:29 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri, 21 Aug 2009 16:29:29 -0700 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <6314CEE4-0735-4BDD-8434-51415C6C7F12@zenspider.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> <6314CEE4-0735-4BDD-8434-51415C6C7F12@zenspider.com> Message-ID: <4B1F397F-2FF2-40A2-9273-5E47D8F8346F@zenspider.com> On Aug 21, 2009, at 11:25 , Ryan Davis wrote: > > On Aug 21, 2009, at 06:34 , Jim Weirich wrote: > >> Comments. Is this intended, or something that slipped through the >> cracks. > > not intended. I've discussed this aspect of plugins with eric > before. we'll look at it after lunch. Apparently I was wrong and the behavior is intended. I think it is wrong (but in this case I also think this is a case of bad code as well). I think that gem plugin activation should be explicit. From jim.weirich at gmail.com Fri Aug 21 20:17:17 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 21 Aug 2009 20:17:17 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <4B1F397F-2FF2-40A2-9273-5E47D8F8346F@zenspider.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> <6314CEE4-0735-4BDD-8434-51415C6C7F12@zenspider.com> <4B1F397F-2FF2-40A2-9273-5E47D8F8346F@zenspider.com> Message-ID: <781E630F-17A4-4669-B74B-BCC0B3D305D6@gmail.com> On Aug 21, 2009, at 7:29 PM, Ryan Davis wrote: > Apparently I was wrong and the behavior is intended. I think it is > wrong (but in this case I also think this is a case of bad code as > well). I think that gem plugin activation should be explicit. Really? What is the intended purpose? -- -- Jim Weirich -- jim.weirich at gmail.com From ryand-ruby at zenspider.com Sat Aug 22 03:00:24 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sat, 22 Aug 2009 00:00:24 -0700 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <781E630F-17A4-4669-B74B-BCC0B3D305D6@gmail.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> <6314CEE4-0735-4BDD-8434-51415C6C7F12@zenspider.com> <4B1F397F-2FF2-40A2-9273-5E47D8F8346F@zenspider.com> <781E630F-17A4-4669-B74B-BCC0B3D305D6@gmail.com> Message-ID: On Aug 21, 2009, at 17:17 , Jim Weirich wrote: > On Aug 21, 2009, at 7:29 PM, Ryan Davis wrote: > >> Apparently I was wrong and the behavior is intended. I think it is >> wrong (but in this case I also think this is a case of bad code as >> well). I think that gem plugin activation should be explicit. > > Really? What is the intended purpose? Eric should weigh in on this as it is his design... It had something to do with install hooks and the like being runnable from someone else's script, not just `gem install`. But I'm paraphrasing heavily. I think that's a good goal, but I would rather see plugin loading be made explicit. If you're writing a script to interact with rubygems (the system), it is already on you to use it correctly so you might as well be the one to load the plugins. If you're just using rubygems (aka require), it shouldn't have to load plugins. From drbrain at segment7.net Mon Aug 24 18:59:40 2009 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 24 Aug 2009 15:59:40 -0700 Subject: [Rubygems-developers] Namespaces for Rubygems In-Reply-To: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> References: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> Message-ID: <36FE094E-AF6D-462A-A8C2-3F24768210AB@segment7.net> On Aug 20, 2009, at 11:45, Tom Werner wrote: > We've been thinking a lot about our gem strategy here at GitHub, and > after a > discussion with Yehuda a number of weeks ago, I'd like to propose a > possible > solution that describes how GitHub gems and Rubyforge gems can live > together > in peace. I'll read your solution and comment on it later, but have you looked at my proposal: http://blog.segment7.net/articles/2009/02/04/a-rubygems-github-proposal From drbrain at segment7.net Mon Aug 24 19:18:05 2009 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 24 Aug 2009 16:18:05 -0700 Subject: [Rubygems-developers] gem check_extra_deps, dictatorship (Was: Added Gem::Version#spermy_recommendation) In-Reply-To: References: <6037b70c0908191648t410cfd67jb91527b135c97f5@mail.gmail.com> <25C62AEC-79E1-48FC-A3D4-B30261569542@zenspider.com> <71B96E07-D0FF-457B-B3FB-49CBEB8143AA@segment7.net> Message-ID: <55EFFF85-3209-44A2-BA30-43833D7E63F0@segment7.net> On Aug 21, 2009, at 00:39, Chad Woolley wrote: > On Wed, Aug 19, 2009 at 8:21 PM, Eric Hodel > wrote: >>> http://rubyforge.org/tracker/index.php?func=detail&aid=26762&group_id=1513&atid=5923 >> >> I don't see what this has to do with RubyGems. Can you move such >> conflicts >> to a more appropriate place? > > This bug is related to Rubygems. Ryan introduced Hoe to Rubygems, > which broke the CI build by adding unspecified dependencies. I let > him know, and he ignored it. So, I fixed it mysqlf by adding > automated dependency installation. You reverted that (working) > change, and replaced it with a call to Hoe's dependency installation > mechanism (which did NOT work). WFM: $ rake check_extra_deps (in /Users/drbrain/Work/svn/rubygems/trunk) sudo gem install builder --version '~> 2.1' Successfully installed builder-2.1.2 1 gem installed [RDoc] $ gem list hoe$ *** LOCAL GEMS *** hoe (2.3.3) $ > This illustrates the often rude and dictatorial tone (and now, > immature and persistent sexual references) on this list, and refusal > to respond to valid technical criticism of questionable code and > policies. Perhaps others tolerate this sort of behavior on a public > development list, but I'd rather not. I believe ignoring it > encourages more of the same, so I will keep pointing it out. I don't get paid to work on RubyGems. I've never been paid to work on RubyGems. I believe I may have gotten a beer or two in relation to my work on RubyGems, but to my recollection never was any beer expressly stated to be in payment for my RubyGems work. If I'm rude or dictatorial, sorry, I'm not paid to be nice. I'd like to have RubyGems be of the highest possible quality, and sometimes technical problems are intertwined with usability, backwards compatibility, etc. Sometimes I just don't get around to it or forget about it because RubyGems isn't my day job. > Again, I have the utmost respect for your incredible and critical > contributions to this project, but there's more to an open source > project than code. There's more to it than technical merit and unfailing niceness too. From noreply at rubyforge.org Wed Aug 26 16:54:31 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 16:54:31 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname --remote will fail if gemname is in current directory Message-ID: <20090826205431.E45C318581E4@rubyforge.org> Bugs item #26109, was opened at 2009-06-03 00:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: ara howard (ahoward) Assigned to: Nobody (None) Summary: gem install gemname --remote will fail if gemname is in current directory Initial Comment: gem install gemname --remote will prefer a gem in the current directory. seems like --remote should *never* do *anything* local? ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 22:54 Message: I can not reproduce this issue as a "preference". Rubygems appears to do remote as requested with requested gem in pwd. In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /home/nihildeb/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 From noreply at rubyforge.org Wed Aug 26 17:36:20 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 17:36:20 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090826213620.55E53197827D@rubyforge.org> Bugs item #25816, was opened at 2009-05-07 04: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: Nick Hildebrant (nihildeb) Date: 2009-08-26 23: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-07 04: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 nick at quaran.to Fri Aug 21 15:37:11 2009 From: nick at quaran.to (Nick Quaranto) Date: Fri, 21 Aug 2009 15:37:11 -0400 Subject: [Rubygems-developers] Plug-ins loaded with require 'rubygems' In-Reply-To: <8EBBBC86-6DB8-4C1F-9A05-F0632FCD5B15@gmail.com> References: <46EDE35F-FFBA-4342-BDEC-7B54D97E5CD7@gmail.com> <8EBBBC86-6DB8-4C1F-9A05-F0632FCD5B15@gmail.com> Message-ID: Thanks Jim, looks like David already merged it in, I'm planning on moving around the gem code a bit internally tonight and then getting a new version out that doesn't stomp all over constants like a whiny kid wanting ice cream. As for gem plugins in general, what's the best way to get around this in the future? Perhaps for testing we can have something like GEM_LOAD_PLUGINS = false require 'rubygems' # No plugins are loaded Or better yet, only load plugins when gem commands are run and not when rubygems is required. Thoughts? -Nick On Fri, Aug 21, 2009 at 3:02 PM, Jim Weirich wrote: > > On Aug 21, 2009, at 9:43 AM, Nick Quaranto wrote: > > That constant should definitely be namespaced, I'll get a new version out >> today that doesn't do that. I have seen this behavior and it's made >> testing >> the gemcutter gem hard, since I have to uninstall all local versions in >> order to get my working copy loaded. >> > > Nick, I sent you a pull request on github. > > > -- > -- Jim Weirich > -- jim.weirich at gmail.com > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From mojombo at gmail.com Fri Aug 21 19:35:50 2009 From: mojombo at gmail.com (Tom Werner) Date: Fri, 21 Aug 2009 16:35:50 -0700 Subject: [Rubygems-developers] Namespaces for Rubygems In-Reply-To: <08B3545A-AC39-4582-9FAE-92925A97845A@gmail.com> References: <12c267e40908201145w4f31af60w1a170574e528828b@mail.gmail.com> <08B3545A-AC39-4582-9FAE-92925A97845A@gmail.com> Message-ID: <12c267e40908211635x5e00a65bu10d2e143584de1ae@mail.gmail.com> On Fri, Aug 21, 2009 at 1:29 PM, John Barnette wrote: > > On Aug 20, 2009, at 11:45 AM, Tom Werner wrote: >> >> This command would look in each source, in order, for a gem with the >> 'mojombo' namespace and the 'jekyll' name. The main benefit here is that the >> gem would be installed as just 'jekyll' instead of 'mojombo-jekyll' as in >> the current situation. This elegantly solves the problem that stems from a >> gemspec declaring 'jekyll' as a dependency, and even though the >> 'mojombo-jekyll' gem is installed, it is not detected as satisfying the >> dependency even though, logically, the user expects that it should. This >> also solves the problem of gem name collisions between Rubyforge and GitHub >> such as 'net-ssh'. > > I'll try and respond to this in more detail later, but one quick note as I read it: What happens with gem updates? If the gem is installed as "jekyll," how would RubyGems know where to pull updates? Are you thinking about a change in the gemspec? One simple way would be for the client to store the source from which it came. On update, it would simply re-check that source. If that source were unavailable, the user could be prompted for what action to take (search other sources or abort). I didn't mention this in the previous message, but it would probably also be handy to list the namespace in the `gem list` output, like so (or something equivalent): $ gem list mojombo/jekyll (0.5.3) And perhaps an additional flag would also list the primary source: $ gem list --sources mojombo/jekyll (0.5.3) from http://gems.github.com Tom From nick at quaran.to Wed Aug 26 16:42:31 2009 From: nick at quaran.to (Nick Quaranto) Date: Wed, 26 Aug 2009 16:42:31 -0400 Subject: [Rubygems-developers] Gemcutter Message-ID: For the past few months I've been working on Gemcutter (http://gemcutter.org), which aims to deliver a fresh take on gem hosting for the Ruby community. The purpose of the project is three-fold: * Create more transparent and accessible project pages * Enable the community to improve and enhance the site * Provide a better API for dealing with gems Gemcutter is now up and running on Heroku, and the gem serving is done entirely through S3. Patches are beginning to roll in from contributors, and a redesign is in progress at http://staging.gemcutter.org thanks to some designer time donated from Thoughtbot. I would like to emphasize that I've worked hard to make this an open, honest effort towards improving a core part of the Ruby world that's easily accessible to every Ruby developer. The overall goal of the project is to become the default gem host for RubyGems. However, this can't happen without the support of the RubyGems and RubyForge team. Here's what I propose: 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. (all gems are currently mirrored from RubyForge and are ready for consumption) 2) Make gemcutter.org the default gem host for the next major release of RubyGems. 3) Keep RubyForge online since many projects depend on its bug trackers, mailing lists, and more. Please note I'm not suggesting that all of these happen *this instant*, I just want to open up discussion about making this happen and what would be involved. Your thoughts and comments would be appreciated. -Nick Quaranto From noreply at rubyforge.org Wed Aug 26 17:44:50 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 17:44:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26299 ] undefined method `each' for # Message-ID: <20090826214450.4092B197827F@rubyforge.org> Bugs item #26299, was opened at 2009-06-20 20:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26299&group_id=126 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Thomas Preymesser (thopre) Assigned to: Nobody (None) Summary: undefined method `each' for # Initial Comment: i get the following message at the installation of each gem with Ruby 1.9 Updating ri class cache with 7980 classes... ERROR: While executing gem ... (NoMethodError) undefined method `each' for # ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 23:44 Message: close ---------------------------------------------------------------------- Comment By: Eric Hodel (drbrain) Date: 2009-06-30 01:14 Message: Hi, please follow the guidelines from the top of the "submit bug" page: Be sure to include the output of `gem env` with your bug report, and if the bug is a result of one of the `gem` commands, run with `gem -- debug thecommand` and include the full output. This will greatly help us in fixing your bug. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26299&group_id=126 From jbarnette at gmail.com Wed Aug 26 17:57:13 2009 From: jbarnette at gmail.com (John Barnette) Date: Wed, 26 Aug 2009 14:57:13 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: Message-ID: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Nick, On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: > 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. > (all gems > are currently mirrored from RubyForge and are ready for consumption) RubyForge currently has a pretty good mirror system for supporting Gem downloads. I expect Tom could get your some figures on how much bandwidth they use. If Gemcutter was the default RG source, how would you deal with this? Are you planning on eating S3 costs yourself? Are you thinking about using something like CloudFront, since S3 itself isn't strictly a CDN? ~ j. From noreply at rubyforge.org Wed Aug 26 18:18:03 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 26 Aug 2009 18:18:03 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25998 ] Had > instead of ~> in docs for specifying a pessimist Message-ID: <20090826221803.C12691978291@rubyforge.org> Bugs item #25998, was opened at 2009-05-22 10:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=25998&group_id=126 Category: documentation Group: None Status: Open 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-27 00: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 thewoolleyman at gmail.com Wed Aug 26 19:55:52 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 26 Aug 2009 16:55:52 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: Message-ID: On Wed, Aug 26, 2009 at 1:42 PM, Nick Quaranto wrote: > Please note I'm not suggesting that all of these happen *this instant*, I > just want to open up discussion about making this happen and what would be > involved. Your thoughts and comments would be appreciated. To be honest, this seems Not Ready For Prime Time: * Pagination/sorting is wrong and broken * Project pages contain obviously broken/incorrect links (version and homepage links) * Project pages seem to have much less information than I have on RubyForge. No release notes, individual file links (.gem, .tar, etc), etc... (broken and less != transparent and accessible) * I uploaded a gem to RubyForge yesterday just before midnight, it is still not mirrored sixteen hours later (and it was available almost immediately on Rubyforge, which shows their mirror process is working very well) That's just what I found in one minute of poking around, it doesn't give me a good feeling for the overall quality and stability of the effort. I'm also concerned about long-term support. No offense to you, but Tom Copeland is a machine, he is always there to support Rubyforge, year after year... In general, if it Ain't Broken, Don't Fix It - and think especially hard if the replacement isn't a no-brainer out-of-the-park homerun... Is there a reason we can't get many of these benefits from RubyForge.org? For example, your API seems like a good idea, but why can't it be a wrapper or enhancement to the current RubyGems/RubyForge ecosystem? A Gem plugin, even? Finally, I don't see why there needs to be a change to the canonical source, since Rubyforge isn't even really one anymore. That ship has already sailed, many people don't even publish gems to RubyForge, they just use Github or their own servers. If anything there needs to be better support for multiple sources (There are good ideas here not yet implemented). The multiple-naming problem is a bigger but related issue as Eric discussed (http://blog.segment7.net/articles/2009/02/04/a-rubygems-github-proposal)... -- Chad From ryand-ruby at zenspider.com Wed Aug 26 19:24:09 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 26 Aug 2009 16:24:09 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: <50CB1EE0-D9F4-451B-A4A6-2AEA4803C68B@zenspider.com> On Aug 26, 2009, at 14:57 , John Barnette wrote: > Nick, > > On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. >> (all gems >> are currently mirrored from RubyForge and are ready for consumption) > > RubyForge currently has a pretty good mirror system for supporting > Gem downloads. I expect Tom could get your some figures on how much > bandwidth they use. If Gemcutter was the default RG source, how > would you deal with this? Are you planning on eating S3 costs > yourself? Are you thinking about using something like CloudFront, > since S3 itself isn't strictly a CDN? (possibly) even better, I'm pretty sure we could get Tom convinced that gemcutter is a good idea and we should migrate rubyforge to it. From luislavena at gmail.com Wed Aug 26 20:16:55 2009 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 27 Aug 2009 02:16:55 +0200 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <50CB1EE0-D9F4-451B-A4A6-2AEA4803C68B@zenspider.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <50CB1EE0-D9F4-451B-A4A6-2AEA4803C68B@zenspider.com> Message-ID: <71166b3b0908261716g2b4d5c1ao6070320eaa34163e@mail.gmail.com> On Thu, Aug 27, 2009 at 1:24 AM, Ryan Davis wrote: > > On Aug 26, 2009, at 14:57 , John Barnette wrote: > >> Nick, >> >> On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >>> >>> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. (all >>> gems >>> are currently mirrored from RubyForge and are ready for consumption) >> >> RubyForge currently has a pretty good mirror system for supporting Gem >> downloads. I expect Tom could get your some figures on how much bandwidth >> they use. If Gemcutter was the default RG source, how would you deal with >> this? Are you planning on eating S3 costs yourself? Are you thinking about >> using something like CloudFront, since S3 itself isn't strictly a CDN? > > (possibly) even better, I'm pretty sure we could get Tom convinced that > gemcutter is a good idea and we should migrate rubyforge to it. > The thing is that RubyForge is more than just gems. Take as example the installers for Ruby for Windows: http://rubyforge.org/frs/?group_id=167&release_id=38052 I believe that GemCutter API and interface has potential, but as was previously mentioned, the support and cost of backing it up raises some concerns. Taking in consideration there are lot of gems with more than 10K of downloads, the incurring charge of running that form S3 and adding CloudFront CDN on top will need to be payed my someone. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From nick at quaran.to Wed Aug 26 18:21:12 2009 From: nick at quaran.to (Nick Quaranto) Date: Wed, 26 Aug 2009 18:21:12 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: I'll take a look into CloudFront, I just haven't yet since the need hasn't come up. My main concern is keeping the gap between publishing a gem and being able to install it low. As for the costs, I'd like to approach a non-profit organization such as RubyCentral to help deal with them. I originally sent an email out to them first about supporting the project a few weeks ago, but I haven't heard anything back. I'm interested to hear their opinions on the site as well. I would love to get an estimate on bandwidth since the costs are easy to calculate for S3. So far with over 2,000 gem downloads and uploading all of the gems from RubyForge over the past 2 months it's been less than $5. On 8/26/09, John Barnette wrote: > Nick, > > On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. >> (all gems >> are currently mirrored from RubyForge and are ready for consumption) > > RubyForge currently has a pretty good mirror system for supporting Gem > downloads. I expect Tom could get your some figures on how much > bandwidth they use. If Gemcutter was the default RG source, how would > you deal with this? Are you planning on eating S3 costs yourself? Are > you thinking about using something like CloudFront, since S3 itself > isn't strictly a CDN? > > > ~ j. > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From nick at quaran.to Wed Aug 26 20:11:02 2009 From: nick at quaran.to (Nick Quaranto) Date: Wed, 26 Aug 2009 20:11:02 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: Message-ID: Chad, I'll admit, the website as it is right now sucks, this is not a finished project yet. There's a full fledged redesign in progress that is being pushed out to: http://staging.gemcutter.org Check out the preview post here too: http://robots.thoughtbot.com/post/165832471/gemcutter-org-redesign-preview I'd also like to pull in all of the READMEs for each gem and show them at the bottom of the gem page and get them indexed for searching. The API is already being used by the gem plugins provided by the gemcutter gem...that's how `gem push` works for instance. -Nick On Wed, Aug 26, 2009 at 7:55 PM, Chad Woolley wrote: > On Wed, Aug 26, 2009 at 1:42 PM, Nick Quaranto wrote: > > Please note I'm not suggesting that all of these happen *this instant*, I > > just want to open up discussion about making this happen and what would > be > > involved. Your thoughts and comments would be appreciated. > > To be honest, this seems Not Ready For Prime Time: > > * Pagination/sorting is wrong and broken > * Project pages contain obviously broken/incorrect links (version and > homepage links) > * Project pages seem to have much less information than I have on > RubyForge. No release notes, individual file links (.gem, .tar, etc), > etc... (broken and less != transparent and accessible) > * I uploaded a gem to RubyForge yesterday just before midnight, it is > still not mirrored sixteen hours later (and it was available almost > immediately on Rubyforge, which shows their mirror process is working > very well) > > That's just what I found in one minute of poking around, it doesn't > give me a good feeling for the overall quality and stability of the > effort. I'm also concerned about long-term support. No offense to > you, but Tom Copeland is a machine, he is always there to support > Rubyforge, year after year... > > In general, if it Ain't Broken, Don't Fix It - and think especially > hard if the replacement isn't a no-brainer out-of-the-park homerun... > > Is there a reason we can't get many of these benefits from > RubyForge.org? For example, your API seems like a good idea, but why > can't it be a wrapper or enhancement to the current RubyGems/RubyForge > ecosystem? A Gem plugin, even? > > Finally, I don't see why there needs to be a change to the canonical > source, since Rubyforge isn't even really one anymore. That ship has > already sailed, many people don't even publish gems to RubyForge, they > just use Github or their own servers. If anything there needs to be > better support for multiple sources (There are good ideas here not yet > implemented). The multiple-naming problem is a bigger but related > issue as Eric discussed > (http://blog.segment7.net/articles/2009/02/04/a-rubygems-github-proposal). > .. > > -- Chad > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From luislavena at gmail.com Wed Aug 26 20:29:09 2009 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 27 Aug 2009 02:29:09 +0200 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: <71166b3b0908261729i421c5953sc3289c57b6783256@mail.gmail.com> On Thu, Aug 27, 2009 at 12:21 AM, Nick Quaranto wrote: > I'll take a look into CloudFront, I just haven't yet since the need > hasn't come up. My main concern is keeping the gap between publishing > a gem and being able to install it low. > CloudFront is a transparent CDN, you only need to subscribe to the service and enable it for the S3 bucket you're using. Then, change the URL to instead of using S3 bucket directly uses the CNAME of the CloudFront enabled bucket. old url: http://my-bucket.s3.amazonaws.com/path/to/my/gem.gem new url: http://assets.gemcutter.org/path/to/my/gem.gem Or something similar. > I would love to get an estimate on bandwidth since the costs are easy > to calculate for S3. So far with over 2,000 gem downloads and > uploading all of the gems from RubyForge over the past 2 months it's > been less than $5. > Taking in consideration RubyForge has lot of mirrors, collecting real life numbers for it would be really great. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From aaron at tenderlovemaking.com Wed Aug 26 20:31:42 2009 From: aaron at tenderlovemaking.com (Aaron Patterson) Date: Wed, 26 Aug 2009 17:31:42 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: Message-ID: <20090827003142.GA41344@higgins.local> On Wed, Aug 26, 2009 at 04:55:52PM -0700, Chad Woolley wrote: > On Wed, Aug 26, 2009 at 1:42 PM, Nick Quaranto wrote: > > Please note I'm not suggesting that all of these happen *this instant*, I > > just want to open up discussion about making this happen and what would be > > involved. Your thoughts and comments would be appreciated. > > To be honest, this seems Not Ready For Prime Time: > > * Pagination/sorting is wrong and broken > * Project pages contain obviously broken/incorrect links (version and > homepage links) > * Project pages seem to have much less information than I have on > RubyForge. No release notes, individual file links (.gem, .tar, etc), > etc... (broken and less != transparent and accessible) > * I uploaded a gem to RubyForge yesterday just before midnight, it is > still not mirrored sixteen hours later (and it was available almost > immediately on Rubyforge, which shows their mirror process is working > very well) > > That's just what I found in one minute of poking around, it doesn't > give me a good feeling for the overall quality and stability of the > effort. I'm also concerned about long-term support. No offense to > you, but Tom Copeland is a machine, he is always there to support > Rubyforge, year after year... > > In general, if it Ain't Broken, Don't Fix It - and think especially > hard if the replacement isn't a no-brainer out-of-the-park homerun... I didn't think this was supposed to be a replacement for rubyforge, but a replacement for the rubyforge gem server. > Is there a reason we can't get many of these benefits from > RubyForge.org? For example, your API seems like a good idea, but why > can't it be a wrapper or enhancement to the current RubyGems/RubyForge > ecosystem? A Gem plugin, even? > > Finally, I don't see why there needs to be a change to the canonical > source, since Rubyforge isn't even really one anymore. That ship has > already sailed, many people don't even publish gems to RubyForge, they > just use Github or their own servers. If anything there needs to be > better support for multiple sources (There are good ideas here not yet > implemented). The multiple-naming problem is a bigger but related > issue as Eric discussed If people aren't willing to publish to the canonical source, it sounds like something is Is Broken, so we Should Fix It. -- Aaron Patterson http://tenderlovemaking.com/ From ryand-ruby at zenspider.com Wed Aug 26 20:40:06 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 26 Aug 2009 17:40:06 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <71166b3b0908261716g2b4d5c1ao6070320eaa34163e@mail.gmail.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <50CB1EE0-D9F4-451B-A4A6-2AEA4803C68B@zenspider.com> <71166b3b0908261716g2b4d5c1ao6070320eaa34163e@mail.gmail.com> Message-ID: <88E21F8C-0C6F-4915-9012-4EB9181083AB@zenspider.com> On Aug 26, 2009, at 17:16 , Luis Lavena wrote: >> (possibly) even better, I'm pretty sure we could get Tom convinced >> that >> gemcutter is a good idea and we should migrate rubyforge to it. >> > > The thing is that RubyForge is more than just gems. I wasn't suggesting that gemcutter take over rubyforge, but that rubyforge migrate to using gemcutter for gem services. With a little bit of work, it wouldn't be hard to do. > Taking in consideration there are lot of gems with more than 10K of > downloads, the incurring charge of running that form S3 and adding > CloudFront CDN on top will need to be payed my someone. There is no incurred charge if S3 is not involved. That is one benefit of having it brought under the wing of ruby central / rubyforge. From tom at infoether.com Wed Aug 26 21:22:23 2009 From: tom at infoether.com (Tom Copeland) Date: Wed, 26 Aug 2009 21:22:23 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: On Aug 26, 2009, at 5:57 PM, John Barnette wrote: > Nick, > > On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. >> (all gems >> are currently mirrored from RubyForge and are ready for consumption) > > RubyForge currently has a pretty good mirror system for supporting > Gem downloads. I expect Tom could get your some figures on how much > bandwidth they use. I just ran webalizer on the Apache log from the Bytemark mirror and it did 14M gems of gem traffic on Monday. Figure Bytemark serves about a quarter of the traffic, that's about 60M/day. File downloads eat a little more bandwidth - that Bytemark mirror did 49M yesterday of files... it's serving about 60% of the traffic, so files account for 80M/day, maybe. And of course there are spikes here and there. Yours, Tom From tom at infoether.com Wed Aug 26 21:25:28 2009 From: tom at infoether.com (Tom Copeland) Date: Wed, 26 Aug 2009 21:25:28 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: On Aug 26, 2009, at 6:21 PM, Nick Quaranto wrote: > > As for the costs, I'd like to approach a non-profit organization such > as RubyCentral to help deal with them. I originally sent an email out > to them first about supporting the project a few weeks ago, but I > haven't heard anything back. I'm interested to hear their opinions on > the site as well. It would definitely be good to get Chad or Rich or David to weigh in since they're on the board of Ruby Central, and Ruby Central rides herd on RubyForge. Yours, tom From tom at infoether.com Wed Aug 26 21:26:58 2009 From: tom at infoether.com (Tom Copeland) Date: Wed, 26 Aug 2009 21:26:58 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: On Aug 26, 2009, at 9:22 PM, Tom Copeland wrote: > > On Aug 26, 2009, at 5:57 PM, John Barnette wrote: > >> Nick, >> >> On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >>> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. >>> (all gems >>> are currently mirrored from RubyForge and are ready for consumption) >> >> RubyForge currently has a pretty good mirror system for supporting >> Gem downloads. I expect Tom could get your some figures on how much >> bandwidth they use. > > I just ran webalizer on the Apache log from the Bytemark mirror and > it did 14M gems of gem traffic on Monday. Figure Bytemark serves > about a quarter of the traffic, that's about 60M/day. File > downloads eat a little more bandwidth - that Bytemark mirror did 49M > yesterday of files... it's serving about 60% of the traffic, so > files account for 80M/day, maybe. And of course there are spikes > here and there. Oh, also, space-wise there are 6GB of gems and 29G of files. Yours, tom From nick at quaran.to Wed Aug 26 22:27:10 2009 From: nick at quaran.to (Nick Quaranto) Date: Wed, 26 Aug 2009 22:27:10 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: So I'm trying out: http://calculator.s3.amazonaws.com/calc5.html 14mb/day, is less than 1GB a month. For S3 that's less than $1/month just for data transfer out, and a little more with CloudFront. It doesn't seem like this would be a problem unless if we were in the range of terabytes/month. As for hosting files on Gemcutter, I'm open to that if that's what is necessary for the transition. 80 mb/day is still a trivial amount for S3 or CloudFront to host, cost-wise. If I interpreted your findings wrong Tom, let me know. -Nick On Wed, Aug 26, 2009 at 9:22 PM, Tom Copeland wrote: > > On Aug 26, 2009, at 5:57 PM, John Barnette wrote: > > Nick, >> >> On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >> >>> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. (all >>> gems >>> are currently mirrored from RubyForge and are ready for consumption) >>> >> >> RubyForge currently has a pretty good mirror system for supporting Gem >> downloads. I expect Tom could get your some figures on how much bandwidth >> they use. >> > > I just ran webalizer on the Apache log from the Bytemark mirror and it did > 14M gems of gem traffic on Monday. Figure Bytemark serves about a quarter > of the traffic, that's about 60M/day. File downloads eat a little more > bandwidth - that Bytemark mirror did 49M yesterday of files... it's serving > about 60% of the traffic, so files account for 80M/day, maybe. And of > course there are spikes here and there. > > Yours, > > Tom > > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From tom at infoether.com Wed Aug 26 23:12:24 2009 From: tom at infoether.com (Tom Copeland) Date: Wed, 26 Aug 2009 23:12:24 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> On Aug 26, 2009, at 10:27 PM, Nick Quaranto wrote: > So I'm trying out: http://calculator.s3.amazonaws.com/calc5.html > > 14mb/day, is less than 1GB a month. For S3 that's less than $1/month > just > for data transfer out, and a little more with CloudFront. It doesn't > seem > like this would be a problem unless if we were in the range of > terabytes/month. As for hosting files on Gemcutter, I'm open to that > if > that's what is necessary for the transition. 80 mb/day is still a > trivial > amount for S3 or CloudFront to host, cost-wise. > > If I interpreted your findings wrong Tom, let me know. Nah, that sounds right. Chad and I were actually talking today about having RubyForge use S3 for serving gems and files... Yours, tom From tom at infoether.com Wed Aug 26 23:59:58 2009 From: tom at infoether.com (Tom Copeland) Date: Wed, 26 Aug 2009 23:59:58 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> Message-ID: On Aug 26, 2009, at 11:12 PM, Tom Copeland wrote: > > On Aug 26, 2009, at 10:27 PM, Nick Quaranto wrote: > >> So I'm trying out: http://calculator.s3.amazonaws.com/calc5.html >> >> 14mb/day, is less than 1GB a month. For S3 that's less than $1/ >> month just >> for data transfer out, and a little more with CloudFront. It >> doesn't seem >> like this would be a problem unless if we were in the range of >> terabytes/month. As for hosting files on Gemcutter, I'm open to >> that if >> that's what is necessary for the transition. 80 mb/day is still a >> trivial >> amount for S3 or CloudFront to host, cost-wise. Oh, one more thing - serving up the gem indexes (yaml, Marshal.4.8, Marshal.4.8.Z, etc) also accounts for 100 MB or so a day. The yaml file is about 60MB of that. Anyhow, it's still a pretty small amount S3-wise... Yours, tom From nick at quaran.to Thu Aug 27 00:08:46 2009 From: nick at quaran.to (Nick Quaranto) Date: Thu, 27 Aug 2009 00:08:46 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> Message-ID: Just a note here: I haven't added support for the legacy indexes for in Gemcutter. Since you need at least RubyGems 1.3.3 to use the gem plugins, I figured supporting the legacy ones shouldn't be a priority as the project started. Currently I'm only generating and serving up the modern indexes (and these are undergoing some serious refactoring and rework internally as well). It would be interesting to watch the traffic of the legacy indexes vs the modern indexes to see if it's even worth it to support those going forward. At the very least, we could drop the legacy indexes into S3 and not update them. -Nick On Wed, Aug 26, 2009 at 11:59 PM, Tom Copeland wrote: > > On Aug 26, 2009, at 11:12 PM, Tom Copeland wrote: > > >> On Aug 26, 2009, at 10:27 PM, Nick Quaranto wrote: >> >> So I'm trying out: http://calculator.s3.amazonaws.com/calc5.html >>> >>> 14mb/day, is less than 1GB a month. For S3 that's less than $1/month just >>> for data transfer out, and a little more with CloudFront. It doesn't seem >>> like this would be a problem unless if we were in the range of >>> terabytes/month. As for hosting files on Gemcutter, I'm open to that if >>> that's what is necessary for the transition. 80 mb/day is still a trivial >>> amount for S3 or CloudFront to host, cost-wise. >>> >> > Oh, one more thing - serving up the gem indexes (yaml, Marshal.4.8, > Marshal.4.8.Z, etc) also accounts for 100 MB or so a day. The yaml file is > about 60MB of that. Anyhow, it's still a pretty small amount S3-wise... > > > Yours, > > tom > > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From tom at infoether.com Thu Aug 27 00:26:38 2009 From: tom at infoether.com (Tom Copeland) Date: Thu, 27 Aug 2009 00:26:38 -0400 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> Message-ID: <9CAFD572-4098-4A9F-8987-1067B7EAABEC@infoether.com> On Aug 27, 2009, at 12:08 AM, Nick Quaranto wrote: > Just a note here: I haven't added support for the legacy indexes for > in > Gemcutter. Since you need at least RubyGems 1.3.3 to use the gem > plugins, I > figured supporting the legacy ones shouldn't be a priority as the > project > started. Currently I'm only generating and serving up the modern > indexes > (and these are undergoing some serious refactoring and rework > internally as > well). > > It would be interesting to watch the traffic of the legacy indexes > vs the > modern indexes to see if it's even worth it to support those going > forward. > At the very least, we could drop the legacy indexes into S3 and not > update > them. Here's the full stats for gems.rubyforge.org (not the mirrors, just the main domain) for Wednesday: http://infoether.com/~tom/gems.rubyforge.org.logs/usage_200908.html 6K hits on the old-timey yaml index. We only rebuild it once a day... I should put it up on S3 and do a rewrite rule for just that one file... Yours, Tom From jftucker at gmail.com Thu Aug 27 04:17:28 2009 From: jftucker at gmail.com (James Tucker) Date: Thu, 27 Aug 2009 09:17:28 +0100 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> Message-ID: On 26 Aug 2009, at 23:21, Nick Quaranto wrote: > I'll take a look into CloudFront, I just haven't yet since the need > hasn't come up. My main concern is keeping the gap between publishing > a gem and being able to install it low. I really can't stress enough that it would be possible to integrate these requirements with rubyforge. I'm not saying "no", I'm just pointing out, that it could have been done just with the gem plugin targeting rubyforge. > > As for the costs, I'd like to approach a non-profit organization such > as RubyCentral to help deal with them. I originally sent an email out > to them first about supporting the project a few weeks ago, but I > haven't heard anything back. I'm interested to hear their opinions on > the site as well. > > I would love to get an estimate on bandwidth since the costs are easy > to calculate for S3. So far with over 2,000 gem downloads and > uploading all of the gems from RubyForge over the past 2 months it's > been less than $5. > > On 8/26/09, John Barnette wrote: >> Nick, >> >> On Aug 26, 2009, at 1:42 PM, Nick Quaranto wrote: >>> 1) Redirect gems.rubyforge.org to gemcutter.org for gem serving. >>> (all gems >>> are currently mirrored from RubyForge and are ready for consumption) >> >> RubyForge currently has a pretty good mirror system for supporting >> Gem >> downloads. I expect Tom could get your some figures on how much >> bandwidth they use. If Gemcutter was the default RG source, how would >> you deal with this? Are you planning on eating S3 costs yourself? Are >> you thinking about using something like CloudFront, since S3 itself >> isn't strictly a CDN? >> >> >> ~ j. >> >> _______________________________________________ >> Rubygems-developers mailing list >> http://rubyforge.org/projects/rubygems >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > _______________________________________________ > Rubygems-developers mailing list > http://rubyforge.org/projects/rubygems > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From ryand-ruby at zenspider.com Thu Aug 27 04:17:52 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 27 Aug 2009 01:17:52 -0700 Subject: [Rubygems-developers] Gemcutter In-Reply-To: References: <5F894EE9-1570-430B-B69E-17FF32AA274D@gmail.com> <034F78A7-1ACE-482E-8019-8F113B92DD01@infoether.com> Message-ID: <362F420A-5F01-498B-A0D1-9712149A6D21@zenspider.com> On Aug 26, 2009, at 21:08 , Nick Quaranto wrote: > Just a note here: I haven't added support for the legacy indexes for > in > Gemcutter. Since you need at least RubyGems 1.3.3 to use the gem > plugins, I > figured supporting the legacy ones shouldn't be a priority as the > project > started. Currently I'm only generating and serving up the modern > indexes > (and these are undergoing some serious refactoring and rework > internally as > well). Agreed. Cut and run. From noreply at rubyforge.org Thu Aug 27 07:49:19 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Aug 2009 07:49:19 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090827114920.073C5185824A@rubyforge.org> Bugs item #25816, was opened at 2009-05-07 02: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: Larry Kyrala (coldnebo) Date: 2009-08-27 11: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 21: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-07 02: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 Thu Aug 27 14:53:37 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Aug 2009 14:53:37 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090827185337.EF91418581F5@rubyforge.org> Bugs item #25816, was opened at 2009-05-07 04: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: Nick Hildebrant (nihildeb) Date: 2009-08-27 20: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 13: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 23: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-07 04: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 Thu Aug 27 15:06:13 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Aug 2009 15:06:13 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090827190613.AAFF415B8025@rubyforge.org> Bugs item #25816, was opened at 2009-05-07 04: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: Nick Hildebrant (nihildeb) Date: 2009-08-27 21: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 20: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 13: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 23: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-07 04: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 Thu Aug 27 16:51:29 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Aug 2009 16:51:29 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-25816 ] misleading error message when one of many sources unreachable. Message-ID: <20090827205129.5F5811858204@rubyforge.org> Bugs item #25816, was opened at 2009-05-07 02: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: Larry Kyrala (coldnebo) Date: 2009-08-27 20: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 19: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 18: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 11: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 21: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-07 02: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 Thu Aug 27 18:37:50 2009 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 27 Aug 2009 18:37:50 -0400 (EDT) Subject: [Rubygems-developers] [ rubygems-Bugs-26109 ] gem install gemname --remote will fail if gemname is in current directory Message-ID: <20090827223750.6FE5B1779932@rubyforge.org> Bugs item #26109, was opened at 2009-06-03 00:03 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 Category: `gem install` command Group: None Status: Open Resolution: None Priority: 3 Submitted By: ara howard (ahoward) Assigned to: Nobody (None) Summary: gem install gemname --remote will fail if gemname is in current directory Initial Comment: gem install gemname --remote will prefer a gem in the current directory. seems like --remote should *never* do *anything* local? ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-28 00:37 Message: Just familiarizing myself with the code here. I now see the issue. #find_gems_with_sources probably should only merge gem sources if @domain == :both also I don't see a case in which setting @domain = :local after rescuing a RemoteFetch exception would be useful or make sense ---------------------------------------------------------------------- Comment By: Nick Hildebrant (nihildeb) Date: 2009-08-26 22:54 Message: I can not reproduce this issue as a "preference". Rubygems appears to do remote as requested with requested gem in pwd. In the case of no network availability, the requested gem in the pwd is installed. This is as designed: Gem::DependencyInstaller#find_gems_with_sources rescues with @domain = :local RubyGems Environment: - RUBYGEMS VERSION: 1.3.3 - RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux] - INSTALLATION DIRECTORY: /usr/lib/ruby/gems/1.8 - RUBY EXECUTABLE: /usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - x86_64-linux - GEM PATHS: - /usr/lib/ruby/gems/1.8 - /home/nihildeb/.gem/ruby/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=26109&group_id=126 From rick.denatale at gmail.com Sat Aug 29 19:01:48 2009 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sat, 29 Aug 2009 19:01:48 -0400 Subject: [Rubygems-developers] Having problems with Gem version on Snow Leopard Message-ID: So, the migration to Snow Leopard has gone well, except that it's totally bollixed up my ruby/rails development environment. It looks like Snow Leopard shipped with gem version 1.2.0 is this right? $ which gem /usr/bin/gem $ gem --version 1.2.0 Okay, so I guess I need to update $ sudo gem update --system Password: Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.2.0 ERROR: While executing gem ... (NameError) undefined local variable or method `remote_gemspecs' for # ../../System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/gem So, is there a newer rubygems-update? $ gem list -b rubygems-update *** LOCAL GEMS *** rubygems-update (1.2.0) *** REMOTE GEMS *** rubygems-update (1.3.5) \e]0;rick? ~ $ gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org/ http://gems.github.com So let's try installing that: $ gem update rubygems-update Updating installed gems Updating rubygems-update Successfully installed rubygems-update-1.2.0 ERROR: While executing gem ... (NameError) undefined local variable or method `remote_gemspecs' for # Okay lets's try installing the specific version: $ gem install --remote --version 1.3.5 rubygems-update Successfully installed rubygems-update-1.2.0 1 gem installed And the version gets ignored. Any ideas about how to get out of this loop??? -- 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