From thewoolleyman at gmail.com Sat Dec 1 23:43:44 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 1 Dec 2007 21:43:44 -0700 Subject: [Rubygems-developers] problems with 'gem server' --[no]-daemon option Message-ID: Hi, Looks like the --[no]-daemon option is broken on the new gem server command. I can only get '-daemon' to work, not '--daemon'. I can't get --no-daemon to work at all. Thanks, Chad From thewoolleyman at gmail.com Mon Dec 3 01:22:27 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 2 Dec 2007 23:22:27 -0700 Subject: [Rubygems-developers] Testing against multiple rubygems versions, gem server problems Message-ID: Hi, I'm trying to update my GemInstaller app's functional tests to pass against rubygems 0.9.5. I'm having problems getting an embedded test gem server to run reliably under 0.9.4 and 0.9.5. Previously, under 0.9.4, I did a full automated install of rubygems 0.9.4 to a temp dir, and used that dir as my test gem home as well. The load path still used 0.9.4 rubygems libs from my system install (/usr/local/lib/ruby/site_ruby/1.8/rubygems), but this was ok because I only ran tests against 0.9.4. I have a local dummy dir of various stub gems which I run an embedded server against, and my tests use GemInstaller to install these gems in various ways. Now, I'm trying to use an environment var RUBYGEMS_VERSION= to automatically put the appropriate embedded distro of rubygems onto my load path, and run an embedded gem server and all of my tests ageinst that specified version (either 0.9.4 or 0.9.5). I can't make this work, however. Gem server does strange things - it will sometimes not show all gems, or sometimes it gets port conflict errors even though there is no other server running, or it shows the rubyforge gems instead of gems in my specified dir. I even have problems when I attempt to manually run the gem server with a specified --port and --dir pointing to dummy gems, and then do a gem list with --remote and --source=http://localhost:port. This used to work fine with 0.9.4, but now I get errors on 0.9.5 boxes, and sometimes even on 0.9.4 boxes which used to work. It also seems to matter whether I use 127.0.0.1 vs. localhost. I've tried to debug this all weekend, but I keep getting lost in the source_index and related gem list/query code. It's also difficult because I'm not sure how to reliably downgrade a rubygems installation from 0.9.5 to 0.9.4. Just installing 0.9.4 over 0.9.5 left stuff broken. I could manually delete stuff and reinstall 0.9.4, but I'm afraid I might miss something. Has anyone tried to do anything like this? Any tips or pointers on how to debug these gem server problems more methodically are welcome. Thanks, --Chad From charles.nutter at sun.com Tue Dec 4 00:37:13 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 03 Dec 2007 23:37:13 -0600 Subject: [Rubygems-developers] Problems with OpenSSL requirement in RubyGems 0.9.5 and JRuby Message-ID: <4754E789.7040801@sun.com> Actually I think this was introduced with signed gem support, but JRuby hasn't updated since spring. So here's the deal. With the new security policy stuff, OpenSSL has gotten pulled in as a requirement to handle certificates, signing, all that jazz. While I intensely dislike the OpenSSL extension (because it's little more than a thin wrapper around the C API, which makes it particularly difficult to emulate on non-C implementations) we could probably live with this in JRuby because we have an OpenSSL extension look-alike gem. The problem, however, is that at some point between 0.9.1 and 0.9.5, RubyGems started requiring that OpenSSL extension be present for *all* gem installs: ~/NetBeansProjects/rubygems $ jruby -S gem install jruby-openssl Bulk updating Gem source index for: http://gems.rubyforge.org ERROR: While executing gem ... (Gem::Exception) SSL is not installed on this system This is a bit of a chicken-and-egg problem. We need to install a gem to enable OpenSSL support in JRuby. We need OpenSSL to install gems. As far as I understand it, when installing non-signed gems there should be no need for RubyGems to pull in OpenSSL, correct? I poked around the source a bit, and discovered a few places where Gem.ensure_ssl_available is being called. Almost all of them look like this: if security_policy then Gem.ensure_ssl_available So the expectation is that if security_policy (usually retrieved from options[:security_policy]) is nil, SSL will not be required and the additional code will not be run. However, I also found this in dependency_installer.rb: DEFAULT_OPTIONS = { :env_shebang => false, :domain => :both, # HACK dup :force => false, :ignore_dependencies => false, :security_policy => Gem::Security::NoSecurity, # HACK AlmostNo? Low? :wrappers => true } If I'm understanding right, this means that for dependency-sensitive installs (which would be basically all of them) security_policy will *never* be nil, and OpenSSL will be required all the time. This is a little problematic for implementations that don't have out-of-the-box OpenSSL implementations like JRuby, Rubinius, Ruby.NET, XRuby, and IronRuby. I tried the naive fixes of commenting out the default security policy and adding a != NoSecurity check into the places that call ensure_ssl_available, but in each case I got errors like this: ERROR: While executing gem ... (TypeError) can't convert NilClass into nil /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:22:in `<=>' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:19:in `call' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:124:in `satisfy?' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `satisfied_by?' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `all?' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `each' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `all?' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `satisfied_by?' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/requirement.rb:117:in `install' /Users/headius/NetBeansProjects/rubygems/lib/rubygems/dependency_installer.rb:225:in `install' So I'm hoping those of you more familiar with RubyGems code can help me out here: 1. Is it intended that OpenSSL will be required all the time, regardless of whether it will be used? 2. Shouldn't the code that's checking for security_policy != nil also check that it is != NoSecurity, avoiding OpenSSL requirement? 3. Perhaps security_policy is intended to never be nil, and so the check for != nil is already useless? - Charlie From charles.nutter at Sun.COM Tue Dec 4 00:49:35 2007 From: charles.nutter at Sun.COM (Charles Oliver Nutter) Date: Mon, 03 Dec 2007 23:49:35 -0600 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby Message-ID: <4754EA6F.8090209@sun.com> I need to modify RubyGems to have slightly different defaults when running under JRuby. Where is the best place to do that? Should I modify the RubyGems code we ship with, or is there a better way? For example, because JRuby's main executable is a shell script, there's no way to use it in the shebang line of a script. Unfortunately, by default, RubyGems installs the exact name of the executable: #!/home/blah/jruby-1.0.2/bin/jruby So I need to enable the env-shebang option always under JRuby, so these scripts install right. Suggestions? - Charlie From thewoolleyman at gmail.com Sun Dec 9 19:17:24 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 9 Dec 2007 17:17:24 -0700 Subject: [Rubygems-developers] Testing against multiple rubygems versions, gem server problems In-Reply-To: References: Message-ID: On Dec 2, 2007 11:22 PM, Chad Woolley wrote: > Gem server does strange things - it > will sometimes not show all gems, or sometimes it gets port conflict > errors even though there is no other server running I've tracked this problem down to a problem with TCPServer on linux only under Ruby 1.8.5 Webrick::Utils.create_listeners. Here's the error for googlers: # Socket.getaddrinfo returns two entries, one inet6 and one inet. On linux, this line in Webrick::Utils.create_listeners gets the EADDRINUSE error when processing the second entry: sock = TCPServer.new(ai[3], port) For some reason, this doesn't happen on mac, and didn't used to happen on Linux. Anyway, doesn't seem to cause problems, since the server gets started anyway, so I'm not going to worry about it. Just thought I'd summarize my debugging here for clo-sure and anybody googling the error. -- Chad From stephen.bannasch at deanbrook.org Mon Dec 10 13:58:24 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 10 Dec 2007 13:58:24 -0500 Subject: [Rubygems-developers] mysql gem: version specification and update problem Message-ID: The mysql gem has unfortunate interaction between gem versions, platforms, and updating on macosx. I'm trying to figure out if it is a problem with rubygems or the specification for the mysql gem itself. The latest version of the mysql gem for the mac is v2.7 while the latest version is 2.7.3. $ gem list mysql -r *** REMOTE GEMS *** mysql (2.7.3, 2.7.1, 2.7, 2.6, 2.5.1) mysql_replication_adapter (0.4.0, 0.2.0, 0.1.1, 0.1.0) mysql_retry_lost_connection (0.0.1) After I install the mysql gem on my mac any future use of the command: sudo gem update assumes the mysql gem is not up-to-date and tries to re-install it. Previously I would just be presented with a console request asking if I wanted to update the mysql gem -- there was actually no update for the mac and I would just answer no. Now because dependencies are automatically followed it is always getting rebuilt. This would just be a waste of bandwidth and processing except that successfully compiling the mysql gem on macosx requires setting an env variable ... so everytime I update all my gems the mysql gem rebuild of it's native libraries fails. I'm finding this problem on: MacOS X 10.4.11, ruby 1.8.6p11, rubygems v0.9.5 Is this a bug in rubygems or in how the mysql gem is specified? ---- example ---- $ sudo gem uninstall mysql Successfully uninstalled mysql-2.7 $ sudo gem install mysql -- --with-mysql-dir=/usr/local/mysql Building native extensions. This could take a while... Successfully installed mysql-2.7 1 gem installed $ gem outdated $ sudo gem update Updating installed gems... Attempting remote update of mysql Building native extensions. This could take a while... ERROR: Error installing mysql: ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb update checking for mysql_query() in -lmysqlclient... no checking for main() in -lm... yes checking for mysql_query() in -lmysqlclient... no checking for main() in -lz... yes checking for mysql_query() in -lmysqlclient... no checking for main() in -lsocket... no checking for mysql_query() in -lmysqlclient... no checking for main() in -lnsl... no checking for mysql_query() in -lmysqlclient... no Gem files will remain installed in /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection. Results logged to /usr/local/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out Gems: [mysql] updated From drbrain at segment7.net Mon Dec 10 17:08:49 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Dec 2007 14:08:49 -0800 Subject: [Rubygems-developers] Testing against multiple rubygems versions, gem server problems In-Reply-To: References: Message-ID: <7BF12670-F64C-447C-AD1B-8241E5565E4E@segment7.net> On Dec 9, 2007, at 16:17 PM, Chad Woolley wrote: > On Dec 2, 2007 11:22 PM, Chad Woolley wrote: >> Gem server does strange things - it >> will sometimes not show all gems, or sometimes it gets port conflict >> errors even though there is no other server running > > I've tracked this problem down to a problem with TCPServer on linux > only under Ruby 1.8.5 Webrick::Utils.create_listeners. > > Here's the error for googlers: > > # > > Socket.getaddrinfo returns two entries, one inet6 and one inet. On > linux, this line in Webrick::Utils.create_listeners gets the > EADDRINUSE error when processing the second entry: > > sock = TCPServer.new(ai[3], port) > > For some reason, this doesn't happen on mac, and didn't used to > happen on Linux. > > Anyway, doesn't seem to cause problems, since the server gets started > anyway, so I'm not going to worry about it. Just thought I'd > summarize my debugging here for clo-sure and anybody googling the > error. Is there a change that can be made to make the gem server handle this better automatically? From thewoolleyman at gmail.com Mon Dec 10 17:14:33 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 10 Dec 2007 15:14:33 -0700 Subject: [Rubygems-developers] Testing against multiple rubygems versions, gem server problems In-Reply-To: <7BF12670-F64C-447C-AD1B-8241E5565E4E@segment7.net> References: <7BF12670-F64C-447C-AD1B-8241E5565E4E@segment7.net> Message-ID: On Dec 10, 2007 3:08 PM, Eric Hodel wrote: > Is there a change that can be made to make the gem server handle this > better automatically? I don't think so. rdebug stopped when I hit the native TCPServer, so I don't know the root cause (and wasn't going to debug that far since it works anyway). From drbrain at segment7.net Mon Dec 10 17:27:15 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Dec 2007 14:27:15 -0800 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: <4754EA6F.8090209@sun.com> References: <4754EA6F.8090209@sun.com> Message-ID: On Dec 3, 2007, at 21:49 PM, Charles Oliver Nutter wrote: > I need to modify RubyGems to have slightly different defaults when > running under JRuby. Where is the best place to do that? Should I > modify > the RubyGems code we ship with, or is there a better way? > > For example, because JRuby's main executable is a shell script, > there's > no way to use it in the shebang line of a script. Unfortunately, by > default, RubyGems installs the exact name of the executable: > > #!/home/blah/jruby-1.0.2/bin/jruby > > So I need to enable the env-shebang option always under JRuby, so > these > scripts install right. > > Suggestions? RubyGems should have a configuration file that lives in /etc and wherever it is on win32. I think Dan Berger posted how to do that in a previous message. From drbrain at segment7.net Mon Dec 10 17:29:42 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Dec 2007 14:29:42 -0800 Subject: [Rubygems-developers] Problems with OpenSSL requirement in RubyGems 0.9.5 and JRuby In-Reply-To: <4754E789.7040801@sun.com> References: <4754E789.7040801@sun.com> Message-ID: On Dec 3, 2007, at 21:37 PM, Charles Oliver Nutter wrote: > The problem, however, is that at some point between 0.9.1 and 0.9.5, > RubyGems started requiring that OpenSSL extension be present for *all* > gem installs: > > [...] > > However, I also found this in dependency_installer.rb: > > DEFAULT_OPTIONS = { > :env_shebang => false, > :domain => :both, # HACK dup > :force => false, > :ignore_dependencies => false, > :security_policy => Gem::Security::NoSecurity, # HACK AlmostNo? > Low? > :wrappers => true > } > > If I'm understanding right, this means that for dependency-sensitive > installs (which would be basically all of them) security_policy will > *never* be nil, and OpenSSL will be required all the time. I'll roll this change back. From drbrain at segment7.net Mon Dec 10 17:53:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Dec 2007 14:53:05 -0800 Subject: [Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again) In-Reply-To: <4b6f054f0711291839j3bb31cb3sbc1868e84999f7ae@mail.gmail.com> References: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> <57a815bf0711282203ja0fced3sf0be049305b62fdd@mail.gmail.com> <4b6f054f0711291839j3bb31cb3sbc1868e84999f7ae@mail.gmail.com> Message-ID: <4C72CF65-3210-43F9-ADCE-10865EC22B3A@segment7.net> On Nov 29, 2007, at 18:39 PM, Trans wrote: > Welll. I have it. Its quite simple. This is how it works: if you set > 'extensions_fallback' to true in the gemspec and an extension fails to > build on install then it says "Native extension failed to compile, but > this gem has a fallback option. Would you like to complete the install > without the native extensions or abort? [Y/n] > > If the RubyGems team thinks this is acceptable I'll send it their > way... Honestly, I don't know how else it can be done. Without this > one is stuck with maintaning a secondary gem and trying to inform > potential users that there is a pure ruby option in case the native > extension one fails --but maybe that's what the RubyGems team > considers the better approach? I like this, but I think extensions_fallback is a bad name. Go ahead and submit the patch, and maybe we can think up a good name in the meantime. From drbrain at segment7.net Mon Dec 10 19:45:31 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 10 Dec 2007 16:45:31 -0800 Subject: [Rubygems-developers] Problems with OpenSSL requirement in RubyGems 0.9.5 and JRuby In-Reply-To: References: <4754E789.7040801@sun.com> Message-ID: <3AD419DA-81A7-4A74-98E5-6155121AF38C@segment7.net> On Dec 10, 2007, at 14:29 PM, Eric Hodel wrote: > On Dec 3, 2007, at 21:37 PM, Charles Oliver Nutter wrote: >> The problem, however, is that at some point between 0.9.1 and 0.9.5, >> RubyGems started requiring that OpenSSL extension be present for >> *all* >> gem installs: >> >> [...] >> >> However, I also found this in dependency_installer.rb: >> >> DEFAULT_OPTIONS = { >> :env_shebang => false, >> :domain => :both, # HACK dup >> :force => false, >> :ignore_dependencies => false, >> :security_policy => Gem::Security::NoSecurity, # HACK AlmostNo? >> Low? >> :wrappers => true >> } >> >> If I'm understanding right, this means that for dependency-sensitive >> installs (which would be basically all of them) security_policy will >> *never* be nil, and OpenSSL will be required all the time. > > > I'll roll this change back. Done. Removing openssl.rb and friends seems to work for me. require 'rubygems' require 'rubygems/dependency_installer' Gem::DependencyInstaller.new('rake', nil, :install_dir => '/tmp/ gems').install p Gem.ssl_available? # => false p $".grep(/openssl/i) # => ["rubygems/gem_openssl.rb"] From thewoolleyman at gmail.com Tue Dec 11 03:30:47 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Dec 2007 01:30:47 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 Message-ID: I'm having problems running the 0.9.5 gem server. I have a directory of stub gems for testing that works fine with the gem_server <= 0.9.4. It's here: http://geminstaller.rubyforge.org/svn/tags/rel_0.2.4/spec/fixture/gems/ I can run these commands successfully in 0.9.4 to start a server and list all the gems in this dir: $ gem_server -d .../gems/ -p 9909 $ gem list --remote --source=http://localhost:9909 However, in 0.9.5, I get errors trying to do this same thing First, I have to delete the local cache because of this command failing previously $ rm -rf ~/.gem Then, I generate the index from the gem dir (although the error still happens even if I don't) $ gem generate_index Then, I start the server: $ gem server --dir=.../gems/ --port=9909 Starting gem server on http://localhost:9909/ Then, I get error listing some of the gems: $ gem list --remote --source=http://localhost:9909 *** REMOTE GEMS *** Updating metadata for 8 gems from http://localhost:9909 Failed to download spec stubgem-multiplatform-1.0.1-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz Failed to download spec dependent-stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/dependent-stubgem-1.0.0.gemspec.rz ..Failed to download spec stubgem-multiplatform-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.0.gemspec.rz Failed to download spec stubgem-multiplatform-1.0.1 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1.gemspec.rz Failed to download spec stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-1.0.0.gemspec.rz Failed to download spec dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz complete dependent-stubgem-depends-on-multiplatform (1.0.0) dependent-stubgem-multilevel (1.0.0) ...and here's the output of the server: 127.0.0.1 - - [11/Dec/2007:01:19:12 MST] "HEAD /Marshal.4.8 HTTP/1.1" 200 0 - -> /Marshal.4.8 127.0.0.1 - - [11/Dec/2007:01:20:17 MST] "HEAD /Marshal.4.8 HTTP/1.1" 200 0 - -> /Marshal.4.8 127.0.0.1 - - [11/Dec/2007:01:20:17 MST] "GET /quick/index.rz HTTP/1.1" 200 100 - -> /quick/index.rz 127.0.0.1 - - [11/Dec/2007:01:20:17 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:17 MST] "GET /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 0 - -> /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:17 MST] "GET /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 0 - -> /quick/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/dependent-stubgem-multilevel-1.0.0.gemspec.rz HTTP/1.1" 200 660 - -> /quick/dependent-stubgem-multilevel-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 200 678 - -> /quick/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 500 0 - -> /quick/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 500 0 - -> /quick/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 0 - -> /quick/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:18 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 0 - -> /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [11/Dec/2007:01:20:19 MST] "GET /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 0 - -> /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz I notice that the only thing that is generated in the /quick dir is index and index.rz. This seems to be the problem, since the gem list command is looking for other files under /quick. Is this a bug, or am I doing something wrong? Thanks, -- Chad From han.holl at tietoenator.com Wed Dec 12 05:49:59 2007 From: han.holl at tietoenator.com (han.holl at tietoenator.com) Date: Wed, 12 Dec 2007 11:49:59 +0100 Subject: [Rubygems-developers] Silly update Message-ID: <200712121149.59623.han.holl@tietoenator.com> Hi, Gem update installs even when no newer version is avalaible: bever:~> gem list hpricot *** LOCAL GEMS *** hpricot (0.6) bever:~> gem update hpricot Updating installed gems... Attempting remote update of hpricot Building native extensions. This could take a while... Successfully installed hpricot-0.6 1 gem installed Installing ri documentation for hpricot-0.6... Installing RDoc documentation for hpricot-0.6... Gems: [hpricot] updated bever:~> gem --version 0.9.5 Cheers, Han Holl From thewoolleyman at gmail.com Wed Dec 12 14:07:37 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 12 Dec 2007 12:07:37 -0700 Subject: [Rubygems-developers] Silly update In-Reply-To: <200712121149.59623.han.holl@tietoenator.com> References: <200712121149.59623.han.holl@tietoenator.com> Message-ID: On Dec 12, 2007 3:49 AM, wrote: > > Hi, > > Gem update installs even when no newer version is avalaible: I've seen this for quite a while even with older versions of rubygems. It happens with certain gems, I think RedCloth or BlueCloth was one of them... From stephen.bannasch at deanbrook.org Wed Dec 12 23:39:41 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 12 Dec 2007 23:39:41 -0500 Subject: [Rubygems-developers] Silly update In-Reply-To: <200712121149.59623.han.holl@tietoenator.com> References: <200712121149.59623.han.holl@tietoenator.com> Message-ID: >Hi, > >Gem update installs even when no newer version is avalaible: Han, You might want to see if your problem is a duplicate or similar to my problem which I also put in a bug on the rubyforge tracker for rubygems. http://rubyforge.org/tracker/index.php?func=detail&aid=16244&group_id=126&atid=575 From drbrain at segment7.net Thu Dec 13 16:37:20 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Dec 2007 13:37:20 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: Message-ID: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> On Dec 11, 2007, at 24:30 AM, Chad Woolley wrote: > I'm having problems running the 0.9.5 gem server. I have a directory > of stub gems for testing that works fine with the gem_server <= 0.9.4. > It's here: > > http://geminstaller.rubyforge.org/svn/tags/rel_0.2.4/spec/fixture/ > gems/ > > I can run these commands successfully in 0.9.4 to start a server and > list all the gems in this dir: > > $ gem_server -d .../gems/ -p 9909 > $ gem list --remote --source=http://localhost:9909 > > However, in 0.9.5, I get errors trying to do this same thing > > First, I have to delete the local cache because of this command > failing previously > $ rm -rf ~/.gem > > Then, I generate the index from the gem dir (although the error still > happens even if I don't) > $ gem generate_index `gem generate_index` is used to generating static files for use w/o gem server. It won't affect `gem server` > Then, I start the server: > $ gem server --dir=.../gems/ --port=9909 > Starting gem server on http://localhost:9909/ > > Then, I get error listing some of the gems: > $ gem list --remote --source=http://localhost:9909 > > [...] > > I notice that the only thing that is generated in the /quick dir is > index and index.rz. This seems to be the problem, since the gem list > command is looking for other files under /quick. `gem server` probably won't show most files since they're generated by a WEBrick handler. I don't think the directory indexes are set up to list things. > Is this a bug, or am I doing something wrong? You certainly shouldn't get 500s. I'll look into it, but if you can run with --debug it might give a backtrace. From drbrain at segment7.net Thu Dec 13 17:43:55 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Dec 2007 14:43:55 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> Message-ID: <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> On Dec 13, 2007, at 13:37 PM, Eric Hodel wrote: > On Dec 11, 2007, at 24:30 AM, Chad Woolley wrote: >> >> Is this a bug, or am I doing something wrong? > > You certainly shouldn't get 500s. I'll look into it, but if you can > run with --debug it might give a backtrace. Fixed. From charles.nutter at sun.com Fri Dec 14 01:06:42 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 14 Dec 2007 07:06:42 +0100 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: References: <4754EA6F.8090209@sun.com> Message-ID: <47621D72.80601@sun.com> Eric Hodel wrote: > RubyGems should have a configuration file that lives in /etc and > wherever it is on win32. I think Dan Berger posted how to do that in > a previous message. That's not exactly what I meant. JRuby users might have several installs of JRuby...what we want is a way to ship RubyGems with all the appropriate defaults for running under JRuby pre-set. I'm just not sure which file is the appropriate one to do that. - Charlie From charles.nutter at sun.com Fri Dec 14 01:07:55 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 14 Dec 2007 07:07:55 +0100 Subject: [Rubygems-developers] Problems with OpenSSL requirement in RubyGems 0.9.5 and JRuby In-Reply-To: <3AD419DA-81A7-4A74-98E5-6155121AF38C@segment7.net> References: <4754E789.7040801@sun.com> <3AD419DA-81A7-4A74-98E5-6155121AF38C@segment7.net> Message-ID: <47621DBB.7060006@sun.com> Eric Hodel wrote: > Done. Removing openssl.rb and friends seems to work for me. > > require 'rubygems' > require 'rubygems/dependency_installer' > > Gem::DependencyInstaller.new('rake', nil, :install_dir => '/tmp/ > gems').install > > p Gem.ssl_available? # => false > p $".grep(/openssl/i) # => ["rubygems/gem_openssl.rb"] Excellent...we'll confirm it's all working correctly in JRuby. Any timeframe for the next big release? You had mentioned a 1.0 possibly in the future. - Charlie From drbrain at segment7.net Sat Dec 15 22:31:41 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 15 Dec 2007 19:31:41 -0800 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: <47621D72.80601@sun.com> References: <4754EA6F.8090209@sun.com> <47621D72.80601@sun.com> Message-ID: <9C21C37A-98C5-466B-A83F-1A32D8AC8920@segment7.net> On Dec 13, 2007, at 22:06 PM, Charles Oliver Nutter wrote: > Eric Hodel wrote: >> RubyGems should have a configuration file that lives in /etc and >> wherever it is on win32. I think Dan Berger posted how to do that in >> a previous message. > > That's not exactly what I meant. JRuby users might have several > installs > of JRuby...what we want is a way to ship RubyGems with all the > appropriate defaults for running under JRuby pre-set. I'm just not > sure > which file is the appropriate one to do that. I added a patch that moved most of the defaults methods into rubygems/ defaults.rb. Perhaps RubyGems could conditionally define things depending upon platform in that file? From drbrain at segment7.net Sat Dec 15 22:32:21 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 15 Dec 2007 19:32:21 -0800 Subject: [Rubygems-developers] Problems with OpenSSL requirement in RubyGems 0.9.5 and JRuby In-Reply-To: <47621DBB.7060006@sun.com> References: <4754E789.7040801@sun.com> <3AD419DA-81A7-4A74-98E5-6155121AF38C@segment7.net> <47621DBB.7060006@sun.com> Message-ID: On Dec 13, 2007, at 22:07 PM, Charles Oliver Nutter wrote: > Eric Hodel wrote: >> Done. Removing openssl.rb and friends seems to work for me. >> >> require 'rubygems' >> require 'rubygems/dependency_installer' >> >> Gem::DependencyInstaller.new('rake', nil, :install_dir => '/tmp/ >> gems').install >> >> p Gem.ssl_available? # => false >> p $".grep(/openssl/i) # => ["rubygems/gem_openssl.rb"] > > Excellent...we'll confirm it's all working correctly in JRuby. Any > timeframe for the next big release? You had mentioned a 1.0 possibly > in > the future. I've cleaned up a bunch of bugs, so I suspect Monday or Tuesday. From drbrain at segment7.net Sat Dec 15 22:35:22 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 15 Dec 2007 19:35:22 -0800 Subject: [Rubygems-developers] RubyGems 1.0 release soon Message-ID: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> I cleaned up a bunch of bugs that arrived with 0.9.5, and would like to do a 1.0 release of RubyGems Monday or Tuesday. I forwarded one Windows-releated bug to Luis Lavena, but maybe somebody else can help? http://rubyforge.org/tracker/index.php?func=detail&aid=16259&group_id=126&atid=575 Are there any other outstanding issues or important bugs that should be fixed in the tracker? Or bugs that didn't make it into the tracker? I think think all the unfixed bugs in the tracker can wait until a future release. http://rubyforge.org/tracker/?atid=575&group_id=126&func=browse From thewoolleyman at gmail.com Sun Dec 16 00:39:16 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 15 Dec 2007 22:39:16 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> Message-ID: Here is a trace from ruby-debug, right before I get the exception. On Dec 13, 2007 3:43 PM, Eric Hodel wrote: > On Dec 13, 2007, at 13:37 PM, Eric Hodel wrote: > > On Dec 11, 2007, at 24:30 AM, Chad Woolley wrote: > >> > >> Is this a bug, or am I doing something wrong? > > > > You certainly shouldn't get 500s. I'll look into it, but if you can > > run with --debug it might give a backtrace. > > Fixed. > This is still a problem with the trunk as of right now. Here is my ruby-debug session, which shows the stack right before I get the exception. It gets into fetch_single_spec, then blows up looking for a /quick/Marshal...rz file: chadmac:~ woolley$ rm -rf ~/.gem; rdebug /usr/local/bin/gem -- list --remote --source=http://127.0.0.1:9909 /usr/local/bin/gem:8 require 'rubygems' [3, 12] in /usr/local/bin/gem 3 # Copyright 2006 by Chad Fowler, Rich Kilmer, Jim Weirich and others. 4 # All rights reserved. 5 # See LICENSE.txt for permissions. 6 #++ 7 => 8 require 'rubygems' 9 require 'rubygems/gem_runner' 10 11 required_version = Gem::Requirement.new ">= 1.8.2" 12 (rdb:1) b /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:397 Set breakpoint 1 at /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:397 (rdb:1) c *** REMOTE GEMS *** Updating metadata for 8 gems from http://127.0.0.1:9909 Breakpoint 1 at /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:397 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:397 marshal_uri = source_uri + "/quick/Marshal.#{Gem.marshal_version}/#{spec_name}.gemspec.rz" [392, 401] in /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb 392 393 # Tries to fetch Marshal representation first, then YAML 394 def fetch_single_spec(source_uri, spec_name) 395 @fetch_error = nil 396 begin => 397 marshal_uri = source_uri + "/quick/Marshal.#{Gem.marshal_version}/#{spec_name}.gemspec.rz" 398 zipped = fetcher.fetch_path marshal_uri 399 return Marshal.load(unzip(zipped)) 400 rescue => ex 401 @fetch_error = ex (rdb:1) where --> #0 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:397 in 'fetch_single_spec' #1 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:425 in 'update_with_missing' #2 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:424 in 'update_with_missing' #3 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:293 in 'update' #4 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:33 in 'refresh' #5 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:135 in 'refresh' #6 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:128 in 'refresh' #7 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:40 in 'cache' #8 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:50 in 'search' #9 /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/query_command.rb:52 in 'execute' #10 /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/list_command.rb:31 in 'execute' #11 /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136 in 'invoke' #12 /usr/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:104 in 'process_args' #13 /usr/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:74 in 'run' #14 /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39 in 'run' #15 /usr/local/bin/gem:22 in 'new' From thewoolleyman at gmail.com Sun Dec 16 00:43:54 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 15 Dec 2007 22:43:54 -0700 Subject: [Rubygems-developers] RubyGems 1.0 release soon In-Reply-To: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> References: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> Message-ID: On Dec 15, 2007 8:35 PM, Eric Hodel wrote: > Are there any other outstanding issues or important bugs that should > be fixed in the tracker? Or bugs that didn't make it into the tracker? I am still having problems with gem server in 0.9.5. I just updated that thread with my debug output. This seems like a problem, because I am not doing anything different than 0.9.4, and it won't serve my local test gems anymore. I'd be glad to help resolve this (or understand what I'm doing wrong and why it's not a problem). I'll keep debugging trying to see what is different from 0.9.4, and update the thread with what I find. I don't have a ticket for this yet, but I can create one if you want... -- Chad From thewoolleyman at gmail.com Sun Dec 16 00:55:32 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 15 Dec 2007 22:55:32 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> Message-ID: Also, I just confirmed, I don't have any problems running the 0.9.5 gem list command against these same gems served by the 0.9.4 gem_server, which I started like this: ruby -I .../rubygems-0.9.4/lib/ .../rubygems-0.9.4/bin/gem_server --dir=.../gems/ --port=9909 From thewoolleyman at gmail.com Sun Dec 16 02:05:45 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 16 Dec 2007 00:05:45 -0700 Subject: [Rubygems-developers] Question on GEM_PATH Message-ID: When I use GEM_PATH to add an additional local repository to be used, what dirs must be in that repository? gems? specifications? docs? cache? others? Also, a related question. If I have a source checkout of a gem locally, can I somehow put it on my GEM_PATH to be loaded, even if it doesn't follow the standard repository layout? The use case would be to perform updates on a dependency gem, and have those updates immediately usable by a separate local app, without having to actually do the step to build and install the gem to a local repository. Thanks, Chad From drbrain at segment7.net Sun Dec 16 04:59:09 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 16 Dec 2007 01:59:09 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> Message-ID: <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> On Dec 15, 2007, at 21:39 PM, Chad Woolley wrote: > On Dec 13, 2007 3:43 PM, Eric Hodel wrote: >> On Dec 13, 2007, at 13:37 PM, Eric Hodel wrote: >>> On Dec 11, 2007, at 24:30 AM, Chad Woolley wrote: >>>> >>>> Is this a bug, or am I doing something wrong? >>> >>> You certainly shouldn't get 500s. I'll look into it, but if you can >>> run with --debug it might give a backtrace. >> >> Fixed. > > This is still a problem with the trunk as of right now. Here is my > ruby-debug session, which shows the stack right before I get the > exception. It gets into fetch_single_spec, then blows up looking for > a /quick/Marshal...rz file: > > [...] Can you give me a log of it running without the debug stuff? I need to know what's coming back from the server. Also, your test gems may be useful in tracking this down. I added some code that'll make RubyGems give a little more information when retrieval of files raises an error. Be sure to have revision 1550 or newer. For what it's worth, I'm not having any problems with `gem server` out of trunk: $ sudo ruby -Ilib bin/gem sources --clear Password: *** Removed user source cache *** *** Removed system source cache *** $ rm -r ~/tmp/gems $ ruby -Ilib bin/gem install -i ~/tmp/gems --source http://localhost:8808 ruby2ruby Updating metadata for 16 gems from http://localhost:8808 ................ complete Successfully installed rubyforge-0.4.4 Successfully installed rake-0.7.3 Successfully installed hoe-1.3.0 Successfully installed RubyInline-3.6.5 Successfully installed ParseTree-2.0.2 Successfully installed ruby2ruby-1.1.7 6 gems installed [ri/rdoc installation follows] I was also successful installing using 0.9.4, minus a few bugs that are present in 0.9.4. The server was run as: $ ruby -Ilib bin/gem server Starting gem server on http://localhost:8808/ [GET/HEAD requests, all 200] From drbrain at segment7.net Sun Dec 16 05:16:01 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 16 Dec 2007 02:16:01 -0800 Subject: [Rubygems-developers] Question on GEM_PATH In-Reply-To: References: Message-ID: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> On Dec 15, 2007, at 23:05 PM, Chad Woolley wrote: > When I use GEM_PATH to add an additional local repository to be used, > what dirs must be in that repository? gems? specifications? docs? > cache? others? The directory doesn't even need to exist. RubyGems will create it and everything it needs inside it when you reference it, provided you have permission to do so. > Also, a related question. If I have a source checkout of a gem > locally, can I somehow put it on my GEM_PATH to be loaded, even if it > doesn't follow the standard repository layout? The use case would be > to perform updates on a dependency gem, and have those updates > immediately usable by a separate local app, without having to actually > do the step to build and install the gem to a local repository. I use two tricks for this. The frequently-used trick is to add the paths for the various dependencies to the -I flag while working on the other dependent project. RUBYLIB can also accomplish this. The hardly-used trick is hoe's install_gem task. Adding a way to load gems w/o being in a gem has been brought up before, and I rejected the feature. It's much simpler to use -I or RUBYLIB than to add a bunch of code to RubyGems to accomplish the same end. From luislavena at gmail.com Sun Dec 16 07:25:14 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 16 Dec 2007 09:25:14 -0300 Subject: [Rubygems-developers] RubyGems 1.0 release soon In-Reply-To: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> References: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> Message-ID: <71166b3b0712160425r735285b5pb557d624f97a1126@mail.gmail.com> On Dec 16, 2007 12:35 AM, Eric Hodel wrote: > I cleaned up a bunch of bugs that arrived with 0.9.5, and would like > to do a 1.0 release of RubyGems Monday or Tuesday. > > I forwarded one Windows-releated bug to Luis Lavena, but maybe > somebody else can help? > > http://rubyforge.org/tracker/index.php?func=detail&aid=16259&group_id=126&atid=575 > Just replied on tracker about it, need to figure out a clean solution for it. > Are there any other outstanding issues or important bugs that should > be fixed in the tracker? Or bugs that didn't make it into the tracker? > I'll give a mingw32 a whirl too since MinGW will became a option for upcoming RubyInstaller (OneClick). There is also the problem with binaries (executables) in /bin, they are being overwritten to add the shebang to them. Take a look at the rmagick win32 gem, they have 4 windows executables there than when installed, get replaced by just the shebang, rendering them useless. > I think think all the unfixed bugs in the tracker can wait until a > future release. > > http://rubyforge.org/tracker/?atid=575&group_id=126&func=browse The only upstanding bug I see there is this: http://rubyforge.org/tracker/index.php?func=detail&aid=15790&group_id=126&atid=575 Which was marked by you as 'accepted'. I'll also add this to my test loop today. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From luislavena at gmail.com Sun Dec 16 08:10:23 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 16 Dec 2007 10:10:23 -0300 Subject: [Rubygems-developers] ConfigMap issues Message-ID: <71166b3b0712160510u7a2c5e79m965ed192c034f594@mail.gmail.com> Hey List, it seems that the new 'defaults' functionality is broken: $ rake test 1) Failure: test_self_default_exec_format(TestGem) [./test/test_gem.rb:123]: <"j%s"> expected but was <"%s">. This is testing Jruby default_exec_format, but its failing. The test is overwriting Config::CONFIG based values for BASERUBY and RUBY_INSTALL_NAME, but those are ignored by Gem.default_exec_format since it's using ConfigMap (which was already initialized with the values form RbConfig). Conclusion: it has no effect. Since rbconfig is already 'required' by Gem, should defaults be using it all the time? or should be a better "reload!" functionality for it? (or in any case, overwrite them instead of RbConfig for the indicated test). Just a thought. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From thewoolleyman at gmail.com Sun Dec 16 15:20:14 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 16 Dec 2007 13:20:14 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: On Dec 16, 2007 2:59 AM, Eric Hodel wrote: > Can you give me a log of it running without the debug stuff? I need > to know what's coming back from the server. Also, your test gems may > be useful in tracking this down. test gem dir is available from svn at [1] gem server command and output at [2] gem list command and output at [3] [1] http://geminstaller.rubyforge.org/svn/tags/rel_0.2.4/spec/fixture/gems/ [2] chadmac:~/workspace/rubygems woolley$ ruby -llib bin/gem server --dir=/Users/woolley/svk-checkouts/geminstaller/spec/fixture/gems/ --port=9909 Starting gem server on http://localhost:9909/ 127.0.0.1 - - [16/Dec/2007:13:16:44 MST] "HEAD /Marshal.4.8 HTTP/1.1" 200 0 - -> /Marshal.4.8 127.0.0.1 - - [16/Dec/2007:13:16:45 MST] "GET /quick/index.rz HTTP/1.1" 200 100 - -> /quick/index.rz 127.0.0.1 - - [16/Dec/2007:13:16:45 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 65 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:45 MST] "GET /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 65 - -> /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:45 MST] "GET /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 52 - -> /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:45 MST] "GET /quick/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 52 - -> /quick/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz HTTP/1.1" 200 414 - -> /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 200 428 - -> /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 500 56 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 500 56 - -> /quick/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 500 56 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 500 56 - -> /quick/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:46 MST] "GET /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 42 - -> /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:47 MST] "GET /quick/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 42 - -> /quick/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:47 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 75 - -> /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [16/Dec/2007:13:16:47 MST] "GET /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 75 - -> /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz [3] chadmac:~/workspace/rubygems woolley$ rm -rf ~/.gem; sudo ruby -Ilib bin/gem sources --clear; ruby bin/gem list --remote --source=http://localhost:9909 *** Removed user source cache *** *** Removed system source cache *** *** REMOTE GEMS *** Updating metadata for 8 gems from http://localhost:9909 Failed to download spec stubgem-multiplatform-1.0.1-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz No gems found matching stubgem-multiplatform-1.0.1-x86-mswin32 60 Failed to download spec dependent-stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/dependent-stubgem-1.0.0.gemspec.rz Multiple gems found matching dependent-stubgem 1.0.0 ..Failed to download spec stubgem-multiplatform-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.0.gemspec.rz Multiple gems found matching stubgem-multiplatform 1.0.0 Failed to download spec stubgem-multiplatform-1.0.1 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1.gemspec.rz Multiple gems found matching stubgem-multiplatform 1.0.1 Failed to download spec stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-1.0.0.gemspec.rz Multiple gems found matching stubgem 1.0.0 Failed to download spec dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz No gems found matching dependent-stubgem-multiplatform-1.0.0-x86-mswin32 60 complete dependent-stubgem-depends-on-multiplatform (1.0.0) dependent-stubgem-multilevel (1.0.0) From thewoolleyman at gmail.com Sun Dec 16 15:33:48 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 16 Dec 2007 13:33:48 -0700 Subject: [Rubygems-developers] Question on GEM_PATH In-Reply-To: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> References: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> Message-ID: On Dec 16, 2007 3:16 AM, Eric Hodel wrote: > On Dec 15, 2007, at 23:05 PM, Chad Woolley wrote: > > When I use GEM_PATH to add an additional local repository to be used, > > what dirs must be in that repository? gems? specifications? docs? > > cache? others? > > The directory doesn't even need to exist. RubyGems will create it and > everything it needs inside it when you reference it, provided you have > permission to do so. I meant when I was reading an already-existing gem out of a repo on GEM_PATH, with the 'gem' method. What dirs does this require the gem to be in? just 'gem' and 'specifications', or more? > > Also, a related question. If I have a source checkout of a gem > > locally, can I somehow put it on my GEM_PATH to be loaded, even if it > > doesn't follow the standard repository layout? The use case would be > > to perform updates on a dependency gem, and have those updates > > immediately usable by a separate local app, without having to actually > > do the step to build and install the gem to a local repository. > > I use two tricks for this. > > The frequently-used trick is to add the paths for the various > dependencies to the -I flag while working on the other dependent > project. RUBYLIB can also accomplish this. OK, that works, but it requires intimate knowledge of the dependency gem. It would be nice to have some method like 'gem' that parsed a spec and loaded the references for you. > > The hardly-used trick is hoe's install_gem task. hehe, that's what I use. It's simple, but I want to skip even that step. > > Adding a way to load gems w/o being in a gem has been brought up > before, and I rejected the feature. It's much simpler to use -I or > RUBYLIB than to add a bunch of code to RubyGems to accomplish the same > end. I can understand that, and it's not too hard to use -l if you know what you need. It's just harder if someone doesn't know exactly how to do this, but I could write my own logic to do it. The scenario I'm thinking of is if we package our company's common code as gems instead of plugins (piston/svn externals). plugins are easy to hack-in-place. If we used gems instead, the -l step or installing gems would be (perceived by some as) much harder than just using plugins. Anyway, Thanks for the response. -- Chad From drbrain at segment7.net Mon Dec 17 00:03:02 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 16 Dec 2007 21:03:02 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: On Dec 16, 2007, at 12:20 PM, Chad Woolley wrote: > Failed to download spec stubgem-multiplatform-1.0.1-x86-mswin32-60 > from http://localhost:9909: > OpenURI::HTTPError: 404 Not Found reading > http://localhost:9909/quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz > No gems found matching stubgem-multiplatform-1.0.1-x86- > mswin32 60 I should be able to reproduce from this, thanks. From luislavena at gmail.com Mon Dec 17 06:04:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 17 Dec 2007 08:04:36 -0300 Subject: [Rubygems-developers] Still issues with mswin32 as platform Message-ID: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> Hello Guys, I'm sad to inform that latest test with trunk (revision 1551) still fails with gems that uses 'mswin32' platform. To better show the problem, uploaded a video to google: http://video.google.com/videoplay?docid=-5029229715132035200&hl=en I think google made the video quality low, so currently I'm uploading it to my host and will post a followup with the link (less than 1 hour). Is hard to explain the behavior of 0.9.5 compared to 0.9.4, so I thought a video will make it more clear. During this "screen cast" found that a lot of gems (not just Mongrel) uses 'mswin32' as platform instead of CURRENT, which will be broken if 0.9.5 made into 1.0 "as-is". Guys, I need some help on this, since is quite complex to attack all the variables in this equation without comments from other users. Thanks in advance for the comments, suggestions or thoughts. PS: I made a few text mistakes in the video, please excuse my poor english. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From luislavena at gmail.com Mon Dec 17 07:13:15 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 17 Dec 2007 09:13:15 -0300 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> Message-ID: <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> On Dec 17, 2007 8:04 AM, Luis Lavena wrote: > Hello Guys, > > I'm sad to inform that latest test with trunk (revision 1551) still > fails with gems that uses 'mswin32' platform. > > To better show the problem, uploaded a video to google: > > http://video.google.com/videoplay?docid=-5029229715132035200&hl=en > > I think google made the video quality low, so currently I'm uploading > it to my host and will post a followup with the link (less than 1 > hour). > The higher resolution videos: http://mmediasys.com/rubygems/rubygems_behavior-2.mp4 (12MB) http://mmediasys.com/rubygems/rubygems_behavior-2.mov (112MB) Still need to check what codecs works cross platform, and also it seems QT7 Animation codec don't work so well on windows :-P -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From drbrain at segment7.net Mon Dec 17 17:03:08 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 14:03:08 -0800 Subject: [Rubygems-developers] ConfigMap issues In-Reply-To: <71166b3b0712160510u7a2c5e79m965ed192c034f594@mail.gmail.com> References: <71166b3b0712160510u7a2c5e79m965ed192c034f594@mail.gmail.com> Message-ID: <557442AB-9E0D-4C3B-923C-F0497B9A23FE@segment7.net> On Dec 16, 2007, at 05:10 AM, Luis Lavena wrote: > Hey List, > > it seems that the new 'defaults' functionality is broken: > > $ rake test > 1) Failure: > test_self_default_exec_format(TestGem) [./test/test_gem.rb:123]: > <"j%s"> expected but was > <"%s">. > > This is testing Jruby default_exec_format, but its failing. > > The test is overwriting Config::CONFIG based values for BASERUBY and > RUBY_INSTALL_NAME, but those are ignored by Gem.default_exec_format > since it's using ConfigMap (which was already initialized with the > values form RbConfig). > > Conclusion: it has no effect. > > Since rbconfig is already 'required' by Gem, should defaults be using > it all the time? or should be a better "reload!" functionality for it? > (or in any case, overwrite them instead of RbConfig for the indicated > test). Fixed. I'm filling in ConfigMap correctly now. From drbrain at segment7.net Mon Dec 17 17:04:47 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 14:04:47 -0800 Subject: [Rubygems-developers] RubyGems 1.0 release soon In-Reply-To: <71166b3b0712160425r735285b5pb557d624f97a1126@mail.gmail.com> References: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> <71166b3b0712160425r735285b5pb557d624f97a1126@mail.gmail.com> Message-ID: On Dec 16, 2007, at 04:25 AM, Luis Lavena wrote: > On Dec 16, 2007 12:35 AM, Eric Hodel wrote: >> I cleaned up a bunch of bugs that arrived with 0.9.5, and would like >> to do a 1.0 release of RubyGems Monday or Tuesday. >> >> I forwarded one Windows-releated bug to Luis Lavena, but maybe >> somebody else can help? >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=16259&group_id=126&atid=575 >> > > Just replied on tracker about it, need to figure out a clean > solution for it. Thanks >> Are there any other outstanding issues or important bugs that should >> be fixed in the tracker? Or bugs that didn't make it into the >> tracker? > > I'll give a mingw32 a whirl too since MinGW will became a option for > upcoming RubyInstaller (OneClick). > > There is also the problem with binaries (executables) in /bin, > they are being overwritten to add the shebang to them. > > Take a look at the rmagick win32 gem, they have 4 windows executables > there than when installed, get replaced by just the shebang, rendering > them useless. 1555 should fix this. From drbrain at segment7.net Mon Dec 17 17:09:11 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 14:09:11 -0800 Subject: [Rubygems-developers] Question on GEM_PATH In-Reply-To: References: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> Message-ID: <4D8D5890-57D7-4C24-B74A-81E51282A78D@segment7.net> On Dec 16, 2007, at 12:33 PM, Chad Woolley wrote: > On Dec 16, 2007 3:16 AM, Eric Hodel wrote: >> On Dec 15, 2007, at 23:05 PM, Chad Woolley wrote: >>> When I use GEM_PATH to add an additional local repository to be >>> used, >>> what dirs must be in that repository? gems? specifications? docs? >>> cache? others? >> >> The directory doesn't even need to exist. RubyGems will create it >> and >> everything it needs inside it when you reference it, provided you >> have >> permission to do so. > > I meant when I was reading an already-existing gem out of a repo on > GEM_PATH, with the 'gem' method. What dirs does this require the gem > to be in? just 'gem' and 'specifications', or more? For require to work you need: gems/ is where the files go specifications/.gemspec is where a Ruby gemspec goes From drbrain at segment7.net Mon Dec 17 18:33:28 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 15:33:28 -0800 Subject: [Rubygems-developers] RubyGems 1.0 release soon In-Reply-To: <71166b3b0712160425r735285b5pb557d624f97a1126@mail.gmail.com> References: <0ECBEA32-30C0-4BDC-B936-25602255E338@segment7.net> <71166b3b0712160425r735285b5pb557d624f97a1126@mail.gmail.com> Message-ID: On Dec 16, 2007, at 04:25 AM, Luis Lavena wrote: > The only upstanding bug I see there is this: > > http://rubyforge.org/tracker/index.php?func=detail&aid=15790&group_id=126&atid=575 > > Which was marked by you as 'accepted'. I think it's ok to let this one wait until a post-1.0 release. It is a minority use-case. From drbrain at segment7.net Mon Dec 17 18:35:06 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 15:35:06 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: On Dec 16, 2007, at 21:03 PM, Eric Hodel wrote: > On Dec 16, 2007, at 12:20 PM, Chad Woolley wrote: >> Failed to download spec stubgem-multiplatform-1.0.1-x86-mswin32-60 >> from http://localhost:9909: >> OpenURI::HTTPError: 404 Not Found reading >> http://localhost:9909/quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz >> No gems found matching stubgem-multiplatform-1.0.1-x86- >> mswin32 60 > > I should be able to reproduce from this, thanks. Fixed. From drbrain at segment7.net Mon Dec 17 20:25:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 17:25:23 -0800 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> Message-ID: On Dec 17, 2007, at 04:13 AM, Luis Lavena wrote: > On Dec 17, 2007 8:04 AM, Luis Lavena wrote: >> Hello Guys, >> >> I'm sad to inform that latest test with trunk (revision 1551) still >> fails with gems that uses 'mswin32' platform. >> >> To better show the problem, uploaded a video to google: >> >> http://video.google.com/videoplay?docid=-5029229715132035200&hl=en >> >> I think google made the video quality low, so currently I'm uploading >> it to my host and will post a followup with the link (less than 1 >> hour). >> > > The higher resolution videos: > > http://mmediasys.com/rubygems/rubygems_behavior-2.mp4 (12MB) > http://mmediasys.com/rubygems/rubygems_behavior-2.mov (112MB) > > Still need to check what codecs works cross platform, and also it > seems QT7 Animation codec don't work so well on windows :-P At 04:11, where `gem install pkg\...` doesn't work, but `cd pkg; gem install ...` works may be due to Dir glob usage in lib/rubygems/ dependency_installer.rb:54 Does Dir['pkg\*'] work properly in Windows from irb? Does `gem install pkg/...` work? 07:13: > Gem::Platform::WIN32 is badly broken. (for peace of mind, why don't > we remove it?) Agreed. If I recall correctly, the WIN32 constant is only needed by gem authors, so having a missing constant will force them to switch to CURRENT. I will do the same with the remaining constants, and add a const_missing that tells gem authors how to upgrade. 07:16: > Gem::Platform::CURRENT work as expected, leave it alone. (and warn > all rubygems developers to stick to it!) Yes. From thewoolleyman at gmail.com Mon Dec 17 21:14:03 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 17 Dec 2007 19:14:03 -0700 Subject: [Rubygems-developers] Question on GEM_PATH In-Reply-To: <4D8D5890-57D7-4C24-B74A-81E51282A78D@segment7.net> References: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> <4D8D5890-57D7-4C24-B74A-81E51282A78D@segment7.net> Message-ID: On Dec 17, 2007 3:09 PM, Eric Hodel wrote: > On Dec 16, 2007, at 12:33 PM, Chad Woolley wrote: > > I meant when I was reading an already-existing gem out of a repo on > > GEM_PATH, with the 'gem' method. What dirs does this require the gem > > to be in? just 'gem' and 'specifications', or more? > > For require to work you need: > > gems/ is where the files go > specifications/.gemspec is where a Ruby gemspec goes Thanks for verifying that... From thewoolleyman at gmail.com Mon Dec 17 21:14:03 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 17 Dec 2007 19:14:03 -0700 Subject: [Rubygems-developers] Question on GEM_PATH In-Reply-To: <4D8D5890-57D7-4C24-B74A-81E51282A78D@segment7.net> References: <1ACBC952-C871-49CC-8AF1-B2C2E122C865@segment7.net> <4D8D5890-57D7-4C24-B74A-81E51282A78D@segment7.net> Message-ID: On Dec 17, 2007 3:09 PM, Eric Hodel wrote: > On Dec 16, 2007, at 12:33 PM, Chad Woolley wrote: > > I meant when I was reading an already-existing gem out of a repo on > > GEM_PATH, with the 'gem' method. What dirs does this require the gem > > to be in? just 'gem' and 'specifications', or more? > > For require to work you need: > > gems/ is where the files go > specifications/.gemspec is where a Ruby gemspec goes Thanks for verifying that... From luislavena at gmail.com Mon Dec 17 21:20:34 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 17 Dec 2007 23:20:34 -0300 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> Message-ID: <71166b3b0712171820u35ea135ehdbf9b4985d0a40b0@mail.gmail.com> On Dec 17, 2007 10:25 PM, Eric Hodel wrote: > > > > The higher resolution videos: > > > > http://mmediasys.com/rubygems/rubygems_behavior-2.mp4 (12MB) > > http://mmediasys.com/rubygems/rubygems_behavior-2.mov (112MB) > > > > Still need to check what codecs works cross platform, and also it > > seems QT7 Animation codec don't work so well on windows :-P > > At 04:11, where `gem install pkg\...` doesn't work, but `cd pkg; gem > install ...` works may be due to Dir glob usage in lib/rubygems/ > dependency_installer.rb:54 > > Does Dir['pkg\*'] work properly in Windows from irb? > > Does `gem install pkg/...` work? > Yes, also: D:\Users\Luis\projects\_sandbox\test_gem>irb irb(main):001:0> Dir['pkg\*'] => [] irb(main):002:0> Dir['pkg/*'] => ["pkg/test_gem-0.1.0-x86-mswin32-60.gem"] irb(main):003:0> File.expand_path('pkg\*') => "D:/Users/Luis/projects/_sandbox/test_gem/pkg/*" irb(main):004:0> Dir[File.expand_path('pkg/*')] => ["D:/Users/Luis/projects/_sandbox/test_gem/pkg/test_gem-0.1.0-x86-mswin32-60.gem"] Maybe a combination of File.expand_path and Dir.glob could do the trick? Compared to 0.9.4 one change that can break some 'rake gem_install' tasks. > 07:13: > > > Gem::Platform::WIN32 is badly broken. (for peace of mind, why don't > > we remove it?) > > Agreed. If I recall correctly, the WIN32 constant is only needed by > gem authors, so having a missing constant will force them to switch to > CURRENT. > > I will do the same with the remaining constants, and add a > const_missing that tells gem authors how to upgrade. > :-D > 07:16: > > > Gem::Platform::CURRENT work as expected, leave it alone. (and warn > > all rubygems developers to stick to it!) > > Yes. > +1 :-D Thank you for your time Eric. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From thewoolleyman at gmail.com Mon Dec 17 21:32:58 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 17 Dec 2007 19:32:58 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: On Dec 17, 2007 4:35 PM, Eric Hodel wrote: > Fixed. This is getting closer, but there are still a couple of gems that have problems. Also, I had to actually install the trunk version to get it to pick up a couple of them, which seems to indicate that "-I" approach of running a specific version sometimes still uses installed rubygems files. Anyway, here's the output. [1] - server command and output WITHOUT running setup [2] - gem list command and output WITHOUT running setup [3] - server command and output AFTER running setup [4] gem list command and output AFTER running setup Only two of my test gems are still failing in [4]. Thanks for all your work on this... -- Chad [1] chadmac:~/workspace/rubygems woolley$ ruby -llib bin/gem server --dir=/Users/woolley/svk-checkouts/geminstaller/spec/fixture/gems/ --port=9909 Starting gem server on http://localhost:9909/ 127.0.0.1 - - [17/Dec/2007:19:23:55 MST] "HEAD /Marshal.4.8 HTTP/1.1" 200 0 - -> /Marshal.4.8 127.0.0.1 - - [17/Dec/2007:19:23:55 MST] "GET /quick/index.rz HTTP/1.1" 200 100 - -> /quick/index.rz 127.0.0.1 - - [17/Dec/2007:19:23:55 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 65 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:56 MST] "GET /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 65 - -> /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:56 MST] "GET /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 52 - -> /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:56 MST] "GET /quick/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 52 - -> /quick/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:56 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz HTTP/1.1" 200 414 - -> /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:56 MST] "GET /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 200 428 - -> /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:57 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 500 56 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:57 MST] "GET /quick/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 500 56 - -> /quick/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:57 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 500 56 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:58 MST] "GET /quick/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 500 56 - -> /quick/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:58 MST] "GET /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 42 - -> /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:58 MST] "GET /quick/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 42 - -> /quick/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:58 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 75 - -> /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:23:59 MST] "GET /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 404 75 - -> /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz [2] chadmac:~/workspace/rubygems woolley$ rm -rf ~/.gem; sudo ruby -Ilib bin/gem sources --clear; ruby bin/gem list --remote --source=http://localhost:9909 *** Removed user source cache *** *** Removed system source cache *** *** REMOTE GEMS *** Updating metadata for 8 gems from http://localhost:9909 Failed to download spec stubgem-multiplatform-1.0.1-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz No gems found matching stubgem-multiplatform-1.0.1-x86-mswin32 60 Failed to download spec dependent-stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/dependent-stubgem-1.0.0.gemspec.rz Multiple gems found matching dependent-stubgem 1.0.0 ..Failed to download spec stubgem-multiplatform-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.0.gemspec.rz Multiple gems found matching stubgem-multiplatform 1.0.0 Failed to download spec stubgem-multiplatform-1.0.1 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-multiplatform-1.0.1.gemspec.rz Multiple gems found matching stubgem-multiplatform 1.0.1 Failed to download spec stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-1.0.0.gemspec.rz Multiple gems found matching stubgem 1.0.0 Failed to download spec dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60 from http://localhost:9909: OpenURI::HTTPError: 404 Not Found reading http://localhost:9909/quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz No gems found matching dependent-stubgem-multiplatform-1.0.0-x86-mswin32 60 complete dependent-stubgem-depends-on-multiplatform (1.0.0) dependent-stubgem-multilevel (1.0.0) [3] chadmac:~/workspace/rubygems woolley$ ruby -llib bin/gem server --dir=/Users/woolley/svk-checkouts/geminstaller/spec/fixture/gems/ --port=9909 Starting gem server on http://localhost:9909/ 127.0.0.1 - - [17/Dec/2007:19:25:44 MST] "HEAD /Marshal.4.8 HTTP/1.1" 200 0 - -> /Marshal.4.8 127.0.0.1 - - [17/Dec/2007:19:25:44 MST] "GET /quick/index.rz HTTP/1.1" 200 100 - -> /quick/index.rz 127.0.0.1 - - [17/Dec/2007:19:25:45 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 200 638 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:45 MST] "GET /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz HTTP/1.1" 200 638 - -> /quick/stubgem-multiplatform-1.0.1-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:45 MST] "GET /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 60 - -> /quick/Marshal.4.8/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:46 MST] "GET /quick/dependent-stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 60 - -> /quick/dependent-stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:46 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz HTTP/1.1" 200 414 - -> /quick/Marshal.4.8/dependent-stubgem-multilevel-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 200 428 - -> /quick/Marshal.4.8/dependent-stubgem-depends-on-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz HTTP/1.1" 200 396 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz HTTP/1.1" 200 394 - -> /quick/Marshal.4.8/stubgem-multiplatform-1.0.1.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 50 - -> /quick/Marshal.4.8/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/stubgem-1.0.0.gemspec.rz HTTP/1.1" 500 50 - -> /quick/stubgem-1.0.0.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:47 MST] "GET /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 200 663 - -> /quick/Marshal.4.8/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz 127.0.0.1 - - [17/Dec/2007:19:25:48 MST] "GET /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz HTTP/1.1" 200 663 - -> /quick/dependent-stubgem-multiplatform-1.0.0-x86-mswin32-60.gemspec.rz [4] chadmac:~/workspace/rubygems woolley$ rm -rf ~/.gem; sudo ruby -Ilib bin/gem sources --clear; ruby bin/gem list --remote --source=http://localhost:9909 *** Removed user source cache *** *** Removed system source cache *** *** REMOTE GEMS *** Updating metadata for 8 gems from http://localhost:9909 .Failed to download spec dependent-stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/dependent-stubgem-1.0.0.gemspec.rz Multiple gems found matching "dependent-stubgem" "1.0.0" nil ....Failed to download spec stubgem-1.0.0 from http://localhost:9909: OpenURI::HTTPError: 500 Internal Server Error reading http://localhost:9909/quick/stubgem-1.0.0.gemspec.rz Multiple gems found matching "stubgem" "1.0.0" nil . complete dependent-stubgem-depends-on-multiplatform (1.0.0) dependent-stubgem-multilevel (1.0.0) dependent-stubgem-multiplatform (1.0.0) stubgem-multiplatform (1.0.1, 1.0.0) From thewoolleyman at gmail.com Mon Dec 17 22:20:21 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 17 Dec 2007 20:20:21 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: On Dec 17, 2007 7:32 PM, Chad Woolley wrote: > On Dec 17, 2007 4:35 PM, Eric Hodel wrote: > > Fixed. > > This is getting closer, but there are still a couple of gems that have > problems. Also, I had to actually install the trunk version to get it > to pick up a couple of them, which seems to indicate that "-I" > approach of running a specific version sometimes still uses installed > rubygems files. Now that you showed me where the problems are, I came up with a failing test for the remaining problems: def test_quick_a_1_ab_1_gemspec_rz_duplicate_gem_name_substrings_do_not_cause_multiple_gem_errors ab1 = quick_gem 'ab', '1' si = Gem::SourceIndex.new @a1.full_name => @a1, ab1.full_name => ab1 @server.source_index = si data = StringIO.new "GET /quick/a-1.gemspec.rz HTTP/1.0\r\n\r\n" @req.parse data @server.quick @req, @res assert_equal 200, @res.status assert @res['date'] assert_equal 'text/plain', @res['content-type'] yaml = Zlib::Inflate.inflate(@res.body) assert_match %r|Gem::Specification|, yaml assert_match %r|name: a|, yaml assert_match %r|version: "1"|, yaml end I'll try to patch this if you don't beat me to it. Gotta go play with my son now :) -- Chad From drbrain at segment7.net Mon Dec 17 22:23:39 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 19:23:39 -0800 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: <71166b3b0712171820u35ea135ehdbf9b4985d0a40b0@mail.gmail.com> References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> <71166b3b0712171820u35ea135ehdbf9b4985d0a40b0@mail.gmail.com> Message-ID: <85ABA89E-6F91-4160-9C2C-F8CA226D082E@segment7.net> On Dec 17, 2007, at 18:20 PM, Luis Lavena wrote: > On Dec 17, 2007 10:25 PM, Eric Hodel wrote: >>> >>> The higher resolution videos: >>> >>> http://mmediasys.com/rubygems/rubygems_behavior-2.mp4 (12MB) >>> http://mmediasys.com/rubygems/rubygems_behavior-2.mov (112MB) >>> >>> Still need to check what codecs works cross platform, and also it >>> seems QT7 Animation codec don't work so well on windows :-P >> >> At 04:11, where `gem install pkg\...` doesn't work, but `cd pkg; gem >> install ...` works may be due to Dir glob usage in lib/rubygems/ >> dependency_installer.rb:54 >> >> Does Dir['pkg\*'] work properly in Windows from irb? >> >> Does `gem install pkg/...` work? >> > > Yes, also: > > D:\Users\Luis\projects\_sandbox\test_gem>irb > irb(main):001:0> Dir['pkg\*'] > => [] > irb(main):002:0> Dir['pkg/*'] > => ["pkg/test_gem-0.1.0-x86-mswin32-60.gem"] > irb(main):003:0> File.expand_path('pkg\*') > => "D:/Users/Luis/projects/_sandbox/test_gem/pkg/*" > irb(main):004:0> Dir[File.expand_path('pkg/*')] > => ["D:/Users/Luis/projects/_sandbox/test_gem/pkg/test_gem-0.1.0-x86- > mswin32-60.gem"] > > Maybe a combination of File.expand_path and Dir.glob could do the > trick? Compared to 0.9.4 one change that can break some 'rake > gem_install' tasks. Do you think gem_name.gsub(File::ALT_SEPARATOR, File::SEPARATOR) be sufficient? >> 07:13: >> >>> Gem::Platform::WIN32 is badly broken. (for peace of mind, why don't >>> we remove it?) >> >> Agreed. If I recall correctly, the WIN32 constant is only needed by >> gem authors, so having a missing constant will force them to switch >> to >> CURRENT. >> >> I will do the same with the remaining constants, and add a >> const_missing that tells gem authors how to upgrade. > > :-D Ok, committed. From luislavena at gmail.com Mon Dec 17 22:31:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Dec 2007 00:31:02 -0300 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: <85ABA89E-6F91-4160-9C2C-F8CA226D082E@segment7.net> References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> <71166b3b0712171820u35ea135ehdbf9b4985d0a40b0@mail.gmail.com> <85ABA89E-6F91-4160-9C2C-F8CA226D082E@segment7.net> Message-ID: <71166b3b0712171931p47f38297s7d80f9bd8484e3b6@mail.gmail.com> On Dec 18, 2007 12:23 AM, Eric Hodel wrote: > > > > Maybe a combination of File.expand_path and Dir.glob could do the > > trick? Compared to 0.9.4 one change that can break some 'rake > > gem_install' tasks. > > Do you think gem_name.gsub(File::ALT_SEPARATOR, File::SEPARATOR) be > sufficient? > Oh man, this is a priceless moment: my suggestion was plain stupid. You're right, but that will not work under *nix / posix platforms since File::ALT_SEPARATOR is nil (and gsub specs a regex), so: gem_name.gsub(File::ALT_SEPARATOR, File::SEPARATOR) if File::ALT_SEPARATOR ?? I'll check how to solve the gem stub scripts being put outside ruby/bin folder tonight. Thank you for your time. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From drbrain at segment7.net Mon Dec 17 22:43:49 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 19:43:49 -0800 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: References: <408E81AF-B630-4720-BF7C-8EA70A2A07A1@segment7.net> <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> Message-ID: <8EC4388F-4F55-4BA2-8E10-DAFAA2A6BF46@segment7.net> On Dec 17, 2007, at 19:20 PM, Chad Woolley wrote: > On Dec 17, 2007 7:32 PM, Chad Woolley wrote: >> On Dec 17, 2007 4:35 PM, Eric Hodel wrote: >>> Fixed. >> >> This is getting closer, but there are still a couple of gems that >> have >> problems. Also, I had to actually install the trunk version to get >> it >> to pick up a couple of them, which seems to indicate that "-I" >> approach of running a specific version sometimes still uses installed >> rubygems files. > > Now that you showed me where the problems are, I came up with a > failing test for the remaining problems: > > def > test_quick_a_1_ab_1_gemspec_rz_duplicate_gem_name_substrings_do_not_cause_multiple_gem_errors > ab1 = quick_gem 'ab', '1' > si = Gem::SourceIndex.new @a1.full_name => @a1, ab1.full_name => > ab1 > @server.source_index = si > > data = StringIO.new "GET /quick/a-1.gemspec.rz HTTP/1.0\r\n\r\n" > @req.parse data > > @server.quick @req, @res > > assert_equal 200, @res.status > assert @res['date'] > assert_equal 'text/plain', @res['content-type'] > yaml = Zlib::Inflate.inflate(@res.body) > assert_match %r|Gem::Specification|, yaml > assert_match %r|name: a|, yaml > assert_match %r|version: "1"|, yaml > end > > I'll try to patch this if you don't beat me to it. Gotta go play with > my son now :) Perfect. Try r1558. From drbrain at segment7.net Mon Dec 17 22:47:28 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 17 Dec 2007 19:47:28 -0800 Subject: [Rubygems-developers] Still issues with mswin32 as platform In-Reply-To: <71166b3b0712171931p47f38297s7d80f9bd8484e3b6@mail.gmail.com> References: <71166b3b0712170304o25728312s87f129d97730ca3f@mail.gmail.com> <71166b3b0712170413h13f2efbci4b0cb9b61ab6f7eb@mail.gmail.com> <71166b3b0712171820u35ea135ehdbf9b4985d0a40b0@mail.gmail.com> <85ABA89E-6F91-4160-9C2C-F8CA226D082E@segment7.net> <71166b3b0712171931p47f38297s7d80f9bd8484e3b6@mail.gmail.com> Message-ID: <33C481A6-5226-498D-A455-5A1DA7B190FA@segment7.net> On Dec 17, 2007, at 19:31 PM, Luis Lavena wrote: > On Dec 18, 2007 12:23 AM, Eric Hodel wrote: >>> >>> Maybe a combination of File.expand_path and Dir.glob could do the >>> trick? Compared to 0.9.4 one change that can break some 'rake >>> gem_install' tasks. >> >> Do you think gem_name.gsub(File::ALT_SEPARATOR, File::SEPARATOR) be >> sufficient? >> > > Oh man, this is a priceless moment: my suggestion was plain stupid. > > You're right, but that will not work under *nix / posix platforms > since File::ALT_SEPARATOR is nil (and gsub specs a regex), so: > > gem_name.gsub(File::ALT_SEPARATOR, File::SEPARATOR) if > File::ALT_SEPARATOR > > ?? Of course, if File::ALT_SEPARATOR. Committed in r1559. > I'll check how to solve the gem stub scripts being put outside > ruby/bin folder tonight. > > Thank you for your time. And thanks for yours! From thewoolleyman at gmail.com Mon Dec 17 22:56:02 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 17 Dec 2007 20:56:02 -0700 Subject: [Rubygems-developers] gem server problems in 0.9.5 In-Reply-To: <8EC4388F-4F55-4BA2-8E10-DAFAA2A6BF46@segment7.net> References: <77D1AB2D-8576-407F-AE58-FFA8185694A4@segment7.net> <96635972-486D-44AF-BD77-B9946D30217B@segment7.net> <8EC4388F-4F55-4BA2-8E10-DAFAA2A6BF46@segment7.net> Message-ID: On Dec 17, 2007 8:43 PM, Eric Hodel wrote: > Perfect. Try r1558. Great! Everything works fine now. I still had to do an install to pick up the new server code, but that's a separate issue. From luislavena at gmail.com Tue Dec 18 02:29:03 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Dec 2007 04:29:03 -0300 Subject: [Rubygems-developers] Loose end: mirror on Windows Message-ID: <71166b3b0712172329l10e95703n549640261cdc12f2@mail.gmail.com> Guys, Couldn't check all the ends and pieces of RubyGems on Windows yet (is monday, week day) :-P Anyway, gem mirror was failing when trying to mirror a file:/// URI, which is the test case URI.parse is broken for Windows, drive letters are still inside it: irb(main):001:0> require 'uri' => true irb(main):002:0> URI.parse Dir.pwd => # irb(main):003:0> URI.parse "file://#{Dir.pwd}" => # irb(main):004:0> URI.parse "file:///#{Dir.pwd}" => # irb(main):005:0> URI.parse("file:///#{Dir.pwd}").to_s => "file:/D:/Users/Luis" The included patch check with a regex if get_from contains a drive letter (only if scheme is file) and grab the correct part of it. I need to check the --source option of install, list and others to see them working properly. I noticed this reading the mails from Chad and Eric about gem server... Good nights everyone. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams -------------- next part -------------- A non-text attachment was scrubbed... Name: mirror_command-ignores-file-scheme-under-windows.patch Type: application/octet-stream Size: 1408 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071218/2098faa9/attachment.obj From drbrain at segment7.net Tue Dec 18 04:01:33 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 18 Dec 2007 01:01:33 -0800 Subject: [Rubygems-developers] Loose end: mirror on Windows In-Reply-To: <71166b3b0712172329l10e95703n549640261cdc12f2@mail.gmail.com> References: <71166b3b0712172329l10e95703n549640261cdc12f2@mail.gmail.com> Message-ID: On Dec 17, 2007, at 23:29 PM, Luis Lavena wrote: > Guys, > > Couldn't check all the ends and pieces of RubyGems on Windows yet (is > monday, week day) :-P > > Anyway, gem mirror was failing when trying to mirror a file:/// URI, > which is the test case > > URI.parse is broken for Windows, drive letters are still inside it: > > irb(main):001:0> require 'uri' > => true > irb(main):002:0> URI.parse Dir.pwd > => # > irb(main):003:0> URI.parse "file://#{Dir.pwd}" > => # > irb(main):004:0> URI.parse "file:///#{Dir.pwd}" > => # > irb(main):005:0> URI.parse("file:///#{Dir.pwd}").to_s > => "file:/D:/Users/Luis" > > The included patch check with a regex if get_from contains a drive > letter (only if scheme is file) and grab the correct part of it. Please commit, and update the ChangeLog too. > I need to check the --source option of install, list and others to see > them working properly. Ok. From luislavena at gmail.com Tue Dec 18 04:17:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Dec 2007 06:17:02 -0300 Subject: [Rubygems-developers] Loose end: mirror on Windows In-Reply-To: References: <71166b3b0712172329l10e95703n549640261cdc12f2@mail.gmail.com> Message-ID: <71166b3b0712180117k40451de2h4fe335ce41902de5@mail.gmail.com> On Dec 18, 2007 6:01 AM, Eric Hodel wrote: > On Dec 17, 2007, at 23:29 PM, Luis Lavena wrote: > > [...] > > The included patch check with a regex if get_from contains a drive > > letter (only if scheme is file) and grab the correct part of it. > > Please commit, and update the ChangeLog too. > Done. I forgot you added me as developer :-) Have a nice day. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From thewoolleyman at gmail.com Tue Dec 18 06:51:45 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 18 Dec 2007 04:51:45 -0700 Subject: [Rubygems-developers] possible bug in doc_manager.rb Message-ID: NOTE: this may be Ruby 1.8.5 specific. In my tests which exercise gem installation, I'm getting errors like this: uninitialized constant RubyToken::AlreadyDefinedToken This is occurring from Gem::DocManager#load_rdoc, where it does: require 'rdoc/rdoc' I get this same error when I try this require in IRB, on multiple platforms using ruby 1.8.5: irb(main):001:0> require 'rdoc/rdoc' /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:31: warning: already initialized constant EXPR_BEG /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:32: warning: already initialized constant EXPR_MID /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:33: warning: already initialized constant EXPR_END /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:34: warning: already initialized constant EXPR_ARG /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:35: warning: already initialized constant EXPR_FNAME /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:36: warning: already initialized constant EXPR_DOT /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:37: warning: already initialized constant EXPR_CLASS /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:262: warning: already initialized constant TokenDefinitions /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:267: warning: already initialized constant TkReading2Token /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:268: warning: already initialized constant TkSymbol2Token NameError: uninitialized constant RubyToken::AlreadyDefinedToken from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:273:in `def_token' from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:300 from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:299:in `each' from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:299 from /usr/local/lib/ruby/1.8/rdoc/rdoc.rb:8:in `require' from /usr/local/lib/ruby/1.8/rdoc/rdoc.rb:8 from (irb):1:in `require' from (irb):1 I'm not sure if this is a bug in rubygems, or if I am missing a prerequisite require since I'm invoking gem installation programatically. This require has been around forever, but there have been some recent refactorings to doc_manager... Thanks, -- Chad From drbrain at segment7.net Tue Dec 18 15:02:42 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 18 Dec 2007 12:02:42 -0800 Subject: [Rubygems-developers] possible bug in doc_manager.rb In-Reply-To: References: Message-ID: <66D3E863-21BF-4C74-9A55-E168FB54F206@segment7.net> On Dec 18, 2007, at 03:51 AM, Chad Woolley wrote: > NOTE: this may be Ruby 1.8.5 specific. In my tests which exercise gem > installation, I'm getting errors like this: > > uninitialized constant RubyToken::AlreadyDefinedToken > > This is occurring from Gem::DocManager#load_rdoc, where it does: > > require 'rdoc/rdoc' > > I get this same error when I try this require in IRB, on multiple > platforms using ruby 1.8.5: > > irb(main):001:0> require 'rdoc/rdoc' > [...] > NameError: uninitialized constant RubyToken::AlreadyDefinedToken > from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:273:in > `def_token' > from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:300 > from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:299:in > `each' > from /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:299 > from /usr/local/lib/ruby/1.8/rdoc/rdoc.rb:8:in `require' > from /usr/local/lib/ruby/1.8/rdoc/rdoc.rb:8 > from (irb):1:in `require' > from (irb):1 > > > I'm not sure if this is a bug in rubygems, or if I am missing a > prerequisite require since I'm invoking gem installation > programatically. This require has been around forever, but there have > been some recent refactorings to doc_manager... Do you get the same without irb? Since RDoc uses a bunch of irb code, the two may be incompatible. From thewoolleyman at gmail.com Tue Dec 18 16:02:47 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 18 Dec 2007 14:02:47 -0700 Subject: [Rubygems-developers] possible bug in doc_manager.rb In-Reply-To: <66D3E863-21BF-4C74-9A55-E168FB54F206@segment7.net> References: <66D3E863-21BF-4C74-9A55-E168FB54F206@segment7.net> Message-ID: On Dec 18, 2007 1:02 PM, Eric Hodel wrote: > Do you get the same without irb? Since RDoc uses a bunch of irb code, > the two may be incompatible. You are right. It only happens if you require 'irb' first. Nonetheless, I don't think I'm explicitly requiring IRB, so maybe one of the recent rubygems refactorings is picking up IRB first, directly or indirectly? I'll keep looking... From thewoolleyman at gmail.com Tue Dec 18 16:13:20 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 18 Dec 2007 14:13:20 -0700 Subject: [Rubygems-developers] possible bug in doc_manager.rb In-Reply-To: References: <66D3E863-21BF-4C74-9A55-E168FB54F206@segment7.net> Message-ID: On Dec 18, 2007 2:02 PM, Chad Woolley wrote: > On Dec 18, 2007 1:02 PM, Eric Hodel wrote: > > Do you get the same without irb? Since RDoc uses a bunch of irb code, > > the two may be incompatible. > > You are right. It only happens if you require 'irb' first. > Nonetheless, I don't think I'm explicitly requiring IRB, so maybe one > of the recent rubygems refactorings is picking up IRB first, directly > or indirectly? I'll keep looking... > OK, this was my fault. I had added a require for ruby-debug, which apparently requires irb, which makes everything blow up. Thanks for the tip to look at IRB. --Chad From thewoolleyman at gmail.com Wed Dec 19 05:32:49 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Dec 2007 03:32:49 -0700 Subject: [Rubygems-developers] executable wrapper not working for some gems? Message-ID: Not sure if this is a problem with the rubygems trunk or not, but reporting anyway... When I install the rspec 1.1.1 gem using rubygems trunk, the 'spec' binary in /usr/local/bin/spec doesn't have the rubygems wrapper code. In other words, it is exactly the same as the rspec source executable, without the shebang or require 'rubygems', etc. I tried another gem (geminstaller) and it did get the exec wrapper generated correctly, so not sure what's up, if this is a rubygems or an rspec problem. This was with the latest trunk rubygems, on mac. Thanks, Chad From drbrain at segment7.net Wed Dec 19 05:45:40 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Dec 2007 02:45:40 -0800 Subject: [Rubygems-developers] executable wrapper not working for some gems? In-Reply-To: References: Message-ID: <9C714CCA-78F6-4E01-A80B-07ACA5B3CAAD@segment7.net> On Dec 19, 2007, at 02:32 AM, Chad Woolley wrote: > Not sure if this is a problem with the rubygems trunk or not, but > reporting anyway... > > When I install the rspec 1.1.1 gem using rubygems trunk, the 'spec' > binary in /usr/local/bin/spec doesn't have the rubygems wrapper code. > In other words, it is exactly the same as the rspec source executable, > without the shebang or require 'rubygems', etc. > > I tried another gem (geminstaller) and it did get the exec wrapper > generated correctly, so not sure what's up, if this is a rubygems or > an rspec problem. > > This was with the latest trunk rubygems, on mac. I added code to omit the wrapper for files that don't have a #! line. spec doesn't have one of these. I think I will roll back this change, and add some code to Gem::Builder to complain about such files for now. From drbrain at segment7.net Wed Dec 19 05:48:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Dec 2007 02:48:05 -0800 Subject: [Rubygems-developers] executable wrapper not working for some gems? In-Reply-To: <9C714CCA-78F6-4E01-A80B-07ACA5B3CAAD@segment7.net> References: <9C714CCA-78F6-4E01-A80B-07ACA5B3CAAD@segment7.net> Message-ID: <7FCE5C40-15DA-4CE5-9E30-71DD3B6703A9@segment7.net> On Dec 19, 2007, at 02:45 AM, Eric Hodel wrote: > On Dec 19, 2007, at 02:32 AM, Chad Woolley wrote: >> Not sure if this is a problem with the rubygems trunk or not, but >> reporting anyway... >> >> When I install the rspec 1.1.1 gem using rubygems trunk, the 'spec' >> binary in /usr/local/bin/spec doesn't have the rubygems wrapper code. >> In other words, it is exactly the same as the rspec source >> executable, >> without the shebang or require 'rubygems', etc. >> >> I tried another gem (geminstaller) and it did get the exec wrapper >> generated correctly, so not sure what's up, if this is a rubygems or >> an rspec problem. >> >> This was with the latest trunk rubygems, on mac. > > I added code to omit the wrapper for files that don't have a #! line. > spec doesn't have one of these. > > I think I will roll back this change, and add some code to > Gem::Builder to complain about such files for now. I filed a bug with rspec: http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/197-bin-spec-missing-line From thewoolleyman at gmail.com Wed Dec 19 06:37:34 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Dec 2007 04:37:34 -0700 Subject: [Rubygems-developers] problems with gem server source_cache Message-ID: Hi, I think there are still some problems with platform handling in gem server. Now, when I start a local server, I can see the /quick/* showing all the test gems for all platforms. However, when I cat the source_cache, I only see a couple of gems with the 'ruby' platform, and grepping for 'mswin' shows nothing. When I try to install a different-platform gem (mswin32 on mac) from this server, it fails - I believe because it's not found in the cache. gem list does seem to show everything, it's just install that doesn't find the mswin32 gem. Not sure how to explain it better, I can show you my failing test or provide more debug info. Thanks, Chad From thewoolleyman at gmail.com Wed Dec 19 06:40:47 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Dec 2007 04:40:47 -0700 Subject: [Rubygems-developers] can't uninstall mswin gem from mac Message-ID: I installed a mswin32 platform gem on mac (this must have been with an older version of rubygems, given the other bug I just reported where this doesn't work). When I tried to 'gem uninstall' the gem, it did not uninstall it (even though stdout said it did). Passing --platform to uninstall didn't work either. I had to manually delete the gem/spec/cache/etc. Thx, -- Chad From drbrain at segment7.net Wed Dec 19 06:48:43 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Dec 2007 03:48:43 -0800 Subject: [Rubygems-developers] executable wrapper not working for some gems? In-Reply-To: <9C714CCA-78F6-4E01-A80B-07ACA5B3CAAD@segment7.net> References: <9C714CCA-78F6-4E01-A80B-07ACA5B3CAAD@segment7.net> Message-ID: <05E2E331-345B-4F89-8B0C-6032A89FD499@segment7.net> On Dec 19, 2007, at 02:45 AM, Eric Hodel wrote: > On Dec 19, 2007, at 02:32 AM, Chad Woolley wrote: >> Not sure if this is a problem with the rubygems trunk or not, but >> reporting anyway... >> >> When I install the rspec 1.1.1 gem using rubygems trunk, the 'spec' >> binary in /usr/local/bin/spec doesn't have the rubygems wrapper code. >> In other words, it is exactly the same as the rspec source >> executable, >> without the shebang or require 'rubygems', etc. >> >> I tried another gem (geminstaller) and it did get the exec wrapper >> generated correctly, so not sure what's up, if this is a rubygems or >> an rspec problem. >> >> This was with the latest trunk rubygems, on mac. > > I added code to omit the wrapper for files that don't have a #! line. > spec doesn't have one of these. > > I think I will roll back this change, and add some code to > Gem::Builder to complain about such files for now. Done. From drbrain at segment7.net Wed Dec 19 06:50:02 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Dec 2007 03:50:02 -0800 Subject: [Rubygems-developers] can't uninstall mswin gem from mac In-Reply-To: References: Message-ID: On Dec 19, 2007, at 03:40 AM, Chad Woolley wrote: > I installed a mswin32 platform gem on mac (this must have been with an > older version of rubygems, given the other bug I just reported where > this doesn't work). > > When I tried to 'gem uninstall' the gem, it did not uninstall it (even > though stdout said it did). Passing --platform to uninstall didn't > work either. I had to manually delete the gem/spec/cache/etc. Could you file a bug? I don't think this is critical to fix, since you can't activate it. From drbrain at segment7.net Wed Dec 19 06:58:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 19 Dec 2007 03:58:23 -0800 Subject: [Rubygems-developers] Gem::RemoteInstaller removed Message-ID: <98046D62-B2A4-4A4C-89F1-A06BAB309642@segment7.net> In preparation for 1.0, I have removed it. It is no longer maintained. From thewoolleyman at gmail.com Wed Dec 19 07:03:06 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Dec 2007 05:03:06 -0700 Subject: [Rubygems-developers] can't uninstall mswin gem from mac In-Reply-To: References: Message-ID: On Dec 19, 2007 4:50 AM, Eric Hodel wrote: > Could you file a bug? I don't think this is critical to fix, since > you can't activate it. Done: http://rubyforge.org/tracker/index.php?func=detail&aid=16435&group_id=126&atid=575 From thewoolleyman at gmail.com Wed Dec 19 12:19:22 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 19 Dec 2007 10:19:22 -0700 Subject: [Rubygems-developers] problems with gem server source_cache In-Reply-To: References: Message-ID: On Dec 19, 2007 4:37 AM, Chad Woolley wrote: > I think there are still some problems with platform handling in gem > server. This was a false alarm - I unknowingly had some older rubygems files on my path. Sorry... From transfire at gmail.com Wed Dec 19 12:54:50 2007 From: transfire at gmail.com (Trans) Date: Wed, 19 Dec 2007 12:54:50 -0500 Subject: [Rubygems-developers] Google Group Mirror Message-ID: <4b6f054f0712190954m688d6a10ufd6203966649cd8a@mail.gmail.com> Is there a google group mirror for the rubygems list? T. From tom at infoether.com Wed Dec 19 23:00:23 2007 From: tom at infoether.com (Tom Copeland) Date: Wed, 19 Dec 2007 23:00:23 -0500 Subject: [Rubygems-developers] Problem with requests for the rails 2.0.2 activesupport gem Message-ID: <1198123223.22579.15.camel@bugs.hal> Hi guys - I'm seeing some odd requests for the activesupport-2.0.2 gem in the gems.rubyforge.org vhost log: ================= gems.rubyforge.org 203.174.47.190 - - [19/Dec/2007:22:51:55 -0500] "GET /gems/activesupport-2.0.2-.gem HTTP/1.1" 302 244 "-" "RubyGems/0.9.4" ================= Note that there's a "-" right before the ".gem" suffix. This request gets routed off to a mirror and of course fails. This seems to be happening with various gem client versions - 0.9.4, 0.9.2, and 0.9.0. I'm not seeing it with 0.9.5, though, which is nice. Any ideas? I wonder if the gem is being built with a version of RubyGems that's somehow creating something that older gem client versions can't read, perhaps? Thanks, Tom From luislavena at gmail.com Wed Dec 19 23:04:21 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 20 Dec 2007 01:04:21 -0300 Subject: [Rubygems-developers] Problem with requests for the rails 2.0.2 activesupport gem In-Reply-To: <1198123223.22579.15.camel@bugs.hal> References: <1198123223.22579.15.camel@bugs.hal> Message-ID: <71166b3b0712192004q32eeee1t74e6588e2e886042@mail.gmail.com> On Dec 20, 2007 1:00 AM, Tom Copeland wrote: > Hi guys - > > I'm seeing some odd requests for the activesupport-2.0.2 gem in the > gems.rubyforge.org vhost log: > > ================= > gems.rubyforge.org 203.174.47.190 - - [19/Dec/2007:22:51:55 -0500] > "GET /gems/activesupport-2.0.2-.gem HTTP/1.1" 302 244 "-" > "RubyGems/0.9.4" > ================= > > Note that there's a "-" right before the ".gem" suffix. This request > gets routed off to a mirror and of course fails. > > This seems to be happening with various gem client versions - 0.9.4, > 0.9.2, and 0.9.0. I'm not seeing it with 0.9.5, though, which is > nice. > > Any ideas? I wonder if the gem is being built with a version of > RubyGems that's somehow creating something that older gem client > versions can't read, perhaps? > That was a problem with platform part of the spec being empty. gem install report it "()" This was reported to Rails devs: http://weblog.rubyonrails.org/2007/12/19/trouble-installing-new-gems And there is a fix on trunk for 2.0.3 Also, future version of 0.9.5 (hope 1.0) of RubyGems solve this. PS: did you got my email about fastthread gem? -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From tom at infoether.com Thu Dec 20 00:11:13 2007 From: tom at infoether.com (Tom Copeland) Date: Thu, 20 Dec 2007 00:11:13 -0500 Subject: [Rubygems-developers] Problem with requests for the rails 2.0.2 activesupport gem In-Reply-To: <71166b3b0712192004q32eeee1t74e6588e2e886042@mail.gmail.com> References: <1198123223.22579.15.camel@bugs.hal> <71166b3b0712192004q32eeee1t74e6588e2e886042@mail.gmail.com> Message-ID: <1198127473.22579.34.camel@bugs.hal> On Thu, 2007-12-20 at 01:04 -0300, Luis Lavena wrote: > That was a problem with platform part of the spec being empty. > > gem install report it "()" > > This was reported to Rails devs: > http://weblog.rubyonrails.org/2007/12/19/trouble-installing-new-gems > > And there is a fix on trunk for 2.0.3 Ah, cool, ok, thanks! I should have checked that first, soory for the noise... > Also, future version of 0.9.5 (hope 1.0) of RubyGems solve this. Very cool. > PS: did you got my email about fastthread gem? Yup, just replied! Yours, Tom From drbrain at segment7.net Thu Dec 20 03:33:07 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 20 Dec 2007 00:33:07 -0800 Subject: [Rubygems-developers] [ANN] RubyGems 1.0.0 Message-ID: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> Release 1.0.0 fixes several bugs. Major New Features Include: * RubyGems warns about various problems with gemspecs during gem building * More-consistent versioning for the RubyGems software Other Changes Include: * Fixed various bugs and problems with installing gems on Windows * Fixed using `gem server` for installing gems * Various operations are even more verbose with --verbose * Built gems are now backwards compatible with 0.9.4 * Improved detection of RUBYOPT loading rubygems * `ruby setup.rb` now has a --help option * Gem::Specification#bindir is now respected on installation * Executable stubs can now be installed to match ruby's name, so if ruby is installed as 'ruby18', foo_exec will be installed as 'foo_exec18' * `gem unpack` can now unpack into a specific directory with --target * OpenSSL is no longer required by default Deprecations and Deletions: * Kernel#require_gem has been removed * Executables without a shebang will not be wrapped in a future version, this may cause such executables to fail to operate on installation * Gem::Platform constants other than RUBY and CURRENT have been removed * Gem::RemoteInstaller was removed * Gem::Specification#test_suite_file and #test_suite_file= are deprecated in favor of #test_file and #test_file= * Gem::Specification#autorequire= has been deprecated * Time::today will be removed in a future version == How can I get RubyGems? NOTE: If you have installed RubyGems using a package you may want to install a new RubyGems through the same packaging system. If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is: $ gem update --system (you might need to be admin/root) (Note: You may have to run the command twice if you have any previosly installed rubygems-update gems). If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update (again, might need to be admin/root) $ update_rubygems (... here too) If you don't have any gems install, there is still the pre-gem approach to getting software ... doing it manually: 1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126 2. UNPACK INTO A DIRECTORY AND CD THERE 3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege) == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From transfire at gmail.com Thu Dec 20 08:53:42 2007 From: transfire at gmail.com (Trans) Date: Thu, 20 Dec 2007 08:53:42 -0500 Subject: [Rubygems-developers] [ANN] RubyGems 1.0.0 In-Reply-To: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> References: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> Message-ID: <4b6f054f0712200553n1c3998fale59f73b2a6d57728@mail.gmail.com> On Dec 20, 2007 3:33 AM, Eric Hodel wrote: > * Improved detection of RUBYOPT loading rubygems Could you explain this one more. What changed? Thanks, T. From rick.denatale at gmail.com Thu Dec 20 10:38:13 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Thu, 20 Dec 2007 10:38:13 -0500 Subject: [Rubygems-developers] [ANN] RubyGems 1.0.0 In-Reply-To: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> References: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> Message-ID: On 12/20/07, Eric Hodel wrote: > If you have a recent version of RubyGems (0.8.5 or later), then all > you need to do is: > > $ gem update --system (you might need to be admin/root) > > (Note: You may have to run the command twice if you have any previosly > installed rubygems-update gems). How would one know if they had to run the command twice, or should I just do it twice for grins? -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From charles.nutter at sun.com Thu Dec 20 18:33:09 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 20 Dec 2007 17:33:09 -0600 Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby Message-ID: <476AFBB5.1090604@sun.com> 1. jgem? I saw this during the 1.0.0 install: install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem Why jgem? We've been shipping with just 'gem'. 2. Some version issue on JRuby I'm not positive this isn't because there's some old files straggling or a marshalling bug or something, but I'm seeing a case where a Version object has not had @ints initialized. This causes it to fail comparisons later on. Specifically, I'm seeing someting looking for a version "1.8.5" >= "0" at some point during Rails 2.0.2 install, which is when it blows up. If I modify version.rb like so I do not see this problem, but I'm not sure why @ints isn't getting initialized on its own: def <=>(other) return 1 unless other - @ints <=> other.ints + @ints <=> other.to_ints end With this fix (and a Time marshalling bug in JRuby) I managed to get Rails 2.0.2 to install fine with RubyGems 1.0.0...so I'm keen to get JRuby upgraded. - Charlie From charles.nutter at sun.com Thu Dec 20 18:38:29 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 20 Dec 2007 17:38:29 -0600 Subject: [Rubygems-developers] Tarballs on rubyforge are actually gzip wrapping gzip wrapping tar Message-ID: <476AFCF5.2000803@sun.com> I didn't try them all, but both the 1.0.0 tgz and the 0.9.5 tgz are actually gzip wrapping gzip wrapping tar, so tar xzf fails to open them. I think they're probably intended to just be gzip wrapping tar. - Charlie From charles.nutter at sun.com Thu Dec 20 21:38:32 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 20 Dec 2007 20:38:32 -0600 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: <9C21C37A-98C5-466B-A83F-1A32D8AC8920@segment7.net> References: <4754EA6F.8090209@sun.com> <47621D72.80601@sun.com> <9C21C37A-98C5-466B-A83F-1A32D8AC8920@segment7.net> Message-ID: <476B2728.1040508@sun.com> Eric Hodel wrote: > I added a patch that moved most of the defaults methods into rubygems/ > defaults.rb. Perhaps RubyGems could conditionally define things > depending upon platform in that file? Well let me describe the changes I'm making. I'm updating JRuby to RubyGems 1.0.0 right now. First change in install_update_options.rb: # Default options for the gem install command. def install_update_defaults_str '--rdoc --no-force --no-test --wrappers --env-shebang' end I don't know if this is anything more than informational Second change is in installer.rb: if true || @env_shebang then "#!/usr/bin/env jruby" else The "if true" needs some explaining. I can't find where to make env_shebang true by default. The other place I tried, also in installer, didn't seem to make a difference: options = { :force => false, :install_dir => Gem.dir, :exec_format => false, :env_shebang => true # this doesn't seem to work }.merge options ...so the if true || @env_shebang is just to hardcode it to always use env shebangs (since JRuby startup script is always just a shell script). And of course the shebang string itself is changed to say "jruby" instead of "ruby" since it's normally hardcoded to be "ruby". It would probably be nice if that used some runtime-specific value. So basically what would be nice is if I didn't have to remember to hunt down and patch these locations each time we updated RubyGems...or simply to have a single place I can tweak them to JRuby. That's probably going to be useful in the future with other implementations getting close to running RubyGems as well. - Charlie From charles.nutter at sun.com Thu Dec 20 21:45:35 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 20 Dec 2007 20:45:35 -0600 Subject: [Rubygems-developers] [ANN] RubyGems 1.0.0 In-Reply-To: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> References: <8ADD0CF0-C6A0-4BA6-8D5D-32769B79B0FA@segment7.net> Message-ID: <476B28CF.60703@sun.com> Eric Hodel wrote: > Release 1.0.0 fixes several bugs. JRuby is now running RubyGems 1.0.0 on trunk, and it will be included in the JRuby 1.1 release. All seems to be working good, other than the couple issues I already emailed about. - Charlie From drbrain at segment7.net Thu Dec 20 22:26:00 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 20 Dec 2007 19:26:00 -0800 Subject: [Rubygems-developers] [ANN] RubyGems 1.0.1 Message-ID: <59C5AF77-3B57-4D1D-8236-26E5931F598B@segment7.net> = Announce: RubyGems Release 1.0.1 Release 1.0.1 fixes a few bugs. Bugs Fixed: * Installation on Ruby 1.8.3 through 1.8.5 fixed * `gem build` on 1.8.3 fixed Other Changes Include: * Since RubyGems 0.9.5, RubyGems is no longer supported on Ruby 1.8.2 or older, this is official in RubyGems 1.0.1. == How can I get RubyGems? NOTE: If you have installed RubyGems using a package you may want to install a new RubyGems through the same packaging system. If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is: $ gem update --system (you might need to be admin/root) (Note: You may have to run the command twice if you have any previosly installed rubygems-update gems). If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update (again, might need to be admin/root) $ update_rubygems (... here too) If you don't have any gems install, there is still the pre-gem approach to getting software ... doing it manually: 1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126 2. UNPACK INTO A DIRECTORY AND CD THERE 3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege) == To File Bugs The RubyGems bug tracker can be found on RubyForge at: http://rubyforge.org/tracker/?func=add&group_id=126&atid=575 When filing a bug, `gem env` output will be helpful in diagnosing the issue. If you find a bug where RubyGems crashes, please provide debug output. You can do that with `gem --debug the_command`. == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From jim.weirich at gmail.com Fri Dec 21 09:39:11 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Fri, 21 Dec 2007 09:39:11 -0500 Subject: [Rubygems-developers] LOAD_PATH Ordering with Ruby 1.9 Gems Message-ID: <55D0FA52-3CBF-4406-ADE2-90F11CEED97B@gmail.com> When I try to override the installed rake in Ruby 1.9 with a gem, I get the following error: /Users/jim/local/ruby19/bin/rake:19:in `load': Is a directory - / Users/jim/local/ruby19/lib/ruby/gems/1.9/gems/rake-0.8.0/lib/rake (Errno::EISDIR) from /Users/jim/local/ruby19/bin/rake:19:in `
' It seems that the 'lib' directory in the rake gem preceeds the 'bin' directory, so loading 'rake' will find 'lib/rake' and complain about that. Pre-1.9 versions of gem put the bin directory first, so that load 'rake' would find that. Was this a deliberate change? (Actually, I never liked the whole idea of including the bin directory in the load path in the first place. Seems to me that we could have made the executable stub a wee bit smarter ... but I digress). -- -- Jim Weirich -- jim.weirich at gmail.com From avatar at spellboundnet.com Sat Dec 22 00:22:35 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Sat, 22 Dec 2007 00:22:35 -0500 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: <476B2728.1040508@sun.com> References: <4754EA6F.8090209@sun.com> <9C21C37A-98C5-466B-A83F-1A32D8AC8920@segment7.net> <476B2728.1040508@sun.com> Message-ID: <200712220022.35701.avatar@spellboundnet.com> On Thursday 20 December 2007 09:38:32 pm Charles Oliver Nutter wrote: > Eric Hodel wrote: > > I added a patch that moved most of the defaults methods into rubygems/ > > defaults.rb. Perhaps RubyGems could conditionally define things > > depending upon platform in that file? > > Well let me describe the changes I'm making. I'm updating JRuby to > RubyGems 1.0.0 right now. > > First change in install_update_options.rb: > > # Default options for the gem install command. > def install_update_defaults_str > '--rdoc --no-force --no-test --wrappers --env-shebang' > end > > I don't know if this is anything more than informational > > Second change is in installer.rb: > > if true || @env_shebang then > "#!/usr/bin/env jruby" > else > > The "if true" needs some explaining. I can't find where to make > env_shebang true by default. The other place I tried, also in installer, > didn't seem to make a difference: > > options = { > > :force => false, > :install_dir => Gem.dir, > :exec_format => false, > :env_shebang => true # this doesn't seem to work > > }.merge options This is because :env_shebang is being set by install_update_options.rb. Since the option already exists, the merge is overriding your default. I submitted patch 16508 which should make the above work properly. > > ...so the if true || @env_shebang is just to hardcode it to always use > env shebangs (since JRuby startup script is always just a shell script). > And of course the shebang string itself is changed to say "jruby" > instead of "ruby" since it's normally hardcoded to be "ruby". It would > probably be nice if that used some runtime-specific value. Honestly, it would be real nice if Ruby interpreters would define a standard constant that contains the name of the interpreter executable. Would be easy to define, and instead of playing patching games, gems could just use that constant. > > So basically what would be nice is if I didn't have to remember to hunt > down and patch these locations each time we updated RubyGems...or simply > to have a single place I can tweak them to JRuby. That's probably going > to be useful in the future with other implementations getting close to > running RubyGems as well. > > - Charlie > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From charles.nutter at sun.com Sat Dec 22 08:40:10 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sat, 22 Dec 2007 07:40:10 -0600 Subject: [Rubygems-developers] How best to change defaults for RubyGems in JRuby In-Reply-To: <200712220022.35701.avatar@spellboundnet.com> References: <4754EA6F.8090209@sun.com> <9C21C37A-98C5-466B-A83F-1A32D8AC8920@segment7.net> <476B2728.1040508@sun.com> <200712220022.35701.avatar@spellboundnet.com> Message-ID: <476D13BA.4000500@sun.com> Donavan Pantke wrote: > On Thursday 20 December 2007 09:38:32 pm Charles Oliver Nutter wrote: >> The "if true" needs some explaining. I can't find where to make >> env_shebang true by default. The other place I tried, also in installer, >> didn't seem to make a difference: >> >> options = { >> >> :force => false, >> :install_dir => Gem.dir, >> :exec_format => false, >> :env_shebang => true # this doesn't seem to work >> >> }.merge options > > This is because :env_shebang is being set by install_update_options.rb. Since > the option already exists, the merge is overriding your default. I submitted > patch 16508 which should make the above work properly. Ahh, I see. Well I'll leave it hardcoded for now, and if a RubyGems 1.0.2 includes the patch I'll upgrade with my fix above instead. Thanks! >> ...so the if true || @env_shebang is just to hardcode it to always use >> env shebangs (since JRuby startup script is always just a shell script). >> And of course the shebang string itself is changed to say "jruby" >> instead of "ruby" since it's normally hardcoded to be "ruby". It would >> probably be nice if that used some runtime-specific value. > > Honestly, it would be real nice if Ruby interpreters would define a standard > constant that contains the name of the interpreter executable. Would be easy > to define, and instead of playing patching games, gems could just use that > constant. We'd gladly do that...and also provide a "shell script shebang" special constant that people can use to generate scripts correctly (so we can just say "jruby scripts should always use env"). - Charlie From stephen.bannasch at deanbrook.org Sun Dec 23 14:06:11 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 23 Dec 2007 14:06:11 -0500 Subject: [Rubygems-developers] gem and jruby problem, can't convert YAML::JvYAML::Map into String Message-ID: I'm trying to learn enough about building gems in order to make a simple test case for the problem I've having. I'm trying to track down why I can't install mongrel with gem on trunk JRuby. see related bug reports for more detail: http://jira.codehaus.org/browse/JRUBY-1772 http://rubyforge.org/tracker/index.php?func=detail&aid=16517&group_id=1306&atid=5145 In doing this I've downloaded mongrel from svn and am getting this error: can't convert YAML::JvYAML::Map into String ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `add_file' while running: gem build mongrel.gemspec I'm looking for suggestions about isolating the problem with a simpler testcase. Here's how to duplicate the problem. [all the following is running JRuby trunk (r5341)] $ svn co http://mongrel.rubyforge.org/svn/trunk mongrel $ cd mongrel $ rake package java can't convert YAML::JvYAML::Map into String ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `add_file' $ cd mongrel/pkg/mongrel-1.1.2 $ gem build mongrel.gemspec -V --backtrace WARNING: no email specified WARNING: no homepage specified WARNING: bin/mongrel_rails is missing #! line ERROR: While executing gem ... (TypeError) can't convert YAML::JvYAML::Map into String ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `add_file' ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `open_from_io' ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `open' ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:790:in `open' ... jruby/lib/ruby/site_ruby/1.8/rubygems/builder.rb:68:in `write_package' ... jruby/lib/ruby/site_ruby/1.8/rubygems/builder.rb:68:in `build' ... jruby/lib/ruby/site_ruby/1.8/rubygems/commands/build_command.rb:23:in `execute' ... jruby/lib/ruby/site_ruby/1.8/rubygems/commands/build_command.rb:22:in `each' ... jruby/lib/ruby/site_ruby/1.8/rubygems/commands/build_command.rb:22:in `execute' ... jruby/lib/ruby/site_ruby/1.8/rubygems/commands/build_command.rb:22:in `invoke' ... jruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:104:in `process_args' ... jruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:74:in `run' ... jruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' ... jruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:69:in `run' From stephen.bannasch at deanbrook.org Sun Dec 23 14:59:45 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 23 Dec 2007 14:59:45 -0500 Subject: [Rubygems-developers] gem and jruby problem, can't convert YAML::JvYAML::Map into String In-Reply-To: References: Message-ID: At 2:06 PM -0500 12/23/07, Stephen Bannasch wrote: >I'm trying to track down why I can't install mongrel with gem on trunk JRuby. > >see related bug reports for more detail: > >http://jira.codehaus.org/browse/JRUBY-1772 >http://rubyforge.org/tracker/index.php?func=detail&aid=16517&group_id=1306&atid=5145 > >In doing this I've downloaded mongrel from svn and am getting this error: > > can't convert YAML::JvYAML::Map into String > ... jruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:738:in `add_file' This error was in JRuby's yaml parsing and has been fixed as of r5344. So I can download or build the mongrel gem manually and install it using JRuby. However trying to do a gem install from the rubgems repository still doesn't process the platform correctly and fails trying to build fastthread (which should only be built on MRI). http://jira.codehaus.org/browse/JRUBY-1771 I don't know yet whether the problem is with: * jruby's slightly patched version of gems 1.0.0 * the mongrel gem itself * ??? From homercs at gmail.com Wed Dec 26 07:09:23 2007 From: homercs at gmail.com (Sandy Young) Date: Wed, 26 Dec 2007 20:09:23 +0800 Subject: [Rubygems-developers] Where is gem_server? Message-ID: Hi All I have downloaded rubygems-1.0.1.tgzand installed it, and it works well. But when I try to read rDoc, I can't find the gem_server shell. Does the tar file not include this shell? Where can I find it? Best regards, Sandy -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071226/dcc1c4e0/attachment.html From luislavena at gmail.com Wed Dec 26 07:27:19 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 26 Dec 2007 09:27:19 -0300 Subject: [Rubygems-developers] Where is gem_server? In-Reply-To: References: Message-ID: <71166b3b0712260427l3fdeba9dyfbb893c00da1ea27@mail.gmail.com> On Dec 26, 2007 9:09 AM, Sandy Young wrote: > Hi All > > I have downloaded rubygems-1.0.1.tgz and installed it, and it works well. > But when I try to read rDoc, I can't find the gem_server shell. Does the tar > file not include this shell? Where can I find it? > No offense, but you should start reading also the release notes since 0.9.5: http://rubyforge.org/frs/shownotes.php?release_id=16500 * `gem_server` is now `gem server` * `gemlock` is now `gem lock` * `gem_mirror` is now `gem mirror` * `gemwhich` is now `gem which` * `gemri` is no longer included with RubyGems also, 'gem help commands' will show you that. HTH, -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From charles.nutter at sun.com Wed Dec 26 17:31:16 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 26 Dec 2007 16:31:16 -0600 Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby In-Reply-To: <476AFBB5.1090604@sun.com> References: <476AFBB5.1090604@sun.com> Message-ID: <4772D634.7010400@sun.com> Charles Oliver Nutter wrote: > 1. jgem? > > I saw this during the 1.0.0 install: > > install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem > > Why jgem? We've been shipping with just 'gem'. I'd still like to know why this is the case. We don't want to ship RubyGems as "jgem" in JRuby. If anything, we might call it "jem", but I strongly prefer just leaving it as "gem". > 2. Some version issue on JRuby Eric suggested, and was correct, that this was an issue with JRuby not calling yaml_initialize when reconstituting objects from YAML. I've fixed that on JRuby trunk and removed the to_ints hack. Thanks! - Charlie From halostatue at gmail.com Wed Dec 26 23:09:58 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Wed, 26 Dec 2007 23:09:58 -0500 Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby In-Reply-To: <4772D634.7010400@sun.com> References: <476AFBB5.1090604@sun.com> <4772D634.7010400@sun.com> Message-ID: <9e7db9110712262009i5a979633o571cf51d6a757625@mail.gmail.com> On Dec 26, 2007 5:31 PM, Charles Oliver Nutter wrote: > Charles Oliver Nutter wrote: > > 1. jgem? > > > > I saw this during the 1.0.0 install: > > > > install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem > > > > Why jgem? We've been shipping with just 'gem'. > I'd still like to know why this is the case. We don't want to ship > RubyGems as "jgem" in JRuby. If anything, we might call it "jem", but I > strongly prefer just leaving it as "gem". Wouldn't then jruby and ruby installations conflict? -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From stephen.bannasch at deanbrook.org Wed Dec 26 23:56:17 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 26 Dec 2007 23:56:17 -0500 Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby In-Reply-To: <9e7db9110712262009i5a979633o571cf51d6a757625@mail.gmail.com> References: <476AFBB5.1090604@sun.com> <4772D634.7010400@sun.com> <9e7db9110712262009i5a979633o571cf51d6a757625@mail.gmail.com> Message-ID: >On Dec 26, 2007 5:31 PM, Charles Oliver Nutter wrote: >> Charles Oliver Nutter wrote: >> > 1. jgem? >> > >> > I saw this during the 1.0.0 install: >> > >> > install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem >> > >> > Why jgem? We've been shipping with just 'gem'. >> I'd still like to know why this is the case. We don't want to ship >> RubyGems as "jgem" in JRuby. If anything, we might call it "jem", but I >> strongly prefer just leaving it as "gem". > >Wouldn't then jruby and ruby installations conflict? Yes, unless the installations are managed correctly -- they will both install various executable programs with the same names. This has not been a problem for me. When I am working in jruby the first element in PATH is set to be: /bin. When I am working in MRI the first element in PATH is /usr/local/bin (my 1.8.6 MRI is installed in /usr/local). When I am working in 1.9 everything lives somewhere else. I think I have four or five different ruby installs -- all with different gem environments. In general while working in jruby all the standard ruby commands just work. Right now there is a problem installing platform-specific gems like mongrel and hpricot but I don't know if that is a jruby, gems, or gemspec issue. See: http://jira.codehaus.org/browse/JRUBY-1771 From thewoolleyman at gmail.com Thu Dec 27 17:35:38 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 27 Dec 2007 15:35:38 -0700 Subject: [Rubygems-developers] Problem with multiplatforms gems when using SourceIndex#search Message-ID: Hi, I have a test scenario where I have two test gems installed - they have an identical platform and version, but different platforms (one 'ruby', one 'mswin32'). This is on a mac. The problem is that I can't see how to make SourceIndex#search select based on platform - it only seems to search based on name and version. Given the gems described above, there's no way to specifically ask if the ruby or mswin32 gem is installed. In other words, there's no way to pass a Gem::Dependency that will select a specific platform. You can pass the platform_only flag, but that's not what I want - I want to select a specific platform that is not the current platform. Is this the intended behavior? I know this is an edge case. In normal usage, you wouldn't install a gem that doesn't match your platform, but I think it's probably pretty common for people that build multiplatform gems - you want to do a test install just to test it out, not necessarily use it. This could be fixed if there was a platform property added to Dependency. Or maybe make the #search platform_only param be an actual Platform object (defaulting to current platform) instead of just a current-platform-or-not flag. Thanks, Chad From mgreenly at gmail.com Fri Dec 28 03:33:42 2007 From: mgreenly at gmail.com (michael greenly) Date: Fri, 28 Dec 2007 02:33:42 -0600 Subject: [Rubygems-developers] Can anyone shed a little light on executable gems for me? Message-ID: It seems to me that something has changed quite a bit about how executable gems are handled in the last few versions? In the past there was a $GEM_HOME/bin directory but it doesn't seem to be there any more? Instead it seems the executable files for installed gems end up in the same place that the gem command exits? Is this right? Or am I off base on this? The reason I ask is I'm left wondering how best to separate a Ruby 1.8environment from a Ruby 1.9 environment so that they can each have a for example a 'rails' gem installed and work in both environments at the same time but with separate gems? There seemed to be a really straight forward solution prior to this change? If the executable files for gems were installed in $GEM_HOME/bin then simply installing Ruby using ./configure --program-suffix=1.8 or --program-suffix= 1.9 like all the linux distributions do anyway would keep everything from overlapping. Then it would be a simple(maybe?) matter of hacking in a "gem run " command. This then would allow the end user to do " gem1.8 run rails" or "gem1.9 run rails" etc... Anyway, I'm hoping some one can shed some light on this for me? let me know what I'm wrong about ;) -- Michael Greenly http://blog.michaelgreenly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071228/88d75243/attachment.html From thewoolleyman at gmail.com Fri Dec 28 21:46:08 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 28 Dec 2007 19:46:08 -0700 Subject: [Rubygems-developers] bug: gem uninstall --all option still prompts if multiple platforms installed Message-ID: Bug report here: http://rubyforge.org/tracker/index.php?func=detail&aid=16686&group_id=126&atid=575 From stephen.bannasch at deanbrook.org Sat Dec 29 00:02:34 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 29 Dec 2007 00:02:34 -0500 Subject: [Rubygems-developers] Can anyone shed a little light on executable gems for me? In-Reply-To: References: Message-ID: >It seems to me that something has changed quite a bit about how executable gems are handled in the last few versions? > >In the past there was a $GEM_HOME/bin directory but it doesn't seem to be there any more? Instead it seems the executable files for installed gems end up in the same place that the gem command exits? Is this right? Or am I off base on this? > >The reason I ask is I'm left wondering how best to separate a Ruby 1.8 environment from a Ruby 1.9 environment so that they can each have a for example a 'rails' gem installed and work in both environments at the same time but with separate gems? Michael, I install ruby 1.9 into a whole different directory and the gems also live there. If I am writing code for 1.9 This is how it works on my MacOS X 10.4.11 system. My source for Ruby 1.9 lives here: ~/dev/ruby/src/ruby_1_9 The Ruby 1.9 install lives here: ~/dev/ruby/1.9_trunk I build the source using these configure parameters: ./configure --prefix=/Users/stephen/dev/ruby/1.9_trunk/ --enable-pthread --with-readline-dir=/usr/local --enable-shared [I've already got an up-to-date copy of readline built and installed in /usr/local] Following this with make; make install creates my ruby 1.9 installation here ~/dev/ruby/1.9_trunk. I set my path accordingly by executing this after I cd into ~/dev/ruby/1.9_trunk: export PATH=`pwd`/bin:$PATH I've now got a pristine new ruby 1.9 environment there. Gems installed there won't conflict at all with the Ruby 1.8.6 p111 I have installed in /usr/local. I do something very similar for my JRuby installs. [~/dev/ruby/1.9_trunk]$ ruby --version ruby 1.9.0 (2007-12-29 revision 0) [i686-darwin8.11.1] [~/dev/ruby/1.9_trunk]$ gem environment RubyGems Environment: - RUBYGEMS VERSION: 1.0.1 (1.0.1) - RUBY VERSION: 1.9.0 (2007-12-29 patchlevel 0) [i686-darwin8.11.1] - INSTALLATION DIRECTORY: /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/gems/1.9.0 - RUBYGEMS PREFIX: /Users/stephen/dev/ruby/1.9_trunk/lib/ruby - RUBY EXECUTABLE: /Users/stephen/dev/ruby/1.9_trunk/bin/ruby - RUBYGEMS PLATFORMS: - ruby - x86-darwin-8 - GEM PATHS: - /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/gems/1.9.0 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - "rdoc" => "--template jamis --inline-source --line-numbers" - REMOTE SOURCES: - http://gems.rubyforge.org [~/dev/ruby/1.9_trunk]$ gem list --local *** LOCAL GEMS *** From thewoolleyman at gmail.com Sat Dec 29 01:31:21 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 28 Dec 2007 23:31:21 -0700 Subject: [Rubygems-developers] bug: gem uninstall --all option still prompts if multiple platforms installed In-Reply-To: References: Message-ID: On Dec 28, 2007 7:46 PM, Chad Woolley wrote: > Bug report here: > http://rubyforge.org/tracker/index.php?func=detail&aid=16686&group_id=126&atid=575 > This was actually a bug where the config-file option threw away any trailing args. Bug and patch are here: http://rubyforge.org/tracker/index.php?func=detail&aid=16688&group_id=126&atid=575 From luislavena at gmail.com Sat Dec 29 02:06:15 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 29 Dec 2007 04:06:15 -0300 Subject: [Rubygems-developers] cannot specify multiple required_ruby_versions. Message-ID: <71166b3b0712282306t4b2c4ce1od6119f37df9a1c6e@mail.gmail.com> Hello everybody, Since 1.9 is out, the use of required_ruby_version of Gem::Specification seems a good alternative to "allow any version of ruby from 1.8.4 but lower than 1.9.0" so, anyone will think: ok, I can do this: spec.required_ruby_version = ['>=1.8.4', '<1.9.0'] then do rake gem and bingo, it gets build! then, install: gem install gem: gem installed successfuly! irb: require 'rubygems' require 'test_gem' ArgumentError: Illformed requirement [">= 1.8.4, < 1.9.0"] This also happens when I try to uninstall the gem. Rakefile: http://pastie.caboo.se/132946 The required_ruby_version wasn't like that. Ideas? -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From halostatue at gmail.com Sat Dec 29 09:59:18 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Sat, 29 Dec 2007 09:59:18 -0500 Subject: [Rubygems-developers] cannot specify multiple required_ruby_versions. In-Reply-To: <71166b3b0712282306t4b2c4ce1od6119f37df9a1c6e@mail.gmail.com> References: <71166b3b0712282306t4b2c4ce1od6119f37df9a1c6e@mail.gmail.com> Message-ID: <9e7db9110712290659y6bd9ee02ga7a51f655b8e1b34@mail.gmail.com> On Dec 29, 2007 2:06 AM, Luis Lavena wrote: > Hello everybody, > > Since 1.9 is out, the use of required_ruby_version of > Gem::Specification seems a good alternative to "allow any version of > ruby from 1.8.4 but lower than 1.9.0" > > so, anyone will think: ok, I can do this: What about spec.required_ruby_version = "~>1.8.4" That should allow anything up to 1.8.9.9.9.9.9.9.... -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From luislavena at gmail.com Sat Dec 29 11:07:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 29 Dec 2007 13:07:08 -0300 Subject: [Rubygems-developers] cannot specify multiple required_ruby_versions. In-Reply-To: <9e7db9110712290659y6bd9ee02ga7a51f655b8e1b34@mail.gmail.com> References: <71166b3b0712282306t4b2c4ce1od6119f37df9a1c6e@mail.gmail.com> <9e7db9110712290659y6bd9ee02ga7a51f655b8e1b34@mail.gmail.com> Message-ID: <71166b3b0712290807x26a5c5b2m1c0179f691e3356f@mail.gmail.com> On Dec 29, 2007 11:59 AM, Austin Ziegler wrote: > > What about > > spec.required_ruby_version = "~>1.8.4" > > That should allow anything up to 1.8.9.9.9.9.9.9.... > You're correct Austin, actually I'm using that on some gems: irb(main):001:0> a = Gem::Requirement.create("~>1.8.4") => #", #]]> irb(main):002:0> v1 = Gem::Version.new("1.8.6") => # irb(main):003:0> v2 = Gem::Version.new("1.9.0") => # irb(main):004:0> a.satisfied_by?(v1) => true irb(main):005:0> a.satisfied_by?(v2) => false === But the point about this mail was to comment about the lack of checking of required_ruby_version illformed values during creation and installation of the gem. -- Luis Lavena Multimedia systems - A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. Douglas Adams From mgreenly at gmail.com Sat Dec 29 12:16:12 2007 From: mgreenly at gmail.com (michael greenly) Date: Sat, 29 Dec 2007 11:16:12 -0600 Subject: [Rubygems-developers] Can anyone shed a little light on executable gems for me? In-Reply-To: References: Message-ID: I don't really have a problem installing it in different directories and in fact that's exactly what I have at the moment (it's the only option) I describe my current setup in this blog post: http://blog.michaelgreenly.com/2007/12/multiple-ruby-version-on-ubuntu.html The one minor shortcoming of this arrangement is that the user has to know where things are installed and use the full paths when they want to execute a specific gem. So for example you'd have to type /opt/ruby/1.9/bin/rails to run that specific version. It works but it's not a clean solution. I was mostly only asking trying to get a bit of historical perspective on recent changes? If there was one? I intend on spending some time learning just what makes gems tick and then taking a real hard look at how it's being re-packaged on Debian based systems. I'd really like to see gems eventually support everything that's necessary for all platforms as configurable installation options. Obviously if that were the case re-packaging would be much more straight forward. All of that said, I'm an outsider looking in at both processes. I have no clue what's really going on with RubyGems or with Debian's Ruby packaging but I'm just starting to pay attention because it's just starting to really matter to me. On Dec 28, 2007 11:02 PM, Stephen Bannasch wrote: > >It seems to me that something has changed quite a bit about how > executable gems are handled in the last few versions? > > > >In the past there was a $GEM_HOME/bin directory but it doesn't seem to be > there any more? Instead it seems the executable files for installed gems > end up in the same place that the gem command exits? Is this right? Or am > I off base on this? > > > >The reason I ask is I'm left wondering how best to separate a Ruby 1.8environment from a Ruby > 1.9 environment so that they can each have a for example a 'rails' gem > installed and work in both environments at the same time but with separate > gems? > > Michael, > > I install ruby 1.9 into a whole different directory and the gems also live > there. If I am writing code for 1.9 > > This is how it works on my MacOS X 10.4.11 system. > > My source for Ruby 1.9 lives here: > > ~/dev/ruby/src/ruby_1_9 > > The Ruby 1.9 install lives here: > > ~/dev/ruby/1.9_trunk > > I build the source using these configure parameters: > > ./configure --prefix=/Users/stephen/dev/ruby/1.9_trunk/ --enable-pthread > --with-readline-dir=/usr/local --enable-shared > > [I've already got an up-to-date copy of readline built and installed in > /usr/local] > > Following this with make; make install creates my ruby 1.9 installation > here ~/dev/ruby/1.9_trunk. > > I set my path accordingly by executing this after I cd into > ~/dev/ruby/1.9_trunk: > > export PATH=`pwd`/bin:$PATH > > I've now got a pristine new ruby 1.9 environment there. Gems installed > there won't conflict at all with the Ruby 1.8.6 p111 I have installed in > /usr/local. I do something very similar for my JRuby installs. > > [~/dev/ruby/1.9_trunk]$ ruby --version > ruby 1.9.0 (2007-12-29 revision 0) [i686-darwin8.11.1] > > [~/dev/ruby/1.9_trunk]$ gem environment > RubyGems Environment: > - RUBYGEMS VERSION: 1.0.1 (1.0.1) > - RUBY VERSION: 1.9.0 (2007-12-29 patchlevel 0) [i686-darwin8.11.1] > - INSTALLATION DIRECTORY: > /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/gems/1.9.0 > - RUBYGEMS PREFIX: /Users/stephen/dev/ruby/1.9_trunk/lib/ruby > - RUBY EXECUTABLE: /Users/stephen/dev/ruby/1.9_trunk/bin/ruby > - RUBYGEMS PLATFORMS: > - ruby > - x86-darwin-8 > - GEM PATHS: > - /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/gems/1.9.0 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - "rdoc" => "--template jamis --inline-source --line-numbers" > - REMOTE SOURCES: > - http://gems.rubyforge.org > > [~/dev/ruby/1.9_trunk]$ gem list --local > > *** LOCAL GEMS *** > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Michael Greenly http://blog.michaelgreenly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071229/e963592e/attachment-0001.html From stephen.bannasch at deanbrook.org Sat Dec 29 13:05:24 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sat, 29 Dec 2007 13:05:24 -0500 Subject: [Rubygems-developers] Can anyone shed a little light on executable gems for me? In-Reply-To: References: Message-ID: At 11:16 AM -0600 12/29/07, michael greenly wrote: >I don't really have a problem installing it in different directories >and in fact that's exactly what I have at the moment (it's the only >option) > >I describe my current setup in this blog post: > >http://blog.michaelgreenly.com/2007/12/multiple-ruby-version-on-ubuntu.html > >The one minor shortcoming of this arrangement is that the user has >to know where things are installed and use the full paths when they >want to execute a specific gem. So for example you'd have to type >/opt/ruby/1.9/bin/rails to run that specific version. It works but >it's not a clean solution. I'm not sure how to make clean and simple. One difference between my setup and yours is that I have just one ruby in /usr/local (1.8.6p111) and mine is actually installed there. My other two major ruby environments (jruby and 1.9) always live in separate directories with no links from /usr/local. An element that both simplifies and complicates is that I modify PATH to put a path to /bin first when I want to work in JRuby or 1.9. That allows me to use gem, rake, rails or any other command that might get installed in bin and it always works. It also means I've got to keep track of the shells I've modified path in. I almost never use full paths to execute anything. >I was mostly only asking trying to get a bit of historical >perspective on recent changes? If there was one? I intend on >spending some time learning just what makes gems tick and then >taking a real hard look at how it's being re-packaged on Debian >based systems. If you haven't seen it check out this thread on ruby-core to get an idea of some of the issues mixing package-based ruby with locally-installed additions: http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/12825?12676-13118 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071229/6fff72de/attachment.html From mgreenly at gmail.com Sat Dec 29 14:23:18 2007 From: mgreenly at gmail.com (michael greenly) Date: Sat, 29 Dec 2007 13:23:18 -0600 Subject: [Rubygems-developers] Can anyone shed a little light on executable gems for me? In-Reply-To: References: Message-ID: Sure, I think your setup is typical (not sharing a single bin directory) but it's one of the components that's more or less essential to support the linux file hierarchy standards. Linux distributions typically handle this by using --program-suffix and then creating a dummy package that symlinks with the base name to the suffixed name. I'm not suggesting I'd want anything like that for Gems but I wanted to look at was being able to control where the executable scripts were put for gem installs and making this a ./configure time option. That combined with a 'gem run' command would be all that's needed at the moment to clean up the multiple installs from source issue. In my case it would give me 'gem1.8 run rails' or 'gem1.9 run rails'. It should be a rather straight forward hacking of 'gem where'. It's just a thought I want to explore On Dec 29, 2007 12:05 PM, Stephen Bannasch wrote: > I'm not sure how to make clean and simple. > > One difference between my setup and yours is that I have just one ruby in > /usr/local (1.8.6p111) and mine is actually installed there. My other two > major ruby environments (jruby and 1.9) always live in separate > directories with no links from /usr/local. > I think a 'gem run' command would fix having to mess with paths... > > An element that both simplifies and complicates is that I modify PATH to > put a path to /bin first when I want to work in JRuby or 1.9. > That allows me to use gem, rake, rails or any other command that might get > installed in bin and it always works. It also means I've got to keep track > of the shells I've modified path in. I almost never use full paths to > execute anything. > I've been following these issues for quite a while and have recently decided it was time to dig into the code so I could get a better understanding of the real problems. Although I think for the most part they are political not technical. > If you haven't seen it check out this thread on ruby-core to get an idea > of some of the issues mixing package-based ruby with locally-installed > additions: > http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/12825?1 > 2676-13118 > > -- Michael Greenly http://blog.michaelgreenly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071229/9582a189/attachment.html