From rubygems at freeze.org Wed Jul 6 00:40:05 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 6 00:29:08 2005 Subject: [Rubygems-developers] Unecessary update? Message-ID: <20050706044005.GA85390@freeze.org> I have rails 0.12.1 installed and requested an update. From the message, I can't tell if it actually installed the same version or if the message was just trying to re-assuring. Seems like it should have told me that no updates were needed. % gem list | grep rails rails (0.12.1, 0.9.5, 0.9.4.1, 0.9.2) % gem update rails Upgrading installed gems... Updating Gem source index for: http://gems.rubyforge.org Attempting remote upgrade of rails Attempting remote installation of 'rails' Successfully installed rails-0.12.1 Gems: [rails] updated -- Jim Freeze From chad at chadfowler.com Thu Jul 7 06:46:40 2005 From: chad at chadfowler.com (Chad Fowler) Date: Thu Jul 7 06:41:38 2005 Subject: [Rubygems-developers] Unecessary update? In-Reply-To: <20050706044005.GA85390@freeze.org> References: <20050706044005.GA85390@freeze.org> Message-ID: <55AE91A5-AA64-4B3C-A1ED-BDB1DDEF8810@chadfowler.com> On 06-Jul-05, at 12:40 AM, Jim Freeze wrote: > I have rails 0.12.1 installed and requested an update. > From the message, I can't tell if it actually installed > the same version or if the message was just trying to re-assuring. > Seems like it should have told me that no updates were needed. > > % gem list | grep rails > rails (0.12.1, 0.9.5, 0.9.4.1, 0.9.2) > > % gem update rails > Upgrading installed gems... > Updating Gem source index for: http://gems.rubyforge.org > Attempting remote upgrade of rails > Attempting remote installation of 'rails' > Successfully installed rails-0.12.1 > Gems: [rails] updated > Thanks, Jim. This one's on the TODO list. Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20050707/ef40c5e0/attachment.htm From assaph at gmail.com Thu Jul 7 19:04:25 2005 From: assaph at gmail.com (Assaph Mehr) Date: Thu Jul 7 18:59:21 2005 Subject: [Rubygems-developers] Feature request: don't die on rdoc Message-ID: <3ff47be905070716043cb0dd2@mail.gmail.com> Hi all, When attempting an upgrade of the rails gems, gems keeps chocking of rdoc (see transcript below). Would it be possible to treat rdoc errors as not fatal and continue with the rest of the installation? I'd attempt a patch but my current free time is rapidly approaching the imaginary numbers scale. Cheers, Assaph c:\>gem up Upgrading installed gems... Updating Gem source index for: http://gems.rubyforge.org Attempting remote upgrade of actionmailer Attempting remote installation of 'actionmailer' Install required dependency actionpack? [Yn] Install required dependency activesupport? [Yn] Successfully installed actionmailer-1.0.0 Successfully installed actionpack-1.9.0 Successfully installed activesupport-1.1.0 Installing RDoc documentation for actionmailer-1.0.0... ERROR: While executing gem ... (NoMethodError) undefined method `as_href' for nil:NilClass c:\>gem up Upgrading installed gems... Attempting remote upgrade of actionwebservice Attempting remote installation of 'actionwebservice' Install required dependency activerecord? [Yn] Successfully installed actionwebservice-0.8.0 Successfully installed activerecord-1.11.0 Installing RDoc documentation for actionwebservice-0.8.0... Installing RDoc documentation for activerecord-1.11.0... ERROR: While executing gem ... (NoMethodError) undefined method `as_href' for nil:NilClass c:\>gem up Upgrading installed gems... Updating Gem source index for: http://gems.rubyforge.org Attempting remote upgrade of builder Attempting remote installation of 'builder' Successfully installed builder-1.2.4 Installing RDoc documentation for builder-1.2.4... Attempting remote upgrade of cmdparse Attempting remote installation of 'cmdparse' Successfully installed cmdparse-1.0.5 Installing RDoc documentation for cmdparse-1.0.5... Attempting remote upgrade of color-tools Attempting remote installation of 'color-tools' Successfully installed color-tools-1.2.0 Installing RDoc documentation for color-tools-1.2.0... Attempting remote upgrade of rails Attempting remote installation of 'rails' Successfully installed rails-0.13.0 Gems: [builder, cmdparse, color-tools, rails] updated c:\>ruby -v ruby 1.8.2 (2004-12-25) [i386-mswin32] c:\>gem env Rubygems Environment: - VERSION: 0.8.10 (0.8.10) - INSTALLATION DIRECTORY: c:/bin/ruby/lib/ruby/gems/1.8 - GEM PATH: - c:/bin/ruby/lib/ruby/gems/1.8 - REMOTE SOURCES: - http://gems.rubyforge.org From jim at weirichhouse.org Fri Jul 8 10:09:25 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Fri Jul 8 10:04:08 2005 Subject: [Rubygems-developers] Gem Signing Dependencies Message-ID: <200507081009.25216.jim@weirichhouse.org> I'm preparing a new release of RubyGems. This version includes the work from the Seattle code fest and Paul Duncan's gem signing options. I've got a question about the gem signing stuff (which works pretty slick btw). Are there any dependencies for the signing code? I see it requires openssl. Are the openssl libraries /always/ available in every ruby installation, or only those that have the openssl libraries available when ruby installs? I just want to make sure we fail gracefully if there are dependencies missing. There is a release candidate for 0.8.11 at http://onestepback.org/betagems (use the --source option). The release candidate is version 0.8.10.99. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From rich at infoether.com Fri Jul 8 10:15:24 2005 From: rich at infoether.com (Richard Kilmer) Date: Fri Jul 8 10:10:20 2005 Subject: [Rubygems-developers] Gem Signing Dependencies In-Reply-To: <200507081009.25216.jim@weirichhouse.org> References: <200507081009.25216.jim@weirichhouse.org> Message-ID: On Jul 8, 2005, at 10:09 AM, Jim Weirich wrote: > I'm preparing a new release of RubyGems. This version includes the > work from > the Seattle code fest and Paul Duncan's gem signing options. > > I've got a question about the gem signing stuff (which works pretty > slick > btw). Are there any dependencies for the signing code? I see it > requires > openssl. Are the openssl libraries /always/ available in every ruby > installation, or only those that have the openssl libraries > available when > ruby installs? The openssl Ruby extension will build if the libraries are there when Ruby builds (from source). Its possible that someone will run this on a machine that has Ruby w/out openssl though, so you better code defensively and fail gracefully. > > I just want to make sure we fail gracefully if there are > dependencies missing. > > There is a release candidate for 0.8.11 at http://onestepback.org/ > betagems > (use the --source option). The release candidate is version > 0.8.10.99. > > -- > -- Jim Weirich jim@weirichhouse.org http://onestepback.org > ----------------------------------------------------------------- > "Beware of bugs in the above code; I have only proved it correct, > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jw at innerewut.de Fri Jul 8 10:29:15 2005 From: jw at innerewut.de (Jonathan Weiss) Date: Fri Jul 8 10:24:12 2005 Subject: [Rubygems-developers] Gem Signing Dependencies In-Reply-To: <200507081009.25216.jim@weirichhouse.org> Message-ID: > I'm preparing a new release of RubyGems. This version includes the work from > the Seattle code fest and Paul Duncan's gem signing options. What is the schedule for the release? As I'm in the work of importing rubygems to OpenBSD and if 0.8.11 is only a week or two away I would wait a little. Greets, Jonathan -- Jonathan Weiss http://blog.innerewut.de From jw at innerewut.de Fri Jul 8 13:48:13 2005 From: jw at innerewut.de (Jonathan Weiss) Date: Fri Jul 8 13:43:12 2005 Subject: [Rubygems-developers] Fake installs of gems under OpenBSD Message-ID: Cheers, I work on integrating gems in to OpenBSD/FreeBSD ports tree. On OpenBSD a port/package is installed by installing it in a fake directory and then creating a package out of the installed files. Therefore a gem must be installed like this: gem install --install-dir ${PREFIX}/lib/ruby/gems/1.8 rake-0.5.4.gem The problem is that the rake executable ends up in ${PREFIX}/bin while all the other files are correctely in ${PREFIX}/lib/ruby/gems/1.8/ (as they should). The rake executable should end up in ${PREFIX}/usr/local/bin Is there a way to solve this problem? Maybe by setting GEM_HOME or something? Greets, Jonathan -- Jonathan Weiss http://blog.innerewut.de From dougkearns at gmail.com Sat Jul 9 10:47:35 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Sat Jul 9 10:48:36 2005 Subject: [Rubygems-developers] zsh completion function Message-ID: <20050709144735.GC3976@localhost.localdomain> G'day all, I was just about to write a zsh completion function for gem and was wondering if anyone had already saved me the trouble. ;-) Thanks, Doug From chad at chadfowler.com Sat Jul 9 13:55:35 2005 From: chad at chadfowler.com (Chad Fowler) Date: Sat Jul 9 13:50:31 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <20050709144735.GC3976@localhost.localdomain> References: <20050709144735.GC3976@localhost.localdomain> Message-ID: <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> On 09-Jul-05, at 10:47 AM, Doug Kearns wrote: > G'day all, > > I was just about to write a zsh completion function for gem and was > wondering if anyone had already saved me the trouble. ;-) > Cool! I don't know of anyone who has already done this. I'd like to have one for Bash, too. That might make a nice Saturday project some time. Chad From ryco at gmx.net Sat Jul 9 14:32:56 2005 From: ryco at gmx.net (Henrik Horneber) Date: Sat Jul 9 14:27:58 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> References: <20050709144735.GC3976@localhost.localdomain> <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> Message-ID: <42D01858.3050702@gmx.net> Chad Fowler schrieb: > > On 09-Jul-05, at 10:47 AM, Doug Kearns wrote: > >> G'day all, >> >> I was just about to write a zsh completion function for gem and was >> wondering if anyone had already saved me the trouble. ;-) >> > > Cool! I don't know of anyone who has already done this. > > I'd like to have one for Bash, too. That might make a nice Saturday > project some time. I would have bet my guitar that Brian Schr?der already had done this for bash, but I can't for the life of me find it right now in the ML archives (I'm pretty certain he announced it on ruby-talk). But I might be wrong. Henrik From mfp at acm.org Sat Jul 9 17:34:43 2005 From: mfp at acm.org (Mauricio =?iso-8859-1?Q?Fern=E1ndez?=) Date: Sat Jul 9 17:29:37 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <42D01858.3050702@gmx.net> References: <20050709144735.GC3976@localhost.localdomain> <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> <42D01858.3050702@gmx.net> Message-ID: <20050709213443.GB32295@tux-chan> On Sat, Jul 09, 2005 at 08:32:56PM +0200, Henrik Horneber wrote: > Chad Fowler schrieb: > > > >On 09-Jul-05, at 10:47 AM, Doug Kearns wrote: > > > >>G'day all, > >> > >>I was just about to write a zsh completion function for gem and was > >>wondering if anyone had already saved me the trouble. ;-) > >> > > > >Cool! I don't know of anyone who has already done this. > > > >I'd like to have one for Bash, too. That might make a nice Saturday > >project some time. > > > I would have bet my guitar that Brian Schr?der already had done this for > bash, but I can't for the life of me find it right now in the ML > archives (I'm pretty certain he announced it on ruby-talk). Not exactly what you want, but easy to adapt: http://ruby.brian-schroeder.de/rpa-completion/ -- Mauricio Fernandez From jim at weirichhouse.org Sat Jul 9 18:19:07 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Jul 9 18:15:54 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <42D01858.3050702@gmx.net> References: <20050709144735.GC3976@localhost.localdomain> <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> <42D01858.3050702@gmx.net> Message-ID: <200507091819.07282.jim@weirichhouse.org> On Saturday 09 July 2005 02:32 pm, Henrik Horneber wrote: > I would have bet my guitar [...] What kind of guitar? -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From jim at weirichhouse.org Sat Jul 9 18:57:15 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Jul 9 18:54:00 2005 Subject: [Rubygems-developers] Please try the release candidate for the new RubyGems version Message-ID: <200507091857.16074.jim@weirichhouse.org> I have a release candidate for the next RubyGems version available at http://onestepback.org/betagems. I'm having problems using the gem update command on windows to get it installed. Would someone else like to give it a try just in case it is my local windows box that is messed up? The command is: gem update --system --source http://onestepback.org/betagems This /should/ install version 0.8.10.100. My box is giving me a permission error when updating the shebang lines. Thanks. Meanwhile I'll continue to debug on my windows box. (blech) -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From jim at weirichhouse.org Sat Jul 9 19:27:07 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Jul 9 19:23:50 2005 Subject: [Rubygems-developers] Please try the release candidate for the new RubyGems version In-Reply-To: <200507091857.16074.jim@weirichhouse.org> References: <200507091857.16074.jim@weirichhouse.org> Message-ID: <200507091927.07214.jim@weirichhouse.org> On Saturday 09 July 2005 06:57 pm, Jim Weirich wrote: > I have a release candidate for the next RubyGems version available at > http://onestepback.org/betagems. I'm having problems using the gem update > command on windows to get it installed. Would someone else like to give it > a try just in case it is my local windows box that is messed up? The > command is: > > gem update --system --source http://onestepback.org/betagems > > This /should/ install version 0.8.10.100. My box is giving me a permission > error when updating the shebang lines. > > Thanks. > > Meanwhile I'll continue to debug on my windows box. (blech) I think I solved it. 0.8.10.101 should work now. Now I'm off to check the mac install. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From assaph at gmail.com Sat Jul 9 19:31:44 2005 From: assaph at gmail.com (Assaph Mehr) Date: Sat Jul 9 19:26:36 2005 Subject: [Rubygems-developers] Please try the release candidate for the new RubyGems version In-Reply-To: <200507091857.16074.jim@weirichhouse.org> References: <200507091857.16074.jim@weirichhouse.org> Message-ID: <3ff47be905070916314e318133@mail.gmail.com> Hi Jim, Tried it on my WinXP box. First run: got an exception (on unlink), and a message that the software updated. Second (consecutive) run: looks like it made it. HTH, Assaph *** System: c:\>ruby -v ruby 1.8.2 (2004-12-25) [i386-mswin32] *** First run: c:\>gem update --system --source http://onestepback.org/betagems Upgrading RubyGems... Updating Gem source index for: http://onestepback.org/betagems Attempting remote upgrade of rubygems-update Attempting remote installation of 'rubygems-update' Successfully installed rubygems-update-0.8.10.101 Updating version of RubyGems to 0.8.10.101 Installing RubyGems 0.8.10.101 ---> bin <--- bin ---> lib ---> lib/rubygems <--- lib/rubygems <--- lib ---> bin adjusting shebang: gem_mirror setup.rb:492:in `unlink': Permission denied - gem_mirror (Errno::EACCES) from setup.rb:492:in `move_file' from setup.rb:1145:in `adjust_shebang' from setup.rb:1136:in `open' from setup.rb:1136:in `adjust_shebang' from setup.rb:1128:in `setup_dir_bin' from setup.rb:1127:in `each' from setup.rb:1127:in `setup_dir_bin' from setup.rb:1321:in `__send__' ... 7 levels... from setup.rb:883:in `exec_setup' from setup.rb:704:in `invoke' from setup.rb:674:in `invoke' from setup.rb:1352 RubyGems system software updated *** Second Run c:\>gem --debug --backtrace update --system --source http://onestepback.org/betagems Exception `Errno::ENOENT' at c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:12 - No such file or directory - C:\Documents and Settings\Admin/.gemrc Upgrading RubyGems... Attempting remote upgrade of rubygems-update Attempting remote installation of 'rubygems-update' Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - c:/bin/ruby/lib/ruby/gems/1.8/gem s/rubygems-update-0.8.10.101 Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - . Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - doc Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - doc Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - examples/application Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - examples/application/bin Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - examples/application/lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - gemspecs Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - lib/rubygems Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - pkgs/sources Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - pkgs/sources/lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - redist Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - scripts Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - scripts Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - scripts Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - scripts Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - scripts Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/one Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/one Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/one Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/one/lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/legacy Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/legacy Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/data/lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/mock/gems/gems/sources-0.0.1 /lib Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/mock/gems/specifications Exception `Errno::EEXIST' at c:/bin/ruby/lib/ruby/1.8/fileutils.rb:212 - File exists - test/fake_certlib Successfully installed rubygems-update-0.8.10.101 Updating version of RubyGems to 0.8.10.101 Installing RubyGems 0.8.10.101 ---> bin <--- bin ---> lib ---> lib/rubygems <--- lib/rubygems <--- lib ---> bin adjusting shebang: gem_mirror <--- bin ---> lib ---> lib/rubygems <--- lib/rubygems <--- lib rm -f InstalledFiles ---> bin mkdir -p c:/bin/ruby/bin/ install gem c:/bin/ruby/bin/ install gemwhich c:/bin/ruby/bin/ install gem_mirror c:/bin/ruby/bin/ install gem_server c:/bin/ruby/bin/ install generate_yaml_index.rb c:/bin/ruby/bin/ install update_rubygems c:/bin/ruby/bin/ <--- bin ---> lib mkdir -p c:/bin/ruby/lib/ruby/site_ruby/1.8/ install gemconfigure.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/ install rubygems.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/ install ubygems.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/ ---> lib/rubygems mkdir -p c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install builder.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install cmd_manager.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install command.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install config_file.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install custom_require.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install dependency_list.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install deployment.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install doc_manager.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install format.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_commands.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_openssl.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install gem_runner.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install installer.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install loadpath_manager.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install old_format.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install open-uri.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install package.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install remote_installer.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install rubygems_version.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install security.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install source_index.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install specification.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install timer.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install user_interaction.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install validator.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems install version.rb c:/bin/ruby/lib/ruby/site_ruby/1.8/rubygems <--- lib/rubygems <--- lib As of RubyGems 0.8.0, library stubs are no longer needed. Searching $LOAD_PATH for stubs to optionally delete (may take a while)... ...done. No library stubs found. Successfully built RubyGem Name: sources Version: 0.0.1 File: sources-0.0.1.gem RubyGems system software updated removing C:/DOCUME~1/Admin/LOCALS~1/Temp/open-uri2540.0...done c:\>gem env Rubygems Environment: - VERSION: 0.8.10.101 (0.8.10.101) - INSTALLATION DIRECTORY: c:/bin/ruby/lib/ruby/gems/1.8 - GEM PATH: - c:/bin/ruby/lib/ruby/gems/1.8 - REMOTE SOURCES: - http://gems.rubyforge.org On 7/10/05, Jim Weirich wrote: > I have a release candidate for the next RubyGems version available at > http://onestepback.org/betagems. I'm having problems using the gem update > command on windows to get it installed. Would someone else like to give it a > try just in case it is my local windows box that is messed up? The command > is: > > gem update --system --source http://onestepback.org/betagems > > This /should/ install version 0.8.10.100. My box is giving me a permission > error when updating the shebang lines. > > Thanks. > > Meanwhile I'll continue to debug on my windows box. (blech) > > -- > -- Jim Weirich jim@weirichhouse.org http://onestepback.org > ----------------------------------------------------------------- > "Beware of bugs in the above code; I have only proved it correct, > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From jim at weirichhouse.org Sat Jul 9 20:18:08 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Jul 9 20:14:53 2005 Subject: [Rubygems-developers] Please try the release candidate for the new RubyGems version In-Reply-To: <3ff47be905070916314e318133@mail.gmail.com> References: <200507091857.16074.jim@weirichhouse.org> <3ff47be905070916314e318133@mail.gmail.com> Message-ID: <200507092018.08266.jim@weirichhouse.org> On Saturday 09 July 2005 07:31 pm, Assaph Mehr wrote: > Tried it on my WinXP box. > First run: got an exception (on unlink), and a message that the > software updated. > Second (consecutive) run: looks like it made it. Thanks... there was a brief moment when the 0.8.10.101 version was bad. It looks like the first update managed to hit that small window. I get the same results as the second run from a clean install of 0.8.10. Thanks for checking. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From ryco at gmx.net Sat Jul 9 21:11:11 2005 From: ryco at gmx.net (Henrik Horneber) Date: Sat Jul 9 21:06:08 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <200507091819.07282.jim@weirichhouse.org> References: <20050709144735.GC3976@localhost.localdomain> <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> <42D01858.3050702@gmx.net> <200507091819.07282.jim@weirichhouse.org> Message-ID: <42D075AF.7070607@gmx.net> Jim Weirich schrieb: > On Saturday 09 July 2005 02:32 pm, Henrik Horneber wrote: > >>I would have bet my guitar [...] > > > What kind of guitar? > http://duesenberg.de/duesenberg/en_hb_carlcarlton.php in black with a black pick guard (unlike any of the pics) And thank you, Mauricio =) From jim at weirichhouse.org Sat Jul 9 22:59:22 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Jul 9 22:56:09 2005 Subject: [Rubygems-developers] More release questions and issues Message-ID: <200507092259.22727.jim@weirichhouse.org> (1) The changelog mentions Mark Hubbart's changes to support the Mac OS X framework files. Can I get more information on this ... like how to take advantage of it? (2) Anybody mind if we change the name of "gem inspect" to "gem contents"? Inspect is close enough to install to goof up the abbreviated commands (i.e. "gem i" becomes ambiguous). I noticed that no one has written up docs for the inspect/contents command yet. I'll do that before the final release. Wow, there's a lot of little cleanup stuff to do for this release. ;) Cheers. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From dougkearns at gmail.com Sun Jul 10 03:22:00 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Sun Jul 10 03:23:03 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb Message-ID: <20050710072200.GF3976@localhost.localdomain> Patch against CVS HEAD. Regards, Doug Index: lib/rubygems/gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.62 diff -u -r1.62 gem_commands.rb --- lib/rubygems/gem_commands.rb 10 Jul 2005 04:07:23 -0000 1.62 +++ lib/rubygems/gem_commands.rb 10 Jul 2005 07:17:30 -0000 @@ -490,7 +490,7 @@ if options[:verify] gem_name = options[:verify] unless gem_name - alert_error "Must specifiy a .gem file with --verify NAME" + alert_error "Must specify a .gem file with --verify NAME" return end unless File.exist?(gem_name) From scholz at scriptolutions.com Sun Jul 10 03:37:11 2005 From: scholz at scriptolutions.com (Lothar Scholz) Date: Sun Jul 10 03:32:06 2005 Subject: [Rubygems-developers] Please try the release candidate for the new RubyGems version In-Reply-To: <200507091857.16074.jim@weirichhouse.org> References: <200507091857.16074.jim@weirichhouse.org> Message-ID: <1761501234.20050710143711@scriptolutions.com> Hello Jim, Sunday, July 10, 2005, 5:57:15 AM, you wrote: JW> I have a release candidate for the next RubyGems version available at JW> http://onestepback.org/betagems. I'm having problems using the gem update JW> command on windows to get it installed. Would someone else like to give it a JW> try just in case it is my local windows box that is messed up? The command JW> is: JW> gem update --system --source http://onestepback.org/betagems JW> This /should/ install version 0.8.10.100. My box is giving me a permission JW> error when updating the shebang lines. Sorry didn't tried it yet - but does this implement the "gem specification --remote name" command ? I would really like to see it implemented as it is important for my frontend. -- Best regards, Lothar Scholz mailto:scholz@scriptolutions.com From dougkearns at gmail.com Sun Jul 10 06:17:48 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Sun Jul 10 06:18:50 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050710072200.GF3976@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> Message-ID: <20050710101748.GH3976@localhost.localdomain> On Sun, Jul 10, 2005 at 05:22:00PM +1000, Doug Kearns wrote: > Patch against CVS HEAD. Another one. Regards, Doug Index: lib/rubygems/gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.62 diff -u -r1.62 gem_commands.rb --- lib/rubygems/gem_commands.rb 10 Jul 2005 04:07:23 -0000 1.62 +++ lib/rubygems/gem_commands.rb 10 Jul 2005 10:16:38 -0000 @@ -574,7 +574,7 @@ summary, {:name=>/.*/, :domain=>:local, :details=>false} ) - add_option('-n', '--name-matches REGEXP', 'Name of gem(s) to query on maches the provided REGEXP') do |value, options| + add_option('-n', '--name-matches REGEXP', 'Name of gem(s) to query on matches the provided REGEXP') do |value, options| options[:name] = /#{value}/i end add_option('-d', '--[no-]details', 'Display detailed information of gem(s)') do |value, options| From jim at weirichhouse.org Sun Jul 10 07:21:42 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sun Jul 10 07:18:23 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050710101748.GH3976@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> <20050710101748.GH3976@localhost.localdomain> Message-ID: <200507100721.42743.jim@weirichhouse.org> On Sunday 10 July 2005 06:17 am, Doug Kearns wrote: > On Sun, Jul 10, 2005 at 05:22:00PM +1000, Doug Kearns wrote: > > Patch against CVS HEAD. > > Another one. Thanks ... got'em. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From hgs at dmu.ac.uk Tue Jul 12 07:09:11 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 12 07:04:03 2005 Subject: [Rubygems-developers] Anothor UI wrinkle. Message-ID: Doing gem update I get Attempting remote installation of 'fxruby' Select which gem to install for your platform (sparc-solaris2.9) 1. fxruby 1.2.6 (mswin32) 2. fxruby 1.2.6 (ruby) 3. fxruby 1.2.5 (ruby) 4. fxruby 1.2.5 (mswin32) 5. fxruby 1.2.4 (mswin32) 6. fxruby 1.2.4 (ruby) 7. fxruby 1.2.3 (mswin32) 8. fxruby 1.2.3 (ruby) 9. fxruby 1.2.2 (mswin32) 10. fxruby 1.2.2 (ruby) 11. fxruby 1.2.1 (mswin32) 12. fxruby 1.2.1 (ruby) 13. Cancel installation > 10 I submit that the last item should be "Skip installation of this gem". Cancel installation suggests that it might abandon the update altogether. Also, when doing an install of rails on a PC I get requests for prerequisites with the form thingumybob [Yn] as the the prompt. I presumed that the upper case meant default, but this did seem to be defined. Would it make sense to allow 'a' for All prerequisites for this gem? Thank you, Hugh From hgs at dmu.ac.uk Tue Jul 12 07:40:19 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 12 07:35:18 2005 Subject: [Rubygems-developers] Anothor UI wrinkle. In-Reply-To: References: Message-ID: On Tue, 12 Jul 2005, Hugh Sasse wrote: > Also, when doing an install of rails on a PC I get requests for > prerequisites with the form > thingumybob [Yn] > as the the prompt. I presumed that the upper case meant default, > but this did seem to be defined. Would it make sense to allow 'a' > for All prerequisites for this gem? Maybe something like: --- ./user_interaction.rb.orig 2004-08-27 19:35:32.000000000 +0100 +++ ./user_interaction.rb 2005-07-12 12:36:51.540093000 +0100 @@ -116,6 +116,52 @@ end return result end + + # Ask yes, no, skip all, or all or quit. + # Returns a true for yes, false for no, :skip for skip, + # :all, for all and :quit for quit (if quit param is true). + def ask_yes_no_all(question, default=nil, quit = false) + qstr = case default + when nil + 'ynasq' + when true + 'Ynasq' + when false + 'yNasq' + when :all + 'ynAsq' + when :skip + 'ynaSq' + when :quit + 'ynasQ' + end + qstr.sub!(/q/i, '') unless quit + + result = nil + say " y = yes (once), n = no (once), ..." + say " a = yes to all , s = skip (i.e. no) to all." + say " q = quit" if quit + say "Capitalisation signifies default"" + while result.nil? + result = ask("#{question} [#{qstr}]") + result = case result + when /^y.*/i + true + when /^n.*/i + false + when /^a.*/i + :all + when /^s.*/i + :skip + when /^q.*/i + :quit if quit + else + default + end + end + return result + end + # Ask a question. Returns an answer. def ask(question) As yet untested..... Hugh From dougkearns at gmail.com Tue Jul 12 08:45:14 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Tue Jul 12 08:46:38 2005 Subject: [Rubygems-developers] Anothor UI wrinkle. In-Reply-To: References: Message-ID: <20050712124514.GU3833@localhost.localdomain> On Tue, Jul 12, 2005 at 12:09:11PM +0100, Hugh Sasse wrote: > Also, when doing an install of rails on a PC I get requests for > prerequisites with the form > thingumybob [Yn] > as the the prompt. I presumed that the upper case meant default, > but this did seem to be defined. Would it make sense to allow 'a' > for All prerequisites for this gem? Yes. I'm just starting to have a look at RubyGems and this is one of the first things I noticed. You can, of course, specify --include-dependencies as an option to 'install' but if you forget it's nice to have 'All' and 'None' as options. Regards, Doug From hgs at dmu.ac.uk Tue Jul 12 13:40:44 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 12 13:36:17 2005 Subject: [Rubygems-developers] Anothor UI wrinkle. In-Reply-To: <20050712124514.GU3833@localhost.localdomain> References: <20050712124514.GU3833@localhost.localdomain> Message-ID: On Tue, 12 Jul 2005, Doug Kearns wrote: > Yes. I'm just starting to have a look at RubyGems and this is one of the > first things I noticed. > > You can, of course, specify --include-dependencies as an option to > 'install' but if you forget it's nice to have 'All' and 'None' as > options. A bit more flesh on the bones: --- ./user_interaction.rb.orig 2004-08-27 19:35:32.000000000 +0100 +++ ./user_interaction.rb 2005-07-12 12:36:51.540093000 +0100 @@ -116,6 +116,52 @@ end return result end + + # Ask yes, no, skip all, or all or quit. + # Returns a true for yes, false for no, :skip for skip, + # :all, for all and :quit for quit (if quit param is true). + def ask_yes_no_all(question, default=nil, quit = false) + qstr = case default + when nil + 'ynasq' + when true + 'Ynasq' + when false + 'yNasq' + when :all + 'ynAsq' + when :skip + 'ynaSq' + when :quit + 'ynasQ' + end + qstr.sub!(/q/i, '') unless quit + + result = nil + say " y = yes (once), n = no (once), ..." + say " a = yes to all , s = skip (i.e. no) to all." + say " q = quit" if quit + say "Capitalisation signifies default"" + while result.nil? + result = ask("#{question} [#{qstr}]") + result = case result + when /^y.*/i + true + when /^n.*/i + false + when /^a.*/i + :all + when /^s.*/i + :skip + when /^q.*/i + :quit if quit + else + default + end + end + return result + end + # Ask a question. Returns an answer. def ask(question) --- ./remote_installer.rb.orig 2005-03-24 05:25:32.000000000 +0000 +++ ./remote_installer.rb 2005-07-12 18:34:55.576997000 +0100 @@ -477,9 +477,18 @@ def install_dependencies(dependencies, force, install_dir) return if @options[:ignore_dependencies] installed_gems = [] + all = nil dependencies.each do |dependency| - if @options[:include_dependencies] || - ask_yes_no("Install required dependency #{dependency.name}?", true) + if @options[:include_dependencies] || all || + case ask_yes_no_all("Install required dependency #{dependency.name}?", true) + when :all + all = true + true + when true + true + else + false + end remote_installer = RemoteInstaller.new(@options) installed_gems << remote_installer.install( dependency.name, Any suggestions of a good way to test the living daylights out of this? I've not done any tests on it yet.... Hugh From rubygems at freeze.org Wed Jul 13 12:14:56 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 13 12:05:46 2005 Subject: [Rubygems-developers] Running a gem server Message-ID: <20050713161456.GA1971@freeze.org> I'm having trouble getting a gem to install from a local server (machine to machine on our coporate net, both behind a firewall). From what I remember, this use to work. I have a gem installed on machine A and run gem_server. gem install gem_server On machine B I type gem install --source http://10.0.0.1:8808 where 10.0.0.1:8808 is the IP of machine B. The response I get is: gem install --source http://10.0.0.1:8808 Attempting local installation of '' Local gem file not found: *.gem Attempting remote installation of '' Updating Gem source index for: http://10.0.0.1:8808 ERROR: While executing gem ... (OpenURI::HTTPError) 503 Service Unavailable Any help will be appreciated. -- Jim Freeze From hgs at dmu.ac.uk Wed Jul 13 12:40:18 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed Jul 13 12:35:06 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <20050713161456.GA1971@freeze.org> References: <20050713161456.GA1971@freeze.org> Message-ID: On Wed, 13 Jul 2005, Jim Freeze wrote: > I'm having trouble getting a gem to install from a local [...] > gem_server > > On machine B I type > > gem install --source http://10.0.0.1:8808 > > where 10.0.0.1:8808 is the IP of machine B. > > The response I get is: > > gem install --source http://10.0.0.1:8808 [....] > Updating Gem source index for: http://10.0.0.1:8808 > ERROR: While executing gem ... (OpenURI::HTTPError) > 503 Service Unavailable I can't see why this wouldn't work. Does using -p on the gem_server help? I see the line: s = WEBrick::HTTPServer.new(:Port => options[:port] || 8808) and wonder if it might possibly be read as s = WEBrick::HTTPServer.new((:Port => options[:port]) || 8808) rather than s = WEBrick::HTTPServer.new(:Port => (options[:port] || 8808)) But surely someone would have hit that by now, and your server should have whinged about it anyway. Other things, are they running the same versions [of ruby?] at each end? I also notice gem_server in 0.8.10 doesn't seem to do much with compression, although the gem program itself does. Shouldn't give you a 503 should it.... http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.4 but that's only meant to be a temporary error, and there is the option of supplying a Retry-After header, but I'm sure you'd not see that. Hugh From rubygems at freeze.org Wed Jul 13 13:49:23 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 13 13:40:13 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: References: <20050713161456.GA1971@freeze.org> Message-ID: <20050713174923.GC2367@freeze.org> * Hugh Sasse [2005-07-13 17:40:18 +0100]: > On Wed, 13 Jul 2005, Jim Freeze wrote: > > > gem install --source http://10.0.0.1:8808 > [....] > > Updating Gem source index for: http://10.0.0.1:8808 > > ERROR: While executing gem ... (OpenURI::HTTPError) > > 503 Service Unavailable > > I can't see why this wouldn't work. Does using -p on the gem_server > help? I see the line: No. Tried that with -p 9000. No difference. > s = WEBrick::HTTPServer.new(:Port => options[:port] || 8808) > > and wonder if it might possibly be read as > > s = WEBrick::HTTPServer.new((:Port => options[:port]) || 8808) > > rather than > > s = WEBrick::HTTPServer.new(:Port => (options[:port] || 8808)) > > But surely someone would have hit that by now, and your server > should have whinged about it anyway. > > Other things, are they running the same versions [of ruby?] at each end? Machine A: % ruby -v ruby 1.8.2 (2004-12-25) [powerpc-darwin7.7.0] % gem -v 0.8.10 Machine B: % ruby -v ruby 1.8.2 (2004-12-25) [sparc-solaris2.8] % gem -v 0.8.10 Also, browsing to the gem_server 10.0.0.1:8808 works just fine. -- Jim Freeze From rubygems at freeze.org Wed Jul 13 14:34:09 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 13 14:24:57 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <20050713183240.GB2888@freeze.org> References: <20050713161456.GA1971@freeze.org> <20050713174923.GC2367@freeze.org> <20050713182956.GA2888@freeze.org> <20050713183240.GB2888@freeze.org> Message-ID: <20050713183409.GC2888@freeze.org> * Jim Freeze [2005-07-13 12:49:23 -0500]: I reversed the roles of machines A and B. I ran the server on B and gem install on A-- and it worked. So, the problem is probably when gem_server is run on the mac. The port 8808 must be open since I can browse there, but I don't see any other sharing options that I would need to set for this to work. Is there anything special one has to do to run gem_server on OS X? > Machine A: > % ruby -v > ruby 1.8.2 (2004-12-25) [powerpc-darwin7.7.0] > % gem -v > 0.8.10 > > Machine B: > % ruby -v > ruby 1.8.2 (2004-12-25) [sparc-solaris2.8] > % gem -v > 0.8.10 > > Also, browsing to the gem_server 10.0.0.1:8808 works just fine. -- Jim Freeze From chad at chadfowler.com Wed Jul 13 14:32:28 2005 From: chad at chadfowler.com (Chad Fowler) Date: Wed Jul 13 14:27:14 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <20050713183409.GC2888@freeze.org> References: <20050713161456.GA1971@freeze.org> <20050713174923.GC2367@freeze.org> <20050713182956.GA2888@freeze.org> <20050713183240.GB2888@freeze.org> <20050713183409.GC2888@freeze.org> Message-ID: Weird. I'm not fully "here" right now, since I'm working. But I find this to be surprising. I'll try it from home when I get there. Chad On 13-Jul-05, at 2:34 PM, Jim Freeze wrote: > * Jim Freeze [2005-07-13 12:49:23 -0500]: > > I reversed the roles of machines A and B. > I ran the server on B and gem install on A-- > and it worked. > > So, the problem is probably when gem_server > is run on the mac. The port 8808 must be open > since I can browse there, but I don't see any > other sharing options that I would need to set > for this to work. > > Is there anything special one has to do to run gem_server > on OS X? > > > >> Machine A: >> % ruby -v >> ruby 1.8.2 (2004-12-25) [powerpc-darwin7.7.0] >> % gem -v >> 0.8.10 >> >> Machine B: >> % ruby -v >> ruby 1.8.2 (2004-12-25) [sparc-solaris2.8] >> % gem -v >> 0.8.10 >> >> Also, browsing to the gem_server 10.0.0.1:8808 works just fine. >> > > > -- > Jim Freeze > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From hgs at dmu.ac.uk Wed Jul 13 16:40:25 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed Jul 13 16:35:56 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <20050713183409.GC2888@freeze.org> References: <20050713161456.GA1971@freeze.org> <20050713174923.GC2367@freeze.org> <20050713182956.GA2888@freeze.org> <20050713183240.GB2888@freeze.org> <20050713183409.GC2888@freeze.org> Message-ID: On Wed, 13 Jul 2005, Jim Freeze wrote: > I reversed the roles of machines A and B. [...] > So, the problem is probably when gem_server > is run on the mac. The port 8808 must be open Does anything else WEBrick-ular work on the Mac? It's that 503 error being temporary that has me puzzled..... You are bound to have tried several times with the port open.... I don't use Macs (just a fact of history rather than an expression of opinion), so am not as familiar with their quirks as some. If the problem can be isolated to WEBrick it might help. You could coax more logging out of WEBrick for some illumination, maybe. Hugh From rubygems at freeze.org Wed Jul 13 17:03:41 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 13 16:54:30 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: References: <20050713161456.GA1971@freeze.org> <20050713174923.GC2367@freeze.org> <20050713182956.GA2888@freeze.org> <20050713183240.GB2888@freeze.org> <20050713183409.GC2888@freeze.org> Message-ID: <20050713210341.GA4269@freeze.org> * Hugh Sasse [2005-07-13 21:40:25 +0100]: > On Wed, 13 Jul 2005, Jim Freeze wrote: > > Does anything else WEBrick-ular work on the Mac? It's that 503 > error being temporary that has me puzzled..... You are bound to > have tried several times with the port open.... Usually works fine. > I don't use Macs (just a fact of history rather than an expression > of opinion), so am not as familiar with their quirks as some. > > If the problem can be isolated to WEBrick it might help. You could > coax more logging out of WEBrick for some illumination, maybe. It may be some proxy problems. Here is a bit more information. 1. I ran gem_server on the mac. 2. From the mac, the gem server served up html pages fine 3. From the sun box, the pages did not show up. 4. I changed the mozilla browser on the sun to bypass the proxy when browsing to the mac. 5. The gem server pages now showed up on the sun Obviously the proxy was getting in the way of the browser, but the proxy should not be part of the picture for 'gem install' should it, unless it is given on the command line? Below is some debug info when running 'gem install'. Not sure it is any more help. BTW, no information was dispayed on the server side during this request. Probably means it never saw the request. gem install -r commandline --source http://10.80.29.42:8808 --debug Exception `Errno::ENOENT' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:12 - No such file or directory - /home/ncsg/r68606/.gemrc Attempting remote installation of 'commandline' Updating Gem source index for: http://10.80.29.42:8808 Exception `OpenURI::HTTPError' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/open-uri.rb:574 - 503 Service Unavailable Exception `OpenURI::HTTPError' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/open-uri.rb:574 - 503 Service Unavailable Exception `OpenURI::HTTPError' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/remote_installer.rb:112 - 503 Service Unavailable Exception `OpenURI::HTTPError' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/open-uri.rb:574 - 503 Service Unavailable Exception `OpenURI::HTTPError' at /project/img/local/sun/lib/ruby/site_ruby/1.8/rubygems/remote_installer.rb:112 - 503 Service Unavailable ERROR: While executing gem ... (OpenURI::HTTPError) 503 Service Unavailable > > Hugh > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -- Jim Freeze From jim at weirichhouse.org Wed Jul 13 17:33:37 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Wed Jul 13 17:28:23 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <20050713210341.GA4269@freeze.org> References: <20050713161456.GA1971@freeze.org><20050713174923.GC2367@freeze.org><20050713182956.GA2888@freeze.org><20050713183240.GB2888@freeze.org><20050713183409.GC2888@freeze.org> <20050713210341.GA4269@freeze.org> Message-ID: <25637.192.223.163.6.1121290417.squirrel@weirichhouse.org> Jim Freeze said: > Obviously the proxy was getting in the way of the browser, > but the proxy should not be part of the picture for > 'gem install' should it, unless it is given on the command line? If you have 'http_proxy' or 'HTTP_PROXY' set, we will use it as a proxy. I /think/ you can override this with the --no-http-proxy flag. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From rubygems at freeze.org Wed Jul 13 17:47:26 2005 From: rubygems at freeze.org (Jim Freeze) Date: Wed Jul 13 17:38:14 2005 Subject: [Rubygems-developers] Running a gem server In-Reply-To: <25637.192.223.163.6.1121290417.squirrel@weirichhouse.org> References: <20050713210341.GA4269@freeze.org> <25637.192.223.163.6.1121290417.squirrel@weirichhouse.org> Message-ID: <20050713214726.GA4584@freeze.org> * Jim Weirich [2005-07-13 21:33:37 -0000]: > If you have 'http_proxy' or 'HTTP_PROXY' set, we will use it as a proxy. That was it. > I /think/ you can override this with the --no-http-proxy flag. That solved the problem. Thanks. I forgot all about that silly environment variable proxy. -- Jim Freeze From jim at weirichhouse.org Wed Jul 13 20:59:10 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Wed Jul 13 20:55:21 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 Message-ID: <200507132059.11070.jim@weirichhouse.org> = Announce: RubyGems Release 0.8.11 RubyGems Version 0.8.11 is now available. This release includes a number of fixes and enhancements, including the work from the Seattle Ruby Brigade's RubyGems codefest. * Improved performance * Ability to sign gems (see http://docs.rubygems.org/read/chapter/21) * New Command: gem contents -- List the contents of an installed gem * New Command: gem rdoc -- Generate rdoc files from an installed gem == What is RubyGems? RubyGems is a package management system for Ruby applications and libraries. RubyGems one command download makes installing Ruby software fun and enjoyable again. (Ok, not really.) Many gems are available for download from the RubyForge site. Browse the list of gems with a "gem list --remote" command and download what you need with a simple "gem install ". RubyGems takes care of the details of installing, not only the gem you requested, but also any gems needed by the software you selected. == RubyGems Statistics * About 326 different gems available (Around 100 new gems since the 0.8.10 release) * Nearly 64,000 downloads of the RubyGems software * Almost 600,000 gem downloads If you are interested in finding out when new gems are released, I maintain an RSS feed at http://onestepback.org/gemwatch.rss. == How can I get RubyGems? 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 all (you may need admin/root privilege) == Recent Changes * -y is a synonym for --include-dependencies. * Better handling of errors in the top level rescue clause. * Package list command (e.g. gem inspect GEM). * .gemrc now allows cvsrc-like options to set defaults per subcommand. * The autorequire gem spec field will now accept a list. * Substituted Time for Date in specs, increasing performance dramatically. * Fixed reported bug of gem directories ending in "-" (reported by Erik Hatcher). * Fixed but in installer that caused dependency installation to not work. * Added Paul Duncan's gem signing patch. * Added Mark Hubbart's Framework patch (for better integration with OS X). * Added David Glasser's install-from-mirror patch. * Additional internal structural cleanup and test reorganization. == What's Next We will probably see one more release in the 0.8.x series (hopefully soon) where the source index download function will be revised to perform better with a large number gems. After that, the 0.9.x series will start unifying the local and remote installers to get more consistent behavior. == Thanks Major contributors to this release include: * Thanks to the Seattle Ruby Brigade (Doug Beaver, Ryan Davis, Pat Eyler, Eric Hodel, Evan Webb, and Aaron Johnson) for the work they did in their code fest. * Thanks to Paul Duncan for the gem signing patch. * Thanks to Mark Hubbart for the Mac OS X framework patch. * Thanks to Doug Kearns for catching some embarassing typos in several error messages. Keep those gems coming! -- Jim & Chad (for the RubyGems team) From agorilla at gmail.com Wed Jul 13 21:18:48 2005 From: agorilla at gmail.com (Bill Guindon) Date: Wed Jul 13 21:13:34 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <200507132059.11070.jim@weirichhouse.org> References: <200507132059.11070.jim@weirichhouse.org> Message-ID: <67a22292050713181841b0f5b6@mail.gmail.com> Finally got my setup working on WinXP the other day (did a brute force removal of all gem related items, killed GEM_PATH env. variable, and reinstalled in default dir). Anyway, did the update, and all seems fine. On 7/13/05, Jim Weirich wrote: > = Announce: RubyGems Release 0.8.11 > > RubyGems Version 0.8.11 is now available. This release includes a > number of fixes and enhancements, including the work from the Seattle > Ruby Brigade's RubyGems codefest. > > * Improved performance > * Ability to sign gems (see http://docs.rubygems.org/read/chapter/21) > * New Command: gem contents -- List the contents of an installed gem > * New Command: gem rdoc -- Generate rdoc files from an installed gem > > == What is RubyGems? > > RubyGems is a package management system for Ruby applications and > libraries. RubyGems one command download makes installing Ruby software > fun and enjoyable again. (Ok, not really.) > > Many gems are available for download from the RubyForge site. Browse > the list of gems with a "gem list --remote" command and download what > you need with a simple "gem install ". RubyGems takes care > of the details of installing, not only the gem you requested, but also > any gems needed by the software you selected. > > == RubyGems Statistics > > * About 326 different gems available (Around 100 new gems since the > 0.8.10 release) > * Nearly 64,000 downloads of the RubyGems software > * Almost 600,000 gem downloads > > If you are interested in finding out when new gems are released, I > maintain an RSS feed at http://onestepback.org/gemwatch.rss. > > == How can I get RubyGems? > > 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 all (you may need admin/root privilege) > > == Recent Changes > > * -y is a synonym for --include-dependencies. > * Better handling of errors in the top level rescue clause. > * Package list command (e.g. gem inspect GEM). > * .gemrc now allows cvsrc-like options to set defaults per subcommand. > * The autorequire gem spec field will now accept a list. > * Substituted Time for Date in specs, increasing performance > dramatically. > * Fixed reported bug of gem directories ending in "-" (reported by > Erik Hatcher). > * Fixed but in installer that caused dependency installation to not > work. > * Added Paul Duncan's gem signing patch. > * Added Mark Hubbart's Framework patch (for better integration with OS > X). > * Added David Glasser's install-from-mirror patch. > * Additional internal structural cleanup and test reorganization. > > == What's Next > > We will probably see one more release in the 0.8.x series (hopefully > soon) where the source index download function will be revised to > perform better with a large number gems. > > After that, the 0.9.x series will start unifying the local and remote > installers to get more consistent behavior. > > == Thanks > > Major contributors to this release include: > > * Thanks to the Seattle Ruby Brigade (Doug Beaver, Ryan Davis, Pat > Eyler, Eric Hodel, Evan Webb, and Aaron Johnson) for the work they > did in their code fest. > > * Thanks to Paul Duncan for the gem signing patch. > > * Thanks to Mark Hubbart for the Mac OS X framework patch. > > * Thanks to Doug Kearns for catching some embarassing typos in several > error messages. > > Keep those gems coming! > > -- Jim & Chad (for the RubyGems team) > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Bill Guindon (aka aGorilla) From dougkearns at gmail.com Thu Jul 14 00:55:35 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Thu Jul 14 00:58:50 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050710072200.GF3976@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> Message-ID: <20050714045535.GA17252@localhost.localdomain> One more. Regards, Doug Index: gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.63 diff -u -r1.63 gem_commands.rb --- gem_commands.rb 10 Jul 2005 11:17:29 -0000 1.63 +++ gem_commands.rb 14 Jul 2005 04:13:06 -0000 @@ -1179,7 +1179,7 @@ class ContentsCommand < Command include CommandAids def initialize - super('contents','Disply the contents of the installed gems', {:list => true, :specdirs => [] }) + super('contents','Display the contents of the installed gems', {:list => true, :specdirs => [] }) add_option("-l","--list",'List the files inside a Gem') do |v,o| o[:list] = true end From hgs at dmu.ac.uk Thu Jul 14 06:31:51 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu Jul 14 06:26:42 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <200507132059.11070.jim@weirichhouse.org> References: <200507132059.11070.jim@weirichhouse.org> Message-ID: On Wed, 13 Jul 2005, Jim Weirich wrote: > = Announce: RubyGems Release 0.8.11 This patch I sent never made it. Is it fundamentally flawed, or does it need specific tweaking? Hugh --- ./lib/rubygems/doc_manager.rb.orig 2005-02-28 23:26:58.000000000 +0000 +++ ./lib/rubygems/doc_manager.rb 2005-06-10 12:42:58.927496000 +0100 @@ -35,7 +35,8 @@ end def generate_rdoc - return if @spec.has_rdoc == false + # return if @spec.has_rdoc == false + # Now taken care of with rescue clause. require 'fileutils' Gem::FilePermissionError.new(@doc_dir) if File.exist?(@doc_dir) && !File.writable?(@doc_dir) FileUtils.mkdir_p @doc_dir unless File.exist?(@doc_dir) @@ -58,6 +59,8 @@ r.document(['--quiet', '--op', rdoc_dir] + @rdoc_args.flatten + source_dirs) rescue Errno::EACCES => e raise Gem::FilePermissionError.new(File.dirname(e.message.split("-")[1].strip)) + rescue => e + say "Performing RDoc failed with \"#{e.message}\", but it is known to crash occasionally" end #TODO: Why is this throwing an error? #ri = RDoc::RDoc.new From hgs at dmu.ac.uk Thu Jul 14 06:36:55 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu Jul 14 06:31:48 2005 Subject: [Rubygems-developers] patchlet for ChangeLog Message-ID: typo fix. Hugh --- ./ChangeLog.orig 2005-07-08 14:07:26.000000000 +0100 +++ ./ChangeLog 2005-07-14 11:35:55.831211000 +0100 @@ -68,7 +68,7 @@ * lib/rubygems/gem_commands.rb (Gem::UpdateCommand::do_rubygems_update): Update --system now runs - the ruby command directly rather than trying to load teh + the ruby command directly rather than trying to load the update-rubygems command. There were too many things to go wrong with the old way. From chad at chadfowler.com Thu Jul 14 08:34:47 2005 From: chad at chadfowler.com (Chad Fowler) Date: Thu Jul 14 08:29:34 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050714045535.GA17252@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> <20050714045535.GA17252@localhost.localdomain> Message-ID: On 14-Jul-05, at 12:55 AM, Doug Kearns wrote: > One more. > > Regards, > Doug > > Index: gem_commands.rb > =================================================================== > RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v > retrieving revision 1.63 > diff -u -r1.63 gem_commands.rb > --- gem_commands.rb 10 Jul 2005 11:17:29 -0000 1.63 > +++ gem_commands.rb 14 Jul 2005 04:13:06 -0000 > @@ -1179,7 +1179,7 @@ > class ContentsCommand < Command > include CommandAids > def initialize > - super('contents','Disply the contents of the installed > gems', {:list => true, :specdirs => [] }) > + super('contents','Display the contents of the installed > gems', {:list => true, :specdirs => [] }) > add_option("-l","--list",'List the files inside a Gem') do | > v,o| > o[:list] = true > end > _______________________________________________ Thanks! I went to do the patch and it looked like Jim had already picked it up, so it's in. Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20050714/af810f81/attachment.htm From chad at chadfowler.com Thu Jul 14 08:37:14 2005 From: chad at chadfowler.com (Chad Fowler) Date: Thu Jul 14 08:31:59 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: References: <200507132059.11070.jim@weirichhouse.org> Message-ID: <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> On 14-Jul-05, at 6:31 AM, Hugh Sasse wrote: > On Wed, 13 Jul 2005, Jim Weirich wrote: > > >> = Announce: RubyGems Release 0.8.11 >> > > This patch I sent never made it. Is it fundamentally flawed, or > does it need specific tweaking? > > Hugh > > > --- ./lib/rubygems/doc_manager.rb.orig 2005-02-28 > 23:26:58.000000000 +0000 > +++ ./lib/rubygems/doc_manager.rb 2005-06-10 > 12:42:58.927496000 +0100 > @@ -35,7 +35,8 @@ > end > > def generate_rdoc > - return if @spec.has_rdoc == false > + # return if @spec.has_rdoc == false > + # Now taken care of with rescue clause. > require 'fileutils' > Gem::FilePermissionError.new(@doc_dir) if File.exist? > (@doc_dir) && !File.writable?(@doc_dir) > FileUtils.mkdir_p @doc_dir unless File.exist?(@doc_dir) > @@ -58,6 +59,8 @@ > r.document(['--quiet', '--op', rdoc_dir] + > @rdoc_args.flatten + source_dirs) > rescue Errno::EACCES => e > raise Gem::FilePermissionError.new(File.dirname > (e.message.split("-")[1].strip)) > + rescue => e > + say "Performing RDoc failed with \"#{e.message}\", but > it is known to crash occasionally" > end > #TODO: Why is this throwing an error? > #ri = RDoc::RDoc.new > Sorry, Hugh. I think that was a simple miss on our part. Though, now that I went to add it, it seems like the first line _should_ return if @spec.has_rdoc == false and the rdoc flag wasn't passed on the command line. That would give the gem author the ability to control default behavior and the end user the ability to override it. What do you think? Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20050714/745e36bd/attachment-0001.htm From chad at chadfowler.com Thu Jul 14 08:38:09 2005 From: chad at chadfowler.com (Chad Fowler) Date: Thu Jul 14 08:32:52 2005 Subject: [Rubygems-developers] patchlet for ChangeLog In-Reply-To: References: Message-ID: <0CC2E47C-0458-4EDE-9E02-B1DBC0FA94C8@chadfowler.com> On 14-Jul-05, at 6:36 AM, Hugh Sasse wrote: > typo fix. > Hugh > > --- ./ChangeLog.orig 2005-07-08 14:07:26.000000000 +0100 > +++ ./ChangeLog 2005-07-14 11:35:55.831211000 +0100 > @@ -68,7 +68,7 @@ > > * lib/rubygems/gem_commands.rb > (Gem::UpdateCommand::do_rubygems_update): Update --system > now runs > - the ruby command directly rather than trying to load teh > + the ruby command directly rather than trying to load the > update-rubygems command. There were too many things to go > wrong > with the old way. > > > > Got it, thanks Chad From hgs at dmu.ac.uk Thu Jul 14 09:24:43 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu Jul 14 09:19:39 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> References: <200507132059.11070.jim@weirichhouse.org> <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> Message-ID: On Thu, 14 Jul 2005, Chad Fowler wrote: > > On 14-Jul-05, at 6:31 AM, Hugh Sasse wrote: > >> >> --- ./lib/rubygems/doc_manager.rb.orig 2005-02-28 23:26:58.000000000 +0000 >> +++ ./lib/rubygems/doc_manager.rb 2005-06-10 12:42:58.927496000 +0100 >> @@ -35,7 +35,8 @@ >> end >> >> def generate_rdoc >> - return if @spec.has_rdoc == false >> + # return if @spec.has_rdoc == false >> + # Now taken care of with rescue clause. [...] > > > Sorry, Hugh. I think that was a simple miss on our part. > > Though, now that I went to add it, it seems like the first line _should_ > return if @spec.has_rdoc == false and the rdoc flag wasn't passed on the > command line. That would I remember discussion about that flag only being a workaround for the rdoc bug[s]. Organic memory may not serve me well here though... > give the gem author the ability to control default behavior and the end user > the ability to override it. What do you think? Then, IMHO, it should default to true regardless of gem authors' preferences. One of the complaints raised against Ruby /was|is/ lack of docs, and with {you, Dave, Andy, DHH, et al}'s efforts this problem is decreasing, but it should take effort to not provide them. Yes, people on small systems may wish to do that, not enough disk space, etc. People keep telling me small systems are less of a problem these days, though :-) > > Chad Hugh From chad at chadfowler.com Thu Jul 14 11:38:47 2005 From: chad at chadfowler.com (chad@chadfowler.com) Date: Thu Jul 14 10:26:38 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: References: <200507132059.11070.jim@weirichhouse.org> <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> Message-ID: <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> > On Thu, 14 Jul 2005, Chad Fowler wrote: > >> >> On 14-Jul-05, at 6:31 AM, Hugh Sasse wrote: >> >>> >>> --- ./lib/rubygems/doc_manager.rb.orig 2005-02-28 23:26:58.000000000 >>> +0000 >>> +++ ./lib/rubygems/doc_manager.rb 2005-06-10 12:42:58.927496000 >>> +0100 >>> @@ -35,7 +35,8 @@ >>> end >>> >>> def generate_rdoc >>> - return if @spec.has_rdoc == false >>> + # return if @spec.has_rdoc == false >>> + # Now taken care of with rescue clause. > [...] >> >> >> Sorry, Hugh. I think that was a simple miss on our part. >> >> Though, now that I went to add it, it seems like the first line _should_ >> return if @spec.has_rdoc == false and the rdoc flag wasn't passed on the >> command line. That would > > I remember discussion about that flag only being a workaround for > the rdoc bug[s]. Organic memory may not serve me well here > though... > Yea, though it was a case where rubygems was generating rdoc for a "super gem" whose only job was to cause other gems to be installed (over simplifying), so it actually makes no sense for the gem in question to have rdoc docs. >> give the gem author the ability to control default behavior and the end >> user >> the ability to override it. What do you think? > > Then, IMHO, it should default to true regardless of gem authors' > preferences. One of the complaints raised against Ruby /was|is/ lack of > docs, and with {you, Dave, Andy, DHH, et al}'s efforts this problem is > decreasing, but it should take effort to not provide them. Yes, > people on small systems may wish to do that, not enough disk space, > etc. People keep telling me small systems are less of a problem > these days, though :-) Agreed, though it actually _does_ require effort on the part of the gem author to not allow rdoc to be generated. If you don't put "has_rdoc", it will generate rdocs. The only way to make it NOT generate rdocs is to explicitly set has_rdoc to false in your gem spec. Make sense? Chad From scholz at scriptolutions.com Thu Jul 14 10:49:16 2005 From: scholz at scriptolutions.com (Lothar Scholz) Date: Thu Jul 14 10:44:05 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: References: <200507132059.11070.jim@weirichhouse.org> Message-ID: <17118224421.20050714214916@scriptolutions.com> Hello Hugh, Thursday, July 14, 2005, 5:31:51 PM, you wrote: HS> On Wed, 13 Jul 2005, Jim Weirich wrote: >> = Announce: RubyGems Release 0.8.11 HS> This patch I sent never made it. Is it fundamentally flawed, or HS> does it need specific tweaking? This patch does not solve the problem for this (IMHO stupid) flag was introduced. Calling rdoc for rails runs into an infinite loop at the moment so the rescue clause is never reached. Tell D.H.H. to add an empty ".document" into the directory, it is already a fault on this side as the templates shouldn't be indexed because they are not ruby code. -- Best regards, Lothar Scholz mailto:scholz@scriptolutions.com From scholz at scriptolutions.com Thu Jul 14 10:53:04 2005 From: scholz at scriptolutions.com (Lothar Scholz) Date: Thu Jul 14 10:47:52 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> References: <200507132059.11070.jim@weirichhouse.org> <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> Message-ID: <11918452109.20050714215304@scriptolutions.com> Hello chad, Thursday, July 14, 2005, 10:38:47 PM, you wrote: ccc> Yea, though it was a case where rubygems was generating rdoc for a "super ccc> gem" whose only job was to cause other gems to be installed (over ccc> simplifying), so it actually makes no sense for the gem in question to ccc> have rdoc docs. ccc> Agreed, though it actually _does_ require effort on the part of the gem ccc> author to not allow rdoc to be generated. If you don't put "has_rdoc", it ccc> will generate rdocs. The only way to make it NOT generate rdocs is to ccc> explicitly set has_rdoc to false in your gem spec. Even for those the decision should be left to the user. If he uses "--force-rdoc" on the command line, he want to see rdoc pages, even if they are empty which just makes clear that this is a "super gem". And if the gem author really care about documentation it will show a nice html page that tells the user what this gem is and why it disables some of the rdoc features, but simply forbidding everything is not good behaviour and definitely not what is expected by "newbies". -- Best regards, Lothar Scholz mailto:scholz@scriptolutions.com From chad at chadfowler.com Thu Jul 14 12:03:21 2005 From: chad at chadfowler.com (chad@chadfowler.com) Date: Thu Jul 14 10:51:11 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <17118224421.20050714214916@scriptolutions.com> References: <200507132059.11070.jim@weirichhouse.org> <17118224421.20050714214916@scriptolutions.com> Message-ID: <34355.216.77.69.67.1121357001.squirrel@216.77.69.67> > Hello Hugh, > > Thursday, July 14, 2005, 5:31:51 PM, you wrote: > > HS> On Wed, 13 Jul 2005, Jim Weirich wrote: > >>> = Announce: RubyGems Release 0.8.11 > > HS> This patch I sent never made it. Is it fundamentally flawed, or > HS> does it need specific tweaking? > > This patch does not solve the problem for this (IMHO stupid) flag was > introduced. Calling rdoc for rails runs into an infinite loop at the > moment so the rescue clause is never reached. > There was a problem that led to this flag being used to inhibit RDoc (the flag has been there since the very first gem spec was ever written). But the problem that led to it is separate from our desire to support the flag. There are some gems for which RDoc generation is pointless. This flag is for those gems. If you would consider gems like the railties gem or fixrbconfig as examples, you would understand. On a side note, calling the work of others "stupid" isn't going to win you any credibility. I'm not interested in reading any more of your caustic remarks. Please temper your attitude on this list. Chad From chad at chadfowler.com Thu Jul 14 12:04:34 2005 From: chad at chadfowler.com (chad@chadfowler.com) Date: Thu Jul 14 10:52:24 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <11918452109.20050714215304@scriptolutions.com> References: <200507132059.11070.jim@weirichhouse.org> <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> <11918452109.20050714215304@scriptolutions.com> Message-ID: <34664.216.77.69.67.1121357074.squirrel@216.77.69.67> > Hello chad, > > Thursday, July 14, 2005, 10:38:47 PM, you wrote: > > > ccc> Yea, though it was a case where rubygems was generating rdoc for a > "super > ccc> gem" whose only job was to cause other gems to be installed (over > ccc> simplifying), so it actually makes no sense for the gem in question > to > ccc> have rdoc docs. > > ccc> Agreed, though it actually _does_ require effort on the part of the > gem > ccc> author to not allow rdoc to be generated. If you don't put > "has_rdoc", it > ccc> will generate rdocs. The only way to make it NOT generate rdocs is > to > ccc> explicitly set has_rdoc to false in your gem spec. > > Even for those the decision should be left to the user. If he uses > "--force-rdoc" on the command line, he want to see rdoc pages, even if > they are empty which just makes clear that this is a "super gem". This is what I was suggesting. From hgs at dmu.ac.uk Thu Jul 14 11:30:06 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu Jul 14 11:25:00 2005 Subject: [Rubygems-developers] [ANNOUNCE] RubyGems Release 0.8.11 In-Reply-To: <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> References: <200507132059.11070.jim@weirichhouse.org> <4B3162FF-CEB1-490A-9422-E7D638538457@chadfowler.com> <28607.216.77.69.67.1121355527.squirrel@216.77.69.67> Message-ID: On Thu, 14 Jul 2005, chad@chadfowler.com wrote: >> On Thu, 14 Jul 2005, Chad Fowler wrote: >> >>> >>> On 14-Jul-05, at 6:31 AM, Hugh Sasse wrote: >>> >> I remember discussion about that flag only being a workaround for >> the rdoc bug[s]. Organic memory may not serve me well here >> though... >> > > Yea, though it was a case where rubygems was generating rdoc for a "super > gem" whose only job was to cause other gems to be installed (over > simplifying), so it actually makes no sense for the gem in question to > have rdoc docs. OK, though I'm not sure that having them would be bad. Maybe something is needed to make the rdocs say words to the effect of "If this rdoc stuff looks completely bonkers, then it is because of #{one_reason_of_several}", rather than just producing empty docs or docs with other wierdness. >>> give the gem author the ability to control default behavior and the end >>> user >>> the ability to override it. What do you think? >> >> Then, IMHO, it should default to true regardless of gem authors' [...] >> decreasing, but it should take effort to not provide them. Yes, [...] > > > Agreed, though it actually _does_ require effort on the part of the gem > author to not allow rdoc to be generated. If you don't put "has_rdoc", it > will generate rdocs. The only way to make it NOT generate rdocs is to > explicitly set has_rdoc to false in your gem spec. > > Make sense? Yes, but I think it should warn loudly about this, at least until standard ruby can output awful smells on most platforms :-) As for Lothar's observation about infinite loops, we could put a Thread based timeout around it. I'm just wondering how YAGNI that is, though. Will rails || rdoc be healed soon? I'm not really on the inside of those projects so don't know how squeaky that wheel is. #{raise MixedMetaphorError} > > Chad Hugh From jim at weirichhouse.org Mon Jul 18 01:20:28 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Mon Jul 18 01:15:06 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 Message-ID: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> This is an outline of my plan for version 0.8.12. The primary goal of this release is to speed up the source index update for the gem command and to decrease the load on the RubyForge gem server. My idea covers two areas (1) incremental updates, and (2) archiving old gems. (1) Incremental Updates Currently the static gem server used by RubyForge has the following directory structure: * topdir * yaml (uncompressed source index) * yaml.Z (compressed source index) * gems * aaa.gem * bbb.gem * ... The proposal would change this to: * topdir * yaml (uncompressed source index) * yaml.Z (compressed source index) * quick * index * index.Z * aaa.gemspec * aaa.gemspec.Z * bbb.gemspec * bbb.gemspec.Z * ... * gems * aaa.gem * bbb.gem * ... The main addition is the "quick" directory. The quick/index file contains a list of gems and a MD5 hash of the corresponding gemspec. Something like this: builder-0.1.1 68673a832739659790fb02e4227d226f builder-1.0.0 9a85bbd956dafd5100de7b6f6cafe4ea builder-1.2.1 43cd2a1edceedebbb46fed45b29b596a builder-1.2.3 952bb54040e301b009d7fb646fff1f15 flexmock-0.0.3 cc235f560a20c103807c299599317d8b rake-0.4.14 367df8d0cca063f3fb132dd00dac1a82 rake-0.4.15.1 fcdf87575c74ca96ffe53061529f9388 rake-0.4.15 1207708d1a0e1fb4979e8d6f8b9b45d1 rake-0.5.0.2 9709b57cc070895261e2d7f48252d3b3 rake-0.5.3 19ecc210059f0e67421c41343006b449 rake-0.5.4.4 370ab5df156158417a0a05b0287dc337 The first thing the gem client will do is download the quick index. If the quick index is not available, it will fall back to the current source update algorithm. This allows the new gem command to remain compatible with servers running the old software. In particular, if we decide to /not/ update the gem_server command, it will still continue to work. Once the quick/index is downloaded, the gem command will audit the list of known gems for the given source and determine two lists: (a) the gems that are no longer available on the server, and (b) the gems that are new or updated (different MD5 hashes). The gemspecs in the the (a) list will just be dropped from the cached source list. The gemspecs in (b) will be downloaded from the quick directory and used to incrementally update the cached source index. The gemspecs available in the quick directory will be in "abbreviated" format. Abbreviated gemspecs don't contain the entire gemspec found in the .gem file. In particular, the 'files' field is empty. This makes the spec *much* smaller. Since this copy of the gemspec is only used for searches in the cache, omitting this data is not a problem. In fact, the current software abbreviates the gemspec on the client side to keep the size of the source cache smaller (we did this when we were having problems loading large yaml files). Abbreviating the gemspec on the server side means we get the benifit of smaller and quicker downloads as well. The net effect of this change is that instead of download a *huge* yaml file everytime someone updates a gem (which happens every day), we only download a reasonably sized index file, plus the (abbreviated) gemspecs that have changed since the last time we synced the source index cache. I haven't run the numbers yet on anticipated savings, but I'm thinking that it could be quite significant. Some open questions: (A) I show storing both the index and index.Z, both the gemspec and gemspec.Z. Is there any reason to store the non-compressed version? (B) If there are a *lot* of gems that are out of date, there may be a point were downloading a single, large yaml file may be more efficient than downloading a bunch of smaller files. At that point we could switch to the current algorithm. I have a generate_yaml_index.rb file updated to generate the quick index (not checked in yet, but will be soon). I haven't updated the client algorithm yet. (2) Archiving Old Gems Part of the problem is that one a gem is available on RubyForge, it is always available on RubyForge. The source index keeps expanding and expanding. If we don't have an archival policy, this will continue to grow until we need to fix it again. While it is cool that we have all Rails version back to verion 0.5 (or whatever, I didn't actually look it up), I don't think anyone is really interested in downloading it anymore. Here's a proposal. We update the generate_yaml_index.rb command to move gems to an archive directory as long as both of the following conditions are true: * All gems uploaded in the last M months are directly available. * At least min(N,V) versions of a gem are available (where V is total number of versions uploaded) Of course, we can pick M and N to be whatever makes sense. For example M=12 and N=3 would keep the last three version around, plus any versions available in the last year. I imagine that M and N will be command line arguments to the generate_yaml_script.rb to that others running their own servers can set their own policies. Gems that are archived will be moved from the gem directory to an archive/gem directory. The archive directory will have its own yaml file and quick index (in the format described in part (1) above). This means that gems moved the archive are still available by using the --source option on the command line. For example, if rails-0.5 is in the archive, I can still get it with the command: gem install --version=0.5 rails --source=http://gems.rubyforge.org/archive By incorporating the archive logic in the generate_yaml_index.rb command, it becomes very easy to manage a gem server. Open questions: (A) There is a date in the gemspec. Should the algorithm use the gemspec date, or the date of the file in the file system? (3) Unrelated Question: I am considering renaming the generate_yaml_index.rb command to gem_index (or maybe gem_server_index ... suggestions welcome). This bring the command in line with the convention that all gem releated command begin with the letters "gem". And it does more then just generate yaml, a new name will reflect this better. Any comments? I see this as the last change for the 0.8.xxx series for RubyGems. I would like version 0.9.xxx to start addressing the differences in behavior in the local and remote installers and to start handling platform issues more intelligently. I've got some thoughts on this that I will write up separately. Feedback on the above? -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From dougkearns at gmail.com Mon Jul 18 06:31:30 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Mon Jul 18 06:35:29 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050710072200.GF3976@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> Message-ID: <20050718103130.GD3554@localhost.localdomain> On Sun, Jul 10, 2005 at 05:22:00PM +1000, Doug Kearns wrote: > Patch against CVS HEAD. One more... Regards, Doug Index: lib/rubygems/gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.64 diff -u -r1.64 gem_commands.rb --- lib/rubygems/gem_commands.rb 14 Jul 2005 05:21:07 -0000 1.64 +++ lib/rubygems/gem_commands.rb 18 Jul 2005 10:30:40 -0000 @@ -282,7 +282,7 @@ def initialize super( 'cert', - 'Adjust RubyGems certificate settings.', + 'Adjust RubyGems certificate settings', { }) From chad at chadfowler.com Mon Jul 18 06:49:49 2005 From: chad at chadfowler.com (Chad Fowler) Date: Mon Jul 18 06:44:27 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <20050718103130.GD3554@localhost.localdomain> References: <20050710072200.GF3976@localhost.localdomain> <20050718103130.GD3554@localhost.localdomain> Message-ID: <8DA8B7D4-0C4F-47A7-AFD9-782A59B7A3E9@chadfowler.com> Done, thanks. Chad On 18-Jul-05, at 6:31 AM, Doug Kearns wrote: > On Sun, Jul 10, 2005 at 05:22:00PM +1000, Doug Kearns wrote: > >> Patch against CVS HEAD. >> > > One more... > > Regards, > Doug > > Index: lib/rubygems/gem_commands.rb > =================================================================== > RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v > retrieving revision 1.64 > diff -u -r1.64 gem_commands.rb > --- lib/rubygems/gem_commands.rb 14 Jul 2005 05:21:07 -0000 1.64 > +++ lib/rubygems/gem_commands.rb 18 Jul 2005 10:30:40 -0000 > @@ -282,7 +282,7 @@ > def initialize > super( > 'cert', > - 'Adjust RubyGems certificate settings.', > + 'Adjust RubyGems certificate settings', > { > }) > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From chad at chadfowler.com Mon Jul 18 07:46:14 2005 From: chad at chadfowler.com (Chad Fowler) Date: Mon Jul 18 07:40:54 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: Excellent ideas! On 18-Jul-05, at 1:20 AM, Jim Weirich wrote: > > * topdir > * yaml (uncompressed source index) > * yaml.Z (compressed source index) > * quick > * index > * index.Z > * aaa.gemspec > * aaa.gemspec.Z > * bbb.gemspec > * bbb.gemspec.Z > * ... > * gems > * aaa.gem > * bbb.gem > * ... > Maybe now is the time to start using .gz instead of .Z? > > Some open questions: > > (A) I show storing both the index and index.Z, both the gemspec and > gemspec.Z. Is there any reason to store the non-compressed > version? > I don't see a reason. The non-compressed yaml index is only still there to support old clients. We could probably kill it at this point, I'd think.....but on second though, I just checked the webalizer stats, and it looks like a LOT of people are still hitting the yaml file uncompressed. Tom, are you capturing user agent yet in Apache? We send the rubygems version as part of user agent, so we could look at this and see what's hitting /yaml directly. > (B) If there are a *lot* of gems that are out of date, there may be a > point were downloading a single, large yaml file may be more > efficient than downloading a bunch of smaller files. At that > point we could switch to the current algorithm. > I think it would be good to try it without the single large download first and see how it goes. It would simplify things if we didn't have to have a special case. > > (A) There is a date in the gemspec. Should the algorithm use the > gemspec date, or the date of the file in the file system? > I would use the gemspec date. > (3) Unrelated Question: > I am considering renaming the generate_yaml_index.rb command to > gem_index (or maybe gem_server_index ... suggestions welcome). This > bring the command in line with the convention that all gem releated > command begin with the letters "gem". And it does more then just > generate yaml, a new name will reflect this better. Any comments? > Agreed. Another question: could we somehow get gem_server and gem_server_index to use the same code? I'm afraid we'll end up with one that works and one that doesn't. And, since fewer people use gem_server to actually serve gems, we may not notice immediately that it's broken. That would be icky. Overall, this sounds great! I'm finally freeing up a bit, so maybe we can remote-pair on some of it. Chad From jim at weirichhouse.org Mon Jul 18 07:57:01 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Mon Jul 18 07:52:20 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: <200507180757.01720.jim@weirichhouse.org> On Monday 18 July 2005 07:46 am, Chad Fowler wrote: > Maybe now is the time to start using .gz instead of .Z? Actually, I tried uncompressing some of the compressed files using gunzip and it failed. I also tried unzip. Are the compressed files produced by Ruby's zlib deflate compatible with anything? -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From tom at infoether.com Mon Jul 18 09:04:04 2005 From: tom at infoether.com (Tom Copeland) Date: Mon Jul 18 08:58:46 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: <1121691844.13518.93.camel@hal> On Mon, 2005-07-18 at 07:46 -0400, Chad Fowler wrote: > I don't see a reason. The non-compressed yaml index is only still > there to support old clients. We could probably kill it at this > point, I'd think.....but on second though, I just checked the > webalizer stats, and it looks like > a LOT of people are still hitting the yaml file uncompressed. > > Tom, are you capturing user agent yet in Apache? We send the > rubygems version as part of user agent, so we could look at this and > see what's hitting /yaml directly. Hm, I haven't been... but now we are; I just turned "combined" logging format for that vhost. Here's the first couple dozen requests, mostly from RubyGems 0.8.11: ============================== 206.228.241.250 - - [18/Jul/2005:08:53:30 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:53:36 -0400] "GET /gems/rails-0.13.1.gem HTTP/1.1" 200 86016 "-" "RubyGems/0.8.11" 206.228.241.250 - - [18/Jul/2005:08:53:36 -0400] "GET /gems/sqlite3-ruby-1.1.0.gem HTTP/1.1" 200 39424 "-" "RubyGems/0.8.11" 218.219.149.62 - - [18/Jul/2005:08:53:45 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:53:46 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:53:51 -0400] "GET /gems/log4r-1.0.5.gem HTTP/1.1" 200 311215 "-" "RubyGems/0.8.11" 218.219.149.62 - - [18/Jul/2005:08:53:55 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:53:58 -0400] "GET /gems/needle-1.2.0.gem HTTP/1.1" 200 125440 "-" "RubyGems/0.8.11" 218.219.149.62 - - [18/Jul/2005:08:54:15 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:54:16 -0400] "GET /gems/jabber4r-0.7.0.gem HTTP/1.1" 200 26566 "-" "RubyGems/0.8.11" 218.219.149.62 - - [18/Jul/2005:08:54:19 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 218.219.149.62 - - [18/Jul/2005:08:54:19 -0400] "GET /gems/ruby-growl-1.0.0.gem HTTP/1.1" 200 8704 "-" "RubyGems/0.8.11" 218.219.149.62 - - [18/Jul/2005:08:54:28 -0400] "GET /gems/damagecontrol-0.5.0.1404.gem HTTP/1.1" 200 443904 "-" "RubyGems/0.8.11" 207.166.198.7 - - [18/Jul/2005:08:54:41 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 62.143.169.229 - - [18/Jul/2005:08:55:14 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 62.143.169.229 - - [18/Jul/2005:08:55:21 -0400] "GET /yaml.Z HTTP/1.1" 200 604624 "-" "RubyGems/0.8.10" 62.143.169.229 - - [18/Jul/2005:08:56:20 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 212.25.248.99 - - [18/Jul/2005:08:56:55 -0400] "HEAD /yaml HTTP/1.1" 200 0 "-" "-" 212.25.248.99 - - [18/Jul/2005:08:57:17 -0400] "GET /gems/sqlite3-ruby-1.1.0-mswin32.gem HTTP/1.1" 200 78336 "-" "RubyGems/0.8.10" ============================== Yours, Tom From dougkearns at gmail.com Mon Jul 18 09:31:15 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Mon Jul 18 09:32:11 2005 Subject: [Rubygems-developers] Typo in gem_commands.rb In-Reply-To: <8DA8B7D4-0C4F-47A7-AFD9-782A59B7A3E9@chadfowler.com> References: <20050710072200.GF3976@localhost.localdomain> <20050718103130.GD3554@localhost.localdomain> <8DA8B7D4-0C4F-47A7-AFD9-782A59B7A3E9@chadfowler.com> Message-ID: <20050718133115.GE3554@localhost.localdomain> On Mon, Jul 18, 2005 at 06:49:49AM -0400, Chad Fowler wrote: > Done, thanks. Sorry I missed this one before... Regards, Doug Index: lib/rubygems/gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.64 diff -u -r1.64 gem_commands.rb --- lib/rubygems/gem_commands.rb 14 Jul 2005 05:21:07 -0000 1.64 +++ lib/rubygems/gem_commands.rb 18 Jul 2005 12:40:39 -0000 @@ -282,17 +282,17 @@ def initialize super( 'cert', - 'Adjust RubyGems certificate settings.', + 'Adjust RubyGems certificate settings', { }) - add_option('-a', '--add CERT', 'Add a trusted certificate.') do |value, options| + add_option('-a', '--add CERT', 'Add a trusted certificate') do |value, options| cert = OpenSSL::X509::Certificate.new(File.read(value)) Gem::Security.add_trusted_cert(cert) puts "Added #{cert.subject.to_s}" end - add_option('-l', '--list', 'List trusted certificates.') do |value, options| + add_option('-l', '--list', 'List trusted certificates') do |value, options| glob_str = File::join(Gem::Security::OPT[:trust_dir], '*.pem') Dir::glob(glob_str) do |path| cert = OpenSSL::X509::Certificate.new(File.read(path)) @@ -301,7 +301,7 @@ end end - add_option('-r', '--remove STRING', 'Remove trusted certificates containing STRING.') do |value, options| + add_option('-r', '--remove STRING', 'Remove trusted certificates containing STRING') do |value, options| trust_dir = Gem::Security::OPT[:trust_dir] glob_str = File::join(trust_dir, '*.pem') @@ -314,7 +314,7 @@ end end - add_option('-b', '--build EMAIL_ADDR', 'Build private key and self-signed certificate for EMAIL_ADDR.') do |value, options| + add_option('-b', '--build EMAIL_ADDR', 'Build private key and self-signed certificate for EMAIL_ADDR') do |value, options| vals = Gem::Security::build_self_signed_cert(value) File::chmod(0600, vals[:key_path]) puts "Public Cert: #{vals[:cert_path]}", @@ -322,18 +322,18 @@ "Don't forget to move the key file to somewhere private..." end - add_option('-C', '--certificate CERT', 'Certificate for --sign command.') do |value, options| + add_option('-C', '--certificate CERT', 'Certificate for --sign command') do |value, options| cert = OpenSSL::X509::Certificate.new(File.read(value)) Gem::Security::OPT[:issuer_cert] = cert end - add_option('-K', '--private-key KEY', 'Private key for --sign command.') do |value, options| + add_option('-K', '--private-key KEY', 'Private key for --sign command') do |value, options| key = OpenSSL::PKey::RSA.new(File.read(value)) Gem::Security::OPT[:issuer_key] = key end - add_option('-s', '--sign NEWCERT', 'Sign a certificate with my key and certificate.') do |value, options| + add_option('-s', '--sign NEWCERT', 'Sign a certificate with my key and certificate') do |value, options| cert = OpenSSL::X509::Certificate.new(File.read(value)) my_cert = Gem::Security::OPT[:issuer_cert] my_key = Gem::Security::OPT[:issuer_key] From dougkearns at gmail.com Mon Jul 18 09:32:48 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Mon Jul 18 09:33:45 2005 Subject: [Rubygems-developers] zsh completion function In-Reply-To: <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> References: <20050709144735.GC3976@localhost.localdomain> <177C0626-572A-4B2E-B3F4-CC203F91AF99@chadfowler.com> Message-ID: <20050718133248.GF3554@localhost.localdomain> On Sat, Jul 09, 2005 at 01:55:35PM -0400, Chad Fowler wrote: > > On 09-Jul-05, at 10:47 AM, Doug Kearns wrote: > > >G'day all, > > > >I was just about to write a zsh completion function for gem and was > >wondering if anyone had already saved me the trouble. ;-) > > > > Cool! I don't know of anyone who has already done this. > > I'd like to have one for Bash, too. That might make a nice Saturday > project some time. OK, I'll take a look at knocking one of these together as well; though why anyone would choose to use bash is beyond me. ;-) Regards, Doug From assaph at gmail.com Mon Jul 18 10:13:23 2005 From: assaph at gmail.com (Assaph Mehr) Date: Mon Jul 18 10:07:59 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: <3ff47be9050718071359690c61@mail.gmail.com> Hi, Just wanted to say thank you for your efforts, and donate a couple of cents :-) > > (A) There is a date in the gemspec. Should the algorithm use the > > gemspec date, or the date of the file in the file system? > > I would use the gemspec date. Wouldn't you then be relying on gem authors doing the right thing? Wouldn't it be better to track when the gem file was actually uploaded to the system and you started tracking it? > * All gems uploaded in the last M months are directly available. > * At least min(N,V) versions of a gem are available (where V is total > number of versions uploaded) I'd also suggest keeping the last minor version of each major version series. E.g. RedCloth - keeping 2.0.11 as well as the last 3 versions of the 3.0.x series. Also, should we check dependencies before archiving? You may have a particular version for a gem that you want to keep, but it still depends on another gem with a version you want to archive. Last thing: maybe also check for download statistics before archiving? Maybe we should keep any version that was downloaded in the last X months, and only archive it after it hasn't been used in a while. This will obviously change between gems. Since that's about all I can contribute for now (at least until I get Pimki2 out), so feel free to ignore my jabbering. Cheers, Assaph From assaph at gmail.com Mon Jul 18 10:24:14 2005 From: assaph at gmail.com (Assaph Mehr) Date: Mon Jul 18 10:18:51 2005 Subject: [Rubygems-developers] Minor error in reporting upgrade results Message-ID: <3ff47be9050718072419f1e350@mail.gmail.com> Hi, Title says it all. Given this transcript: c:\>gem up Upgrading installed gems... Attempting remote upgrade of lafcadio Attempting remote installation of 'lafcadio' Install required dependency englishext? [Yn] Install required dependency month? [Yn] Install required dependency queuehash? [Yn] Install required dependency uscommerce? [Yn] Successfully installed lafcadio-0.7.4 Successfully installed englishext-0.1.0 Successfully installed month-0.1.0 Successfully installed queuehash-0.1.0 Successfully installed uscommerce-0.1.0 Attempting remote upgrade of wee Attempting remote installation of 'wee' Successfully installed wee-0.9.1 Gems: [lafcadio, wee] updated I would have expected to see all gems installed/upgraded in the final list. What do you think? Cheers, Assaph From halostatue at gmail.com Mon Jul 18 13:14:30 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Mon Jul 18 13:09:05 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: <9e7db9110507181014bcaa20@mail.gmail.com> On 7/18/05, Jim Weirich wrote: > * topdir > * yaml (uncompressed source index) > * yaml.Z (compressed source index) > * quick > * index > * index.Z > * aaa.gemspec > * aaa.gemspec.Z > * bbb.gemspec > * bbb.gemspec.Z No comment on the rest, at least for now, but if you're not actually using the compress(1) algorithm (IIRC, you're using GZipWriter, which is Deflate), don't use Z as the extension. Use gz as the extension. This may be difficult to change on yaml.Z because of historical issues, but this should not be compounded. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca From hgs at dmu.ac.uk Tue Jul 19 06:24:50 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 06:19:31 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: On Mon, 18 Jul 2005, Jim Weirich wrote: > > * topdir [...] > * quick > * index > * index.Z > * aaa.gemspec > * aaa.gemspec.Z [...] > * gems [...] Agreed. > > The main addition is the "quick" directory. The quick/index file > contains a list of gems and a MD5 hash of the corresponding gemspec. > Something like this: > > builder-0.1.1 68673a832739659790fb02e4227d226f Yes, agree with this, except that I'd go for a stronger hash. MD5 is regarded as pretty feeble now, and Ruby supports SHA-256. Yes it is bulkier, but when gems start to get really popular then we will have some scoundrels trying to abuse the system at some point, so why make it easier than it needs to be? [...] > in the .gem file. In particular, the 'files' field is empty. This > makes the spec *much* smaller. Since this copy of the gemspec is only > used for searches in the cache, omitting this data is not a problem. [...] I remember discussion about this before. Seems a good idea. > > Some open questions: > > (A) I show storing both the index and index.Z, both the gemspec and > gemspec.Z. Is there any reason to store the non-compressed > version? Gem_server can generate that if needed? > > (B) If there are a *lot* of gems that are out of date, there may be a > point were downloading a single, large yaml file may be more > efficient than downloading a bunch of smaller files. At that > point we could switch to the current algorithm. This will only happen when we have mirroring support and people joining the mirror network, I think. So for now I'd tend to advise YAGNI. > > (2) Archiving Old Gems > > Part of the problem is that one a gem is available on RubyForge, it is > always available on RubyForge. The source index keeps expanding and > expanding. "In all of the directions it can whizz" :-) [...] > archive/gem directory. The archive directory will have its own yaml > file and quick index (in the format described in part (1) above). This is a good, pragmatic solution. > This means that gems moved the archive are still available by using > the --source option on the command line. For example, if rails-0.5 is > in the archive, I can still get it with the command: > > gem install --version=0.5 rails --source=http://gems.rubyforge.org/archive If the version is less than that in the current repository, the server should "know" to look in the archive. After all, all version numbers are comparables, aren't they? It is the kind of decision a computer can make easily, I think. People won't want to know this level of detail, IMHO. Will they want to remember if it is ./Archive, ./archive, ./arch or what? And to keep up to date with what has been archived or and what has not? "Press 8 if your gem has not been found in the repository." Please don't inflict that kind of interface on our users. :-) > (A) There is a date in the gemspec. Should the algorithm use the > gemspec date, or the date of the file in the file system? I'd say gemspec date. If it differs from the file date there's probably a reason. > > (3) Unrelated Question: > > I am considering renaming the generate_yaml_index.rb command to > gem_index (or maybe gem_server_index ... suggestions welcome). This gem_index sounds fine. > > > Hugh From hgs at dmu.ac.uk Tue Jul 19 06:36:01 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 06:30:51 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <9e7db9110507181014bcaa20@mail.gmail.com> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> <9e7db9110507181014bcaa20@mail.gmail.com> Message-ID: On Mon, 18 Jul 2005, Austin Ziegler wrote: > No comment on the rest, at least for now, but if you're not actually > using the compress(1) algorithm (IIRC, you're using GZipWriter, which Zlib::Deflate::deflate > is Deflate), don't use Z as the extension. Use gz as the extension. Except that gzip won't unpack these, so that is wrong too. I've tried before. RFC1951 doesn't advise on an extension for Deflate, AFAICS. > This may be difficult to change on yaml.Z because of historical > issues, but this should not be compounded. > > -austin Hugh From hgs at dmu.ac.uk Tue Jul 19 06:47:02 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 06:41:41 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <1121691844.13518.93.camel@hal> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> <1121691844.13518.93.camel@hal> Message-ID: On Mon, 18 Jul 2005, Tom Copeland wrote: > On Mon, 2005-07-18 at 07:46 -0400, Chad Fowler wrote: >> I don't see a reason. The non-compressed yaml index is only still >> there to support old clients. We could probably kill it at this [...] >> >> Tom, are you capturing user agent yet in Apache? We send the >> rubygems version as part of user agent, so we could look at this and >> see what's hitting /yaml directly. > > Hm, I haven't been... but now we are; I just turned "combined" logging > format for that vhost. Here's the first couple dozen requests, mostly > from RubyGems 0.8.11: > > ============================== > 206.228.241.250 - - [18/Jul/2005:08:53:30 -0400] "HEAD /yaml HTTP/1.1" > 200 0 "-" "-" > 218.219.149.62 - - [18/Jul/2005:08:53:36 -0400] > "GET /gems/rails-0.13.1.gem HTTP/1.1" 200 86016 "-" "RubyGems/0.8.11" > 206.228.241.250 - - [18/Jul/2005:08:53:36 -0400] > "GET /gems/sqlite3-ruby-1.1.0.gem HTTP/1.1" 200 39424 "-" > "RubyGems/0.8.11" > 218.219.149.62 - - [18/Jul/2005:08:53:45 -0400] "HEAD /yaml HTTP/1.1" > 200 0 "-" "-" [...] Rubygems doesn't seem to utilize the accept-encoding header -- it doesn't show here and doesn't seem to be in the sources... http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3 which may help, and covers my other point about only keeping one form on the server, and deriving the other forms when needed. Hugh From chad at chadfowler.com Tue Jul 19 07:13:51 2005 From: chad at chadfowler.com (Chad Fowler) Date: Tue Jul 19 07:08:28 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <3ff47be9050718071359690c61@mail.gmail.com> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> <3ff47be9050718071359690c61@mail.gmail.com> Message-ID: <2268CBB5-00CB-447D-BFBC-21394731F9D8@chadfowler.com> On 18-Jul-05, at 10:13 AM, Assaph Mehr wrote: > Hi, > > Just wanted to say thank you for your efforts, and donate a couple > of cents :-) > > >>> (A) There is a date in the gemspec. Should the algorithm use the >>> gemspec date, or the date of the file in the file system? >>> >> >> I would use the gemspec date. >> > > Wouldn't you then be relying on gem authors doing the right thing? > Wouldn't it be better to track when the gem file was actually uploaded > to the system and you started tracking it? > > Perhaps, though there are gems that might sit out on a non-rubyforge location for some time before being added to the central repo. The ramifications of either direction on this aren't too huge, so I guess it's a bit of a nitpicky thing to argue to heavily. :) By that I mean that I wouldn't defend use of the gemspec date too strongly if there was reasonable objection to it. >> * All gems uploaded in the last M months are directly available. >> * At least min(N,V) versions of a gem are available (where V is total >> number of versions uploaded) >> > > I'd also suggest keeping the last minor version of each major version > series. E.g. RedCloth - keeping 2.0.11 as well as the last 3 versions > of the 3.0.x series. > Very good point, given the meaning of the major version numbers. > Also, should we check dependencies before archiving? You may have a > particular version for a gem that you want to keep, but it still > depends on another gem with a version you want to archive. > Another very good point. Absolutely crucial, I'd say. > Last thing: maybe also check for download statistics before archiving? > Maybe we should keep any version that was downloaded in the last X > months, and only archive it after it hasn't been used in a while. This > will obviously change between gems. > I thought about this one too. It might be painful unless we could use, for example, a summary pre-generated by webalizer (I wonder if it leaves this kind of data lying around in non-HTML format after a run?). Thanks! Chad From jim at weirichhouse.org Tue Jul 19 08:07:04 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Tue Jul 19 08:02:12 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: <200507190807.05071.jim@weirichhouse.org> On Tuesday 19 July 2005 06:24 am, Hugh Sasse wrote: > > The main addition is the "quick" directory. The quick/index file > > contains a list of gems and a MD5 hash of the corresponding gemspec. > > Something like this: > > > > builder-0.1.1 68673a832739659790fb02e4227d226f > > Yes, agree with this, except that I'd go for a stronger hash. MD5 is > regarded as pretty feeble now, and Ruby supports SHA-256. Yes it > is bulkier, but when gems start to get really popular then we will > have some scoundrels trying to abuse the system at some point, so > why make it easier than it needs to be? The point of the hash is to detect changes, not protect against malicious users (sign your gem if you need that). How much bigger is SHA-256? > > This means that gems moved the archive are still available by using > > the --source option on the command line. For example, if rails-0.5 is > > in the archive, I can still get it with the command: > > > > gem install --version=0.5 rails > > --source=http://gems.rubyforge.org/archive > > If the version is less than that in the current repository, the > server should "know" to look in the archive. After all, all version > numbers are comparables, aren't they? Sure, but for the client software to know to look in the archive, it must get the archive index. The reason we move stuff to the archive is to avoid the need to get the index for everything that is archived. Automatically falling back to the archive kinda defeats the purpose (although it would only happen when a requested version is not found). Hmmm ... worth thinking about. Thanks for the feedback. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From hgs at dmu.ac.uk Tue Jul 19 08:38:00 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 08:33:07 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <200507190807.05071.jim@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> <200507190807.05071.jim@weirichhouse.org> Message-ID: On Tue, 19 Jul 2005, Jim Weirich wrote: >> Yes, agree with this, except that I'd go for a stronger hash. MD5 is > > The point of the hash is to detect changes, not protect against malicious Which is why it needs to be stronger, strength here being the difficulty of creating a file with the same hash but different content. > users (sign your gem if you need that). I don't want to open the cryptography worm can here.... I'm not after Military level security, I'm after making abuse sufficiently diffult. > > How much bigger is SHA-256? It's 256 bits == 32 bytes -- 64 hex digits. > >>> This means that gems moved the archive are still available by using >>> the --source option on the command line. For example, if rails-0.5 is >>> in the archive, I can still get it with the command: >>> >>> gem install --version=0.5 rails >>> --source=http://gems.rubyforge.org/archive >> >> If the version is less than that in the current repository, the >> server should "know" to look in the archive. After all, all version >> numbers are comparables, aren't they? > > Sure, but for the client software to know to look in the archive, it must get > the archive index. The reason we move stuff to the archive is to avoid the Normally it will get the main index, and versions in the archive won't show up in that. Any gems in the archive will have their latest versions in the main index, because we preserve the most recent. Anything being got from the archive will thus not be a check for changes, so why bother to transmit the archive index at all? > need to get the index for everything that is archived. Automatically falling > back to the archive kinda defeats the purpose (although it would only happen No, I'm talking about gem install --version=0.5 rails --source=http://gems.rubyforge.org/archive which is a request for installation of a specific old version, which must therefore be in the archive, and for which we don't need the archive index. And I'm saying it need only be: gem install --version=0.5 rails because the SERVER knows it is held in the archive, as soon as it sees the version number is less than the smallest version in the main index file. > when a requested version is not found). Hmmm ... worth thinking about. > > Thanks for the feedback. > > -- Thank you, Hugh From assaph at gmail.com Tue Jul 19 08:46:51 2005 From: assaph at gmail.com (Assaph Mehr) Date: Tue Jul 19 08:41:26 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <200507190807.05071.jim@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> <200507190807.05071.jim@weirichhouse.org> Message-ID: <3ff47be905071905467220d5ac@mail.gmail.com> Hi, > gem install --version=0.5 rails > --source=http://gems.rubyforge.org/archive Not related directly but a new feature request: Would it be possible to have a "beta" section of the repository? For example, I may want to release a preview of the next version of my library but not cause everyone to automatically update and break existing programs. Second request: we want to have the archive/beta directory on the same server, right? So why not abbreviate the above option to --archive / --beta? It should append the relevant directory to the source url. It is a matter of convenience, so I prefer the shortest readable option. Thanks for listening, Assaph From hgs at dmu.ac.uk Tue Jul 19 12:10:36 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 12:07:06 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org> Message-ID: On Mon, 18 Jul 2005, Jim Weirich wrote: > Gems that are archived will be moved from the gem directory to an > archive/gem directory. The archive directory will have its own yaml > file and quick index (in the format described in part (1) above). Suppose the server can do the version checking I mentioned before (older than known then look in the archive). Then the only use I see for the indices is `gem list -r` when pointing at the archive[1]. That may be a sufficient condition for having indices in the archive. But I think most of the time there's no need to consult indices held there. Hugh [1] Though I agree the command should probably take the form 'gem list -r --archive', and probably --archive should simply imply -r. When would it make sense for people to have local archives of gems? Or is assuming they won't, needlessly restricting people's choices? Gem commands default to looking locally in most cases so that would break the pattern. From jim at weirichhouse.org Tue Jul 19 12:26:31 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Tue Jul 19 12:21:06 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <3ff47be905071905467220d5ac@mail.gmail.com> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org><200507190807.05071.jim@weirichhouse.org> <3ff47be905071905467220d5ac@mail.gmail.com> Message-ID: <29873.192.223.163.6.1121790391.squirrel@weirichhouse.org> Assaph Mehr said: > Hi, > >> gem install --version=0.5 rails >> --source=http://gems.rubyforge.org/archive > > Not related directly but a new feature request: Would it be possible > to have a "beta" section of the repository? For example, I may want to > release a preview of the next version of my library but not cause > everyone to automatically update and break existing programs. Good point. We can certainly support a beta subdirectory just like the archive subdirectory. In fact, it may be worth supporting arbitrary partitions or subdirectories (e.g. --partition=beta). The larger problem is how to populate these partitions under RubyForge. The user does not control where the RubyForge gem is located. The original proposal was to automate the archiving using the same script that RubyForge uses to generate its indicies. I don't want to start dictating RubyForge policy however. Creating a beta directory would require that RubyForge allow the user to somehow direct where the gem should go. Actually, this wouldn't be a bad thing. Let the user specify when versions should be rolled into the archive. That takes all the hassle away from automating it. Hmmm ... just some more thoughts on the --beta idea. One other problem that just occurred to me is that --beta flag is disconnected from the source. Since the gem command supports multiple sources (at least it will in the 0.9.xxx series ... we're not quite there yet), just saying --beta doesn't tell you which source should be used for --beta. Perhaps what we need is a source management piece. E.g. This source is beta, that one is alpha, this one is an archive. Then we can say update from my beta sources, and the gem command will switch in multiple betas as configured. I think for 0.8.12 I'm going with the explicit source for archive (i.e. no need for any work on the client side to support it), but the --beta suggestion and friends will certainly be worth thinking about in the future. -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From jim at weirichhouse.org Tue Jul 19 12:39:36 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Tue Jul 19 12:34:10 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org><200507190807.05071.jim@weirichhouse.org> Message-ID: <35860.192.223.163.6.1121791176.squirrel@weirichhouse.org> Hugh Sasse said: > Normally it will get the main index, and versions in the archive won't > show up in that. Any gems in the archive will have their latest > versions in the main index, because we preserve the most recent. > Anything being got from the archive will thus not be a check for > changes, so why bother to transmit the archive index at all? Two reasons: (1) Just because the latest version is in the main directory, that doesn't mean that the particular version requested is in the archive. I need to check the index of the archive to know for sure. (2) As proposed, the archive directory is a separate, independent source of gems. I don't want to develope special case behavior for the archive. Keep in mind that not only do I have to grab the index (which doesn't exist today), but I also have to grab the individual gemspecs for the gems in the archive. Otherwise I can't do dependency analysis. (Although grabbing the gemspecs on demand might be another interesting enhancement ... no, keep is simple for the first revision. We can enhance it as needed later) -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From hgs at dmu.ac.uk Tue Jul 19 13:06:31 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jul 19 13:01:15 2005 Subject: [Rubygems-developers] Roadmap for version 0.8.12 In-Reply-To: <35860.192.223.163.6.1121791176.squirrel@weirichhouse.org> References: <34076.216.23.21.112.1121664028.squirrel@weirichhouse.org><200507190807.05071.jim@weirichhouse.org> <35860.192.223.163.6.1121791176.squirrel@weirichhouse.org> Message-ID: On Tue, 19 Jul 2005, Jim Weirich wrote: > > Hugh Sasse said: > >> Normally it will get the main index, and versions in the archive won't >> show up in that. Any gems in the archive will have their latest >> versions in the main index, because we preserve the most recent. >> Anything being got from the archive will thus not be a check for >> changes, so why bother to transmit the archive index at all? > > Two reasons: (1) Just because the latest version is in the main directory, > that doesn't mean that the particular version requested is in the archive. True, it may not exist at all. > I need to check the index of the archive to know for sure. (2) As > proposed, the archive directory is a separate, independent source of gems. > I don't want to develope special case behavior for the archive. Agreed, except that it *is* a special case for old gems, to stop the main one filling up. One of the good things about gems is the usability. I don't think users should have to tell the server to dig gems out of the archive when the server can figure out that they are in there. It's too much like having to micromanage the server. For the person looking for a given gem, the goal is to get the gem, not to be presenting with information about where it might be hidden :-) See Donald Norman's stuff about Gulf of Execution. The main reason for rubygems is to make this kind of thing EASY for the user, isn't it? Maybe an option to alter this behaviour is sensible. I have the feeling I'd want it on by default, and you'd want it off by default. :-) [Damn! Now I'll never be allowed CVS write access :-)!] > > Keep in mind that not only do I have to grab the index (which doesn't > exist today), but I also have to grab the individual gemspecs for the gems > in the archive. Otherwise I can't do dependency analysis. I concede that :-) > > (Although grabbing the gemspecs on demand might be another interesting > enhancement ... no, keep is simple for the first revision. We can enhance > it as needed later) > Thanks, Hugh From dougkearns at gmail.com Wed Jul 20 08:02:14 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Wed Jul 20 08:03:16 2005 Subject: [Rubygems-developers] --version failing Message-ID: <20050720120214.GI3593@localhost.localdomain> G'day all, I'm a bit short on time tonight so I haven't investigated properly but could someone confirm this for me? (21:55)-(doug@hairbear)-(pts/17)-(10010)-(~) (0)% gem --version 0.8.11 (21:55)-(doug@hairbear)-(pts/17)-(10011)-(~) (0)% gem check rails --test There are no unit tests to run for rails-0.13.1 (21:56)-(doug@hairbear)-(pts/17)-(10012)-(~) (0)% gem check rails --test --version '> 0' ERROR: While executing gem ... (Gem::CommandLineError) Too many gem names (rails, > 0); please specify only one It looks like the same occurs for the use of --version with the 'dependency' and 'contents' commands as well. I also noticed when upgrading that the shebang line was changed from "#!/usr/bin/env ruby" to "#!/specific/path/to/ruby" for gem_mirror only? Thanks, Doug From dougkearns at gmail.com Wed Jul 20 11:02:05 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Wed Jul 20 11:04:15 2005 Subject: [Rubygems-developers] --version failing In-Reply-To: <20050720120214.GI3593@localhost.localdomain> References: <20050720120214.GI3593@localhost.localdomain> Message-ID: <20050720150205.GK3593@localhost.localdomain> On Wed, Jul 20, 2005 at 10:02:14PM +1000, Doug Kearns wrote: > G'day all, > > I'm a bit short on time tonight so I haven't investigated properly but > could someone confirm this for me? Not having used optparse I'll take a punt... ;-) Regards, Doug Index: gem_commands.rb =================================================================== RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/gem_commands.rb,v retrieving revision 1.65 diff -u -r1.65 gem_commands.rb --- gem_commands.rb 18 Jul 2005 10:44:15 -0000 1.65 +++ gem_commands.rb 20 Jul 2005 15:01:03 -0000 @@ -460,7 +460,7 @@ add_option('-t', '--test', "Run unit tests for gem") do |value, options| options[:test] = true end - add_option('-V', '--version', "Specify version for which to run unit tests") do |value, options| + add_option('-V', '--version VERSION', "Specify version for which to run unit tests") do |value, options| options[:version] = value end end @@ -1184,7 +1184,7 @@ o[:list] = true end - add_option("-V","--version","Specify version for gem to view") do |v,o| + add_option("-V","--version VERSION","Specify version for gem to view") do |v,o| o[:version] = v end From nseckar at gmail.com Wed Jul 20 16:18:27 2005 From: nseckar at gmail.com (Nicholas Seckar) Date: Wed Jul 20 16:13:33 2005 Subject: [Rubygems-developers] Load errors squashed Message-ID: <42DEB193.7090203@gmail.com> Hello guys, I've run into an issue in RubyGems where load errors are swallowed by require. Allow me to describe the situation as I have come to understand it: Assume RubyGems is loaded. Say that we perform require 'fcgi_handler'. Rubygems' implementation of require sets up an exception handler for LoadError and calls require__ (the built-in require). Assuming fcgi_handler.rb is present, it is read and evaluated. Suppose that fcgi_handler.rb calls require 'fcgi' Rubygems' again wraps require__. Suppose fcgi isn't present? require catches' require__'s exception and looks for a gem containing fcgi.rb. Suppose the fcgi gem isn't installed? RubyGems' require re-raises the exception. The exception is raised past require__('fcgi_handler') and into require('fcgi_handler'), where it is caught. RubyGems *wrongfully* assumes that the load error is related to missing fcgi_handler.rb, and looks for a gem with fcgi_handler.rb. It finds rails, and require's it, and continues on merrily. http://www.utsc.utoronto.ca/~02seckar/rubygems-custom-require-assumes-too-much.patch The above URL leads to a patch which corrects this behavior. It inspects the call stack and re-raises the exception if the load error did not occur while loading the current file. It does so by checking the exceptions's stack trace and ensuring that all the methods contain the word require. This is done to play fair with other require hooks, but you may choose to simplify this. If you prefer, raise if load_error.backtrace.length > caller.length + 2 will raise the error unless the require__ method was the source of the error. You will also notice the lact of unit-tests. I'm quite unfamiliar with RubyGems' test setup, and I don't have the time to absorb it. Hopefully another soul can provide this... Regards, Nicholas Seckar -------------- next part -------------- Index: actionpack/lib/action_controller/request.rb =================================================================== --- actionpack/lib/action_controller/request.rb (revision 1854) +++ actionpack/lib/action_controller/request.rb (working copy) @@ -153,12 +153,9 @@ path = (uri = request_uri) ? uri.split('?').first : '' # Cut off the path to the installation directory if given - if root = relative_url_root - path[root.length..-1] - else - path - end - end + path[0, root.length] = '' if root = relative_url_root + path || '' + end # Returns the path minus the web server relative installation directory. # This method returns nil unless the web server is apache. From hgs at dmu.ac.uk Thu Jul 21 11:25:27 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu Jul 21 11:20:05 2005 Subject: [Rubygems-developers] wrt future: accessing changelogs or similar? Message-ID: I've been trying to get my head sufficiently around rails that I can use it confidently. I read this http://www.slash7.com/articles/2005/06/01/fastcgi-berzerking which suggests I should not use the 0.8.5 gem or the 0.8.6 gem of fcgi. But I see there's a 0.8.6.1 gem. So I do gem query and get the same info as gem list, and then neelix hgs 16 %> gem spec -r fcgi (Remote 'info' operation is not yet implemented.) neelix hgs 17 %> Well, even if I got the spec I probably couldn't see the changes from it, though I'd probably get the URL to look at. So, how much of a priority is implementation of the remote info facility (by those who are familiar with the design of the local info implementation, which I'm not yet), and how bonkers is the idea of a command to access the changelog directly? If I get chance, (and the way this week has been going, I won't), I'll look into implementing this myself, but in the meantime... Thank you, Hugh From hgs at dmu.ac.uk Wed Jul 27 07:25:51 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed Jul 27 08:03:54 2005 Subject: [Rubygems-developers] Handling of tar files.... Message-ID: AFAICS rubygems assumes that tar is gnu tar. [ [need_tar, tgz_file, "z"], [need_tar_gz, tar_gz_file, "z"], [need_tar_bz2, tar_bz2_file, "j"] ].each do |(need, file, flag)| if need task :package => ["#{package_dir}/#{file}"] file "#{package_dir}/#{file}" => [package_dir_path] + package_files do chdir(package_dir) do sh %{tar #{flag}cvf #{file} #{package_name}} end end end end from ./lib/rake/packagetask.rb in 0.5.4 We have Suns here, and I'm not really in a position to know if Sun does anything unusual with their tar when they distribute things. Therefore I tend to keep the sun binaries in place and first on the path and have GNU tar as /usr/local/bin/tar symlinked to /usr/local/bin/gtar. I'm wondering what the correct fix for this is. I could try to remember to fix this everytime I update the gem, but it would be nice if it worked for other people in my position out of the box. I've seen GNU configure check tar to see if it is gnuish, but I've not looked at the details to see how this is done. I do know that the j flag is only supported by recent versions of GNU tar though, versions that I can't build on a Solaris 2.5.1 system. Hugh From halostatue at gmail.com Wed Jul 27 08:30:18 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Wed Jul 27 08:24:41 2005 Subject: [Rubygems-developers] Handling of tar files.... In-Reply-To: References: Message-ID: <9e7db91105072705301bc4edf6@mail.gmail.com> On 7/27/05, Hugh Sasse wrote: > AFAICS rubygems assumes that tar is gnu tar. > [ > [need_tar, tgz_file, "z"], > [need_tar_gz, tar_gz_file, "z"], > [need_tar_bz2, tar_bz2_file, "j"] > ].each do |(need, file, flag)| > if need > task :package => ["#{package_dir}/#{file}"] > file "#{package_dir}/#{file}" => [package_dir_path] + package_files do > chdir(package_dir) do > sh %{tar #{flag}cvf #{file} #{package_name}} > end > end > end > end > > from ./lib/rake/packagetask.rb in 0.5.4 This should be using Archive::Tar::Minitar or something similar in any case. -austin -- Austin Ziegler * halostatue@gmail.com * Alternate: austin@halostatue.ca From hgs at dmu.ac.uk Wed Jul 27 08:42:39 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed Jul 27 08:40:33 2005 Subject: [Rubygems-developers] Handling of tar files.... In-Reply-To: <9e7db91105072705301bc4edf6@mail.gmail.com> References: <9e7db91105072705301bc4edf6@mail.gmail.com> Message-ID: On Wed, 27 Jul 2005, Austin Ziegler wrote: > On 7/27/05, Hugh Sasse wrote: >> AFAICS rubygems assumes that tar is gnu tar. >> file "#{package_dir}/#{file}" => [package_dir_path] + package_files do >> chdir(package_dir) do >> sh %{tar #{flag}cvf #{file} #{package_name}} >> end >> end >> from ./lib/rake/packagetask.rb in 0.5.4 > > This should be using Archive::Tar::Minitar or something similar in any case. Where's that? I can't see it in the Standard Library online... > > -austin Thanks, Hugh From jim at weirichhouse.org Wed Jul 27 13:07:26 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Wed Jul 27 13:01:48 2005 Subject: [Rubygems-developers] Handling of tar files.... In-Reply-To: References: Message-ID: <6590.192.223.163.6.1122484046.squirrel@weirichhouse.org> Hugh Sasse said: > AFAICS rubygems assumes that tar is gnu tar. Actually, it is rake that assumes this, and only the package task at that. I'm willing to accept patches to Rake's package task to support (i) tar commands called something other than "tar" or located elsewhere in the path, or (2) option to user Tar::Minitar (or whatever it is called). -- -- Jim Weirich jim@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From hgs at dmu.ac.uk Wed Jul 27 13:34:07 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed Jul 27 13:28:41 2005 Subject: [Rubygems-developers] Handling of tar files.... In-Reply-To: <6590.192.223.163.6.1122484046.squirrel@weirichhouse.org> References: <6590.192.223.163.6.1122484046.squirrel@weirichhouse.org> Message-ID: On Wed, 27 Jul 2005, Jim Weirich wrote: > > Hugh Sasse said: >> AFAICS rubygems assumes that tar is gnu tar. > > Actually, it is rake that assumes this, and only the package task at that. > > I'm willing to accept patches to Rake's package task to support (i) tar > commands called something other than "tar" or located elsewhere in the > path, or (2) option to user Tar::Minitar (or whatever it is called). > I'm willing to write something that will detect gtar, but what do you do for things like this at the moment: check at runtime; check environment variables; check at build time, or something else? Whatever's written should fit current conventions. GNU stuff does this at configure time usually, so that model isn't applicable here. Thank you, Hugh