From gsinclair at soyabean.com.au Fri Apr 1 03:58:05 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Fri Apr 1 03:54:11 2005 Subject: [Rubygems-developers] Issue: listing from a specified source Message-ID: <147207063291.20050401185805@soyabean.com.au> When I run gem list -s http://gems.rubyonrails.org I get a list of my local gems and no remote ones at all. Then I notices that -s is not actually a shortcut for --source, which surprised me. Anyway gem list --source http://gems.rubyonrails.org gave the same result: only my local gems. It seems to me that the result _should_ be NO local gems, and the gems from the specified source ONLY. gem list --source http://gems.rubyonrails.org -r gave the result I was after. I think that result should be available via the first command I tried: gem list -s http://gems.rubyonrails.org Thoughts? Gavin From chad at chadfowler.com Fri Apr 1 11:15:35 2005 From: chad at chadfowler.com (chad@chadfowler.com) Date: Fri Apr 1 10:03:54 2005 Subject: [Rubygems-developers] Issue: listing from a specified source In-Reply-To: <147207063291.20050401185805@soyabean.com.au> References: <147207063291.20050401185805@soyabean.com.au> Message-ID: <59089.66.80.154.3.1112372135.squirrel@66.80.154.3> Good catch. We could either fix it right quick or give it to Ryan Davis, Eric Hodel and crew for their code fest. Ryan, are you listening? > When I run > > gem list -s http://gems.rubyonrails.org > > I get a list of my local gems and no remote ones at all. Then I > notices that -s is not actually a shortcut for --source, which > surprised me. Anyway > > gem list --source http://gems.rubyonrails.org > > gave the same result: only my local gems. It seems to me that the > result _should_ be NO local gems, and the gems from the specified > source ONLY. > > gem list --source http://gems.rubyonrails.org -r > > gave the result I was after. I think that result should be available > via the first command I tried: > > gem list -s http://gems.rubyonrails.org > > Thoughts? > > Gavin > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From gsinclair at soyabean.com.au Fri Apr 1 11:41:35 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Fri Apr 1 11:37:46 2005 Subject: [Rubygems-developers] Issue: listing from a specified source In-Reply-To: <59089.66.80.154.3.1112372135.squirrel@66.80.154.3> References: <147207063291.20050401185805@soyabean.com.au> <59089.66.80.154.3.1112372135.squirrel@66.80.154.3> Message-ID: <41234873199.20050402024135@soyabean.com.au> Give it to Ryan and his mates. A nice easy problem to get the weekend started, and perhaps introduce someone to the source code. On Saturday, April 2, 2005, 2:15:35 AM, chad wrote: > Good catch. We could either fix it right quick or give it to Ryan Davis, > Eric Hodel and crew for their code fest. Ryan, are you listening? >> When I run >> >> gem list -s http://gems.rubyonrails.org >> >> I get a list of my local gems and no remote ones at all. Then I >> notices that -s is not actually a shortcut for --source, which >> surprised me. Anyway >> >> gem list --source http://gems.rubyonrails.org >> >> gave the same result: only my local gems. It seems to me that the >> result _should_ be NO local gems, and the gems from the specified >> source ONLY. >> >> gem list --source http://gems.rubyonrails.org -r >> >> gave the result I was after. I think that result should be available >> via the first command I tried: >> >> gem list -s http://gems.rubyonrails.org >> >> Thoughts? >> >> Gavin From drbrain at segment7.net Fri Apr 1 14:05:11 2005 From: drbrain at segment7.net (Eric Hodel) Date: Fri Apr 1 14:00:06 2005 Subject: [Rubygems-developers] Issue: listing from a specified source In-Reply-To: <59089.66.80.154.3.1112372135.squirrel@66.80.154.3> References: <147207063291.20050401185805@soyabean.com.au> <59089.66.80.154.3.1112372135.squirrel@66.80.154.3> Message-ID: On 01 Apr 2005, at 08:15, chad@chadfowler.com wrote: > Good catch. We could either fix it right quick or give it to Ryan > Davis, > Eric Hodel and crew for their code fest. Ryan, are you listening? > >> When I run >> >> gem list -s http://gems.rubyonrails.org >> >> I get a list of my local gems and no remote ones at all. Then I >> notices that -s is not actually a shortcut for --source, which >> surprised me. Anyway So that's what's broken with the script/generate documentation! -- Eric Hodel - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050401/a768c313/PGP.bin From curt at hibbs.com Thu Apr 7 07:00:05 2005 From: curt at hibbs.com (Curt Hibbs) Date: Thu Apr 7 06:54:46 2005 Subject: [Rubygems-developers] Re: 'gem install instiki-0.10.0' does not pull in dependencies - why? In-Reply-To: References: Message-ID: <425512B5.2040808@hibbs.com> I'll cross post this (and your 2nd email) to the RubyGems ML where it should get faster attention. Curt Alexey Verkhovsky wrote: > I have a problem with this gem (about to be released Instiki 0.10): > http://alexeyv.textdriven.com/instiki-0.10.0.gem > It has external dependencies: > > QTE instiki.gemspec > s.add_dependency('madeleine', '= 0.7.1') > s.add_dependency('RedCloth', '= 3.0.3') > s.add_dependency('rubyzip', '= 0.5.5') > s.add_dependency('rails', '= 0.11.1') > UNQTE > > and yet, when I try to install it, it gets installed without them. I > wonder what is it that I'm doing wrong here. What follows is an excerpt > from command-line session. > Re my shell prompt: I swear, this is only for the kids and their games - > the next thing I'm buying after a car, a house and a boat will be a Mac :) > > E:\>gem install --both --include-dependencies instiki-0.10.0.gem > Attempting local installation of 'instiki-0.10.0.gem' > Successfully installed instiki, version 0.10.0 > > E:\>gem list > > *** LOCAL GEMS *** > > instiki (0.10.0) > Easy to install WikiClone running on WEBrick and Madeleine > > postgres-pr (0.3.6) > A pure Ruby interface to the PostgreSQL (>= 7.4) database > > rake (0.5.0.2, 0.5.0, 0.4.15) > Ruby based make-like utility. > > rubygems-update (0.8.10) > RubyGems Update GEM > > sources (0.0.1) > This package provides download sources for remote gem installation > > // NOTE: no Rails, no Madeleine, etc > > E:\>gem specification instiki > --- !ruby/object:Gem::Specification > rubygems_version: 0.8.10 > specification_version: 1 > name: instiki > version: !ruby/object:Gem::Version > version: 0.10.0 > date: 2005-04-07 > summary: Easy to install WikiClone running on WEBrick and Madeleine > require_paths: > - lib > email: david@loudthinking.com > homepage: http://www.instiki.org > rubyforge_project: instiki > description: Instiki is a Wiki Clone written in Ruby that ships with an > embedded > webserver. You can setup up an Instiki in just a few steps. Possibly > the simp > lest wiki setup ever. > autorequire: > default_executable: instiki > bindir: "." > has_rdoc: false > required_ruby_version: !ruby/object:Gem::Version::Requirement > requirements: > - > - ">" > - !ruby/object:Gem::Version > version: 0.0.0 > version: > platform: ruby > authors: > - David Heinemeier Hansson > files: > - CHANGELOG > - README > - instiki > - instiki.rb > - app/controllers/admin_controller.rb > - app/controllers/application.rb > - app/controllers/file_controller.rb > - app/controllers/wiki_controller.rb > - app/helpers/application_helper.rb > - app/models/author.rb > - app/models/file_yard.rb > - app/models/page.rb > - app/models/page_lock.rb > - app/models/page_set.rb > - app/models/revision.rb > - app/models/web.rb > - app/models/wiki_content.rb > - app/models/wiki_service.rb > - app/models/wiki_words.rb > - app/models/chunks/category.rb > - app/models/chunks/chunk.rb > - app/models/chunks/engines.rb > - app/models/chunks/include.rb > - app/models/chunks/literal.rb > - app/models/chunks/nowiki.rb > - app/models/chunks/test.rb > - app/models/chunks/uri.rb > - app/models/chunks/wiki.rb > - app/views/markdown_help.rhtml > - app/views/navigation.rhtml > - app/views/rdoc_help.rhtml > - app/views/textile_help.rhtml > - app/views/wiki_words_help.rhtml > - app/views/admin/create_system.rhtml > - app/views/admin/create_web.rhtml > - app/views/admin/edit_web.rhtml > - app/views/file/file.rhtml > - app/views/file/import.rhtml > - app/views/layouts/default.rhtml > - app/views/wiki/authors.rhtml > - app/views/wiki/edit.rhtml > - app/views/wiki/export.rhtml > - app/views/wiki/feeds.rhtml > - app/views/wiki/list.rhtml > - app/views/wiki/locked.rhtml > - app/views/wiki/login.rhtml > - app/views/wiki/new.rhtml > - app/views/wiki/page.rhtml > - app/views/wiki/print.rhtml > - app/views/wiki/published.rhtml > - app/views/wiki/recently_revised.rhtml > - app/views/wiki/revision.rhtml > - app/views/wiki/rollback.rhtml > - app/views/wiki/rss_feed.rhtml > - app/views/wiki/search.rhtml > - app/views/wiki/tex.rhtml > - app/views/wiki/tex_web.rhtml > - app/views/wiki/web_list.rhtml > - lib/active_record_stub.rb > - lib/diff.rb > - lib/instiki_errors.rb > - lib/rdocsupport.rb > - lib/redcloth_for_tex.rb > - public/404.html > - public/500.html > - public/dispatch.rb > - public/favicon.ico > - public/javascripts/edit_web.js > - public/javascripts/prototype.js > - public/stylesheets/instiki.css > - natives/osx/desktop_launcher/AppDelegate.h > - natives/osx/desktop_launcher/AppDelegate.mm > - natives/osx/desktop_launcher/Credits.html > - natives/osx/desktop_launcher/Info.plist > - natives/osx/desktop_launcher/Instiki_Prefix.pch > - natives/osx/desktop_launcher/main.mm > - natives/osx/desktop_launcher/MakeDMG.sh > - natives/osx/desktop_launcher/version.plist > - natives/osx/desktop_launcher/English.lproj/InfoPlist.strings > - natives/osx/desktop_launcher/English.lproj/MainMenu.nib/classes.nib > - natives/osx/desktop_launcher/English.lproj/MainMenu.nib/info.nib > - natives/osx/desktop_launcher/English.lproj/MainMenu.nib/objects.nib > - natives/osx/desktop_launcher/Instiki.xcode/project.pbxproj > - config/environment.rb > - config/routes.rb > - config/environments/development.rb > - config/environments/production.rb > - config/environments/test.rb > - script/breakpointer > - script/server > - "./instiki" > test_files: [] > rdoc_options: [] > extra_rdoc_files: [] > executables: > - instiki > extensions: [] > requirements: > - none > dependencies: > - !ruby/object:Gem::Dependency > name: madeleine > version_requirement: > version_requirements: !ruby/object:Gem::Version::Requirement > requirements: > - > - "=" > - !ruby/object:Gem::Version > version: 0.7.1 > version: > - !ruby/object:Gem::Dependency > name: RedCloth > version_requirement: > version_requirements: !ruby/object:Gem::Version::Requirement > requirements: > - > - "=" > - !ruby/object:Gem::Version > version: 3.0.3 > version: > - !ruby/object:Gem::Dependency > name: rubyzip > version_requirement: > version_requirements: !ruby/object:Gem::Version::Requirement > requirements: > - > - "=" > - !ruby/object:Gem::Version > version: 0.5.5 > version: > - !ruby/object:Gem::Dependency > name: rails > version_requirement: > version_requirements: !ruby/object:Gem::Version::Requirement > requirements: > - > - "=" > - !ruby/object:Gem::Version > version: 0.11.1 > version: > > E:\>instiki > e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:194:in > `report_activate_error': Could > not find RubyGem madeleine (= 0.7.1) (Gem::LoadError) > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:136:in `activate' > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:162:in `activate' > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:161:in `each' > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:161:in `activate' > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:37:in > `require_gem_with_ > options' > from e:/ruby/lib/ruby/site_ruby/1.8/rubygems.rb:31:in `require_gem' > from e:/ruby/bin/instiki:17 > Alexey Verkhovsky wrote: > Alexey Verkhovsky wrote: > >> I have a problem with this gem (about to be released Instiki 0.10): >> http://alexeyv.textdriven.com/instiki-0.10.0.gem > > > Oh, just in case - to get the sources and build the gem yourself: > > svn co http://svn.instiki.org/instiki/trunk instiki > cd instiki > rake clean package > ls pkg > From hgs at dmu.ac.uk Thu Apr 14 07:12:11 2005 From: hgs at dmu.ac.uk (Hugh Sasse Staff Elec Eng) Date: Thu Apr 14 07:06:47 2005 Subject: [Rubygems-developers] 0.8.10, various matters. Message-ID: I have just tried to install Rubygems on a Windows98 box. Because I wasn't using gem update I looked for an INSTALL file in the tarball. There isn't one. README doesn't contain installation instructions. May I suggest we add something like this for now? A proposed INSTALL file: ---------8<------------------- To install rubygems: % ruby install.rb config % ruby install.rb setup % ruby install.rb install You may need to be root or Administrator to install for the whole system. If you want to install within your home directory or somewhere other than where the system ruby files are installed: % ruby install.rb config --prefix=/home/mystuff % ruby install.rb setup % ruby install.rb install Rubygems may simply be updated with the other gems % gem update ---------8<------------------- Obviously we can expand on this. When setup was done I could find no files in the Ruby distribution. I'd done the install from a DOS prompt. So I looked at recent files, and found it had put the program under the Cygwin structure, which was somewhat unexpected. OK, so the docs should be there then.... No, they don't seem to be. Normally gems install the docs as well. I'm not sure what is happening here.... Hugh From gsinclair at soyabean.com.au Thu Apr 14 08:40:20 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Thu Apr 14 08:35:08 2005 Subject: [Rubygems-developers] 0.8.10, various matters. In-Reply-To: References: Message-ID: <1911343335003.20050414224020@soyabean.com.au> On Thursday, April 14, 2005, 9:12:11 PM, Hugh wrote, in part: > When setup was done I could find no files in the > Ruby distribution. I'd done the install from a DOS prompt. So I > looked at recent files, and found it had put the program under the > Cygwin structure, which was somewhat unexpected. Try "ruby -v". If you're running a Cygwin version of Ruby, it will naturally install things in the Cygwin structure. You've probably got your path set up to favour Cygwin's /usr/bin etc. Gavin From hgs at dmu.ac.uk Thu Apr 14 09:04:10 2005 From: hgs at dmu.ac.uk (Hugh Sasse Staff Elec Eng) Date: Thu Apr 14 08:58:42 2005 Subject: [Rubygems-developers] 0.8.10, various matters. In-Reply-To: <1911343335003.20050414224020@soyabean.com.au> References: <1911343335003.20050414224020@soyabean.com.au> Message-ID: On Thu, 14 Apr 2005, Gavin Sinclair wrote: > Try "ruby -v". If you're running a Cygwin version of Ruby, it will > naturally install things in the Cygwin structure. You've probably got > your path set up to favour Cygwin's /usr/bin etc. Excuse me while I go and LART myself! Thank you, it was the path, and I wondered why ruby -v was banging on about i386-cygwin. > > Gavin Hugh, off to get some caffeine. From jim at weirichhouse.org Sat Apr 16 09:36:08 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Apr 16 09:31:13 2005 Subject: [Rubygems-developers] 0.8.10, various matters. In-Reply-To: References: Message-ID: <200504160936.08390.jim@weirichhouse.org> On Thursday 14 April 2005 07:12 am, Hugh Sasse Staff Elec Eng wrote: > I have just tried to install Rubygems on a Windows98 box. > > Because I wasn't using gem update I looked for an INSTALL file in > the tarball. There isn't one. README doesn't contain installation > instructions. May I suggest we add something like this for now? > A proposed INSTALL file: I just added the following to the README file: --CUT------------------------------------------------------------ == Installation Get it from RubyForge (http://rubygems.rubyforge.org) and run (as root, if appropriate and necessary) ruby setup.rb For more details and other options, see: * {User Guide/Installation}[http://docs.rubygems.org/read/chapter/3] --CUT------------------------------------------------------------ I also updated the installation chapter in the RubyGems document to reflect the extended directions for installing in an alternate location. -- -- 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 gsinclair at soyabean.com.au Sat Apr 16 21:33:48 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Sat Apr 16 21:28:21 2005 Subject: [Rubygems-developers] Deprecating gems Message-ID: <17360926788.20050417113348@soyabean.com.au> On the rails list, some confusion has permeated surrounding the wad of gems surrounding sqlite. The main problem is that one of them is deprecated. I suggested to Jamis that he update the description of the deprecated one ("sqlite") which informs the user that it's deprecated and they should use sqlite-ruby or sqlite3-ruby instead. As far as I'm concerned, that's a sufficient solution. Just thought I'd mention the issue here, though, in case someone thinks an explicit way of deprecating gems is a useful idea. Cheers, Gavin From jim at weirichhouse.org Sat Apr 16 23:08:44 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sat Apr 16 23:03:40 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: <17360926788.20050417113348@soyabean.com.au> References: <17360926788.20050417113348@soyabean.com.au> Message-ID: <200504162308.44350.jim@weirichhouse.org> On Saturday 16 April 2005 09:33 pm, Gavin Sinclair wrote: > On the rails list, some confusion has permeated surrounding the wad of > gems surrounding sqlite. The main problem is that one of them is > deprecated. > > I suggested to Jamis that he update the description of the deprecated > one ("sqlite") which informs the user that it's deprecated and they > should use sqlite-ruby or sqlite3-ruby instead. > > As far as I'm concerned, that's a sufficient solution. Just thought > I'd mention the issue here, though, in case someone thinks an explicit > way of deprecating gems is a useful idea. I was actually thinking about such things recently. Although its cool that rubyforge lists all gems that were /ever/ uploaded (minus the handfull that have been explicitly withdrawn), I'm wondering if that is a sustainable model. The yaml.Z file is enormous and most of those older gems that have been replaced by newer versions are of little use to most people. Here's an idea. Establish some kind of policy on archiving older versions of gems. Hmmm ... something like keeping the last 10 version or the last year's worth of versions (whichever is less) on the normal gem server (http://gems.rubyforge.org). When a version falls off the map, move it to http://gems.rubyforge.org/archive, where it will remain available. If someone really needs it, they can use the --source option. (the 10 version / 1 year criteria is offered as an example... feel free to debate the merits of other policies). That will keep the main gem index from growing so large so fast. Beyond that, we should have an explicit interface for gem authors to mark archive versions and remove flawed gems on the server. Something like this would allow the gem author to remove the deprecated gems themselves. There would be some effort to put the interface together, but perhaps someone would like to take it on as a RAILSDAY project :). Just some random thoughts on the topic. -- -- 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 chad at chadfowler.com Sun Apr 17 18:55:00 2005 From: chad at chadfowler.com (Chad Fowler) Date: Sun Apr 17 18:49:19 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: <200504162308.44350.jim@weirichhouse.org> References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> Message-ID: On 16-Apr-05, at 11:08 PM, Jim Weirich wrote: > On Saturday 16 April 2005 09:33 pm, Gavin Sinclair wrote: >> On the rails list, some confusion has permeated surrounding the wad of >> gems surrounding sqlite. The main problem is that one of them is >> deprecated. >> >> I suggested to Jamis that he update the description of the deprecated >> one ("sqlite") which informs the user that it's deprecated and they >> should use sqlite-ruby or sqlite3-ruby instead. >> >> As far as I'm concerned, that's a sufficient solution. Just thought >> I'd mention the issue here, though, in case someone thinks an explicit >> way of deprecating gems is a useful idea. > > I was actually thinking about such things recently. Although its cool > that > rubyforge lists all gems that were /ever/ uploaded (minus the handfull > that > have been explicitly withdrawn), I'm wondering if that is a sustainable > model. The yaml.Z file is enormous and most of those older gems that > have > been replaced by newer versions are of little use to most people. > > Here's an idea. Establish some kind of policy on archiving older > versions of > gems. Hmmm ... something like keeping the last 10 version or the last > year's > worth of versions (whichever is less) on the normal gem server > (http://gems.rubyforge.org). When a version falls off the map, move > it to > http://gems.rubyforge.org/archive, where it will remain available. If > someone really needs it, they can use the --source option. (the 10 > version / > 1 year criteria is offered as an example... feel free to debate the > merits of > other policies). > > That will keep the main gem index from growing so large so fast. > > Beyond that, we should have an explicit interface for gem authors to > mark > archive versions and remove flawed gems on the server. Something like > this > would allow the gem author to remove the deprecated gems themselves. > There > would be some effort to put the interface together, but perhaps > someone would > like to take it on as a RAILSDAY project :). > > Just some random thoughts on the topic. > > I like these ideas. I especially like the fact that --source could be used to access archived gems. The only thing I don't like about this is that it would remove the ability to do a centralized search of every gem ever deployed. Of course, that could be handled via a separate mechanism (like a web app--hmmmm...). Someone on IRC suggested we deal with referrals at one point. So, you could register just enough metadata to respond to a search, but any request for details or the download of a gem would result in a referral (similar to the way LDAP works, if any of you are familiar with it) which the gem client would follow. Could be interesting. Would require quite a bit of thought before implementing something like that. Chad From jim at weirichhouse.org Sun Apr 17 19:59:58 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sun Apr 17 19:54:49 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> Message-ID: <200504171959.58176.jim@weirichhouse.org> On Sunday 17 April 2005 06:55 pm, Chad Fowler wrote: > I like these ideas. ?I especially like the fact that --source could be > used to access archived gems. ?The only thing I don't like about this is > that it would remove the ability to do a centralized search of every > gem ever deployed. If we got sufficiently sophisticated with --source, we could allow multiple sources, so a search could include the normal source and the archive site. (In fact, I thought that was the way it worked until a week ago when I tried to install a gem from one source that had dependencies on gems from another ... I was surprised that gem couldn't resolve the dependencies across sources). -- -- 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 gsinclair at soyabean.com.au Sun Apr 17 20:49:23 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Sun Apr 17 20:44:02 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> Message-ID: <145144661542.20050418104923@soyabean.com.au> On Monday, April 18, 2005, 8:55:00 AM, Chad wrote: >> Here's an idea. Establish some kind of policy on archiving older >> versions of gems. Hmmm ... something like keeping the last 10 >> version or the last year's worth of versions (whichever is less) on >> the normal gem server (http://gems.rubyforge.org). When a version >> falls off the map, move it to http://gems.rubyforge.org/archive, >> where it will remain available. If someone really needs it, they >> can use the --source option. (the 10 version / 1 year criteria is >> offered as an example... feel free to debate the merits of other >> policies). > I like these ideas. I especially like the fact that --source could > be used to access archived gems. The only thing I don't like about > this is that it would remove the ability to do a centralized search > of every gem ever deployed. That's probably not a search people want to do very much at all. In practice, I think deprecation of an entire gem (as opposed to archival of old versions) would be rare. It would be nice if gem could give output like this: $ gem list -r rails rails (0.11.1, 0.11.0, 0.10.1, 0.10.0, ...) Web-application framework with template engine, control-flow layer, and ORM. where the "..." is taken to mean "older versions available". Having a separate gem server for archived gems is a good idea, I believe, and the gem command could even recognise this: $ gem list -r rails --archive rails (0.9.5, 0.9.4.1, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.5, 0.8.0, 0.7.0, 0.6.5, 0.6.0) ... > Of course, that could be handled via a separate mechanism (like a web > app--hmmmm...). :) > Someone on IRC suggested we deal with referrals at one point. So, > you could register just enough metadata to respond to a search, but > any request for details or the download of a gem would result in a > referral (similar to the way LDAP works, if any of you are familiar > with it) which the gem client would follow. > Could be interesting. Would require quite a bit of thought before > implementing something like that. Not familiar and don't quite understand, sorry. Gavin From jim at weirichhouse.org Sun Apr 17 21:07:46 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sun Apr 17 21:02:33 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> Message-ID: <200504172107.46205.jim@weirichhouse.org> On Sunday 17 April 2005 06:55 pm, Chad Fowler wrote: > I like these ideas. ?I especially like the fact that --source could be > used to access archived gems. While we are discussing it, I think a 'beta' section of the archive would be useful too, allowing folks to release early versions of gems before they are ready for general public consumption. I've started to do a "roll your own" beta site at http://onestepback.org/betagems. I will release rake and rubygems gems there before deploying them on RubyForge (especially after that one rubygems release that had a bad gem that horked the rubyforge indexer). -- -- 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 gsinclair at soyabean.com.au Sun Apr 17 21:49:45 2005 From: gsinclair at soyabean.com.au (Gavin Sinclair) Date: Sun Apr 17 21:44:24 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: <200504172107.46205.jim@weirichhouse.org> References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> <200504172107.46205.jim@weirichhouse.org> Message-ID: <68148283260.20050418114945@soyabean.com.au> On Monday, April 18, 2005, 11:07:46 AM, Jim wrote: > On Sunday 17 April 2005 06:55 pm, Chad Fowler wrote: >> I like these ideas. ?I especially like the fact that --source could be >> used to access archived gems. > While we are discussing it, I think a 'beta' section of the archive would be > useful too, allowing folks to release early versions of gems before they are > ready for general public consumption. > I've started to do a "roll your own" beta site at > http://onestepback.org/betagems. I will release rake and rubygems gems there > before deploying them on RubyForge (especially after that one rubygems > release that had a bad gem that horked the rubyforge indexer). Yeah, when I saw that _you_ have a beta gems site, in addition to 2 or 3 others I know of, I thought "Perhaps it's time to let people easily release beta gems - i.e. without having to run their own server." So a beta server and an archive server running on Rubyforge sound good to me. Gavin From discordantus at gmail.com Fri Apr 22 01:29:11 2005 From: discordantus at gmail.com (Mark Hubbart) Date: Fri Apr 22 01:23:21 2005 Subject: [Rubygems-developers] Ruby's --with-site-dir and Rubygems' gem_path Message-ID: Hi all, Sorry in advance for my long-windedness. I've been working on this for a long time, and I was unable to find a good solution on my own. I'm working on a project that configures and compiles a customized Ruby install. As part of this, the site_ruby directory is moved to a separate location (using Ruby's --with-site-dir=path configure option). This badly confuses the RubyGems setup, which then chooses a strange place for it's gem_path. Is there a way to fix this? The easiest solution (I think) would be to add an option to RubyGems' setup.rb that would allow specifying a gem_path. Because of the project being the way it is, I can't use the GEM_DIR environment variable. I'm trying to work out a patch the the Gem.default_dir method that would give the same result for normal installations, while still giving reasonable values for unusual configurations. Until it gets figured out (by me or otherwise), a --with-default-gem-path configure option for RubyGems would be a great solution. I will happily do whatever's needed of me to make this work; say the words and I'll submit a patch :) I feel that the project I'm working on (the mac ruby framework project) will be an extremely important project in the future, but it will require RubyGems' setup process to be as flexible as Ruby's is. Thanks much for all the great work you guys have done on RubyGems :) Thanks, Mark From discordantus at gmail.com Sat Apr 23 01:40:21 2005 From: discordantus at gmail.com (Mark Hubbart) Date: Sat Apr 23 01:34:59 2005 Subject: [Rubygems-developers] Ruby's --with-site-dir and Rubygems' gem_path Message-ID: <157594119899.20050423154021@soyabean.com.au> [My reply went to Mark instead of the list. I'm redirecting his reply to me here.] On 4/22/05, Gavin Sinclair wrote: > On Friday, April 22, 2005, 3:29:11 PM, Mark wrote: > > > Hi all, > > > Sorry in advance for my long-windedness. I've been working on this for > > a long time, and I was unable to find a good solution on my own. > > > I'm working on a project that configures and compiles a customized > > Ruby install. As part of this, the site_ruby directory is moved to a > > separate location (using Ruby's --with-site-dir=path configure > > option). This badly confuses the RubyGems setup, which then chooses a > > strange place for it's gem_path. > > On the face of it, this shouldn't confuse RubyGems. All the > information about site dir, etc., is available in the Config module > (isn't it?), so RubyGems should have the info it needs to choose a > directory for itself. > > Just let me ask: you _are_ following this procedure, aren't you? > > * Install Ruby (customised up the wazoo) > > * Use that Ruby to install RubyGems > > * Not stuff around with Ruby's or RubyGems' configuration afterwards That's pretty much it. I do nothing with RubyGems that isn't in the setup.rb. > If you're following that (broad) procedure and RubyGems is getting > confused, I'd say RubyGems has a problem. > > Perhaps you could go into detail about all the directories involved. > That would help confirm what RubyGems is doing. Okay. *deep breath* This customized Ruby install is actually a Ruby.framework, the native format for installing libraries and their associated support files and executables on OSX/*Step. This is the way Python is installed on OSX, and it is hoped that we can get Ruby up to the same standard. For RubyGems' purpose, the main difference is that the site_ruby directory is part of an entirely different part of the directory tree from the main install, not parallel to it. Here are the main directories in this install. framework: /Library/Frameworks/Ruby.framework prefix: /Library/Frameworks/Ruby.framework/Versions/1.8 libdir: /Library/Frameworks/Ruby.framework/Versions/1.8/lib rubylibdir: /Library/Frameworks/Ruby.framework/Versions/1.8/lib/scripts archdir: /Library/Frameworks/Ruby.framework/Versions/1.8/lib/bundles supportdir: /Library/Ruby sitedir: /Library/Ruby/1.8/lib sitelib: /Library/Ruby/1.8/lib/scripts sitearchdir: /Library/Ruby/1.8/lib/bundles The "framework" and "support" directories are OSX concepts, and Ruby doesn't know or care about them (for now). But, in theory, an administrator should be able to (fairly) safely add or remove items from the support dir, and the framework dir should always be left completely alone. By default, Rubygems wanted to install most of it's files in the framework directory, using Ruby's prefix. That would not be good, so I specified a different prefix (for a sort of lightweight framework), and a rubypath that would make sure ruby was found: ruby setup.rb --prefix=/Library/Frameworks/RubyGems.framework/Versions/A \ --rubypath='usr/bin/env ruby' I figured it would be okay for now to allow RubyGems to have free reign over Ruby's support dir and the RubyGems framework dir. When I installed, that's where all the files went. Except the sources gem, which went in the gemdir; inside the Ruby.framework. binaries: /Library/Frameworks/RubyGems.framework/Versions/A/bin libfiles: /Library/Ruby/1.8/lib/scripts gems libs: /Library/Frameworks/Ruby.framework/Versions/1.8/lib/ruby/gems/1.8 The gem dir is inside the *main* ruby installation (in the framework), not in the support dir, alongside the equivalent of the site_ruby folder. While it technically works, this is a very bad setup, as bad as if RubyGems were dumping files into ruby's stdlib directory. And I don't think it's what was intended. I realize why it would be hard to programmatically determine the correct directory to choose for the gem dir. The way that is used currently will work for nearly all installs, it just happens not to for this one. I'm assuming that the gem directory was supposed to be alongside the site_ruby directory, as they are the directories that can be modified. The easiest way (I think) to solve this would be to allow a setup argument, so the path can be corrected if it appears wrong. Or, a bit more in-depth analysis of the paths retrieved from Config::CONFIG could be done. I'm trying to figure out how that might work... Anyway, as I said, I'm very willing to help with this. Just tell me what to do. The main reason I didn't just come up with a patch and submit it is that there are probably going to be some decisions made about the best way to handle this, and they aren't my decisions to make :) The ruby framework is currently in a pre-alpha state. Getting RubyGems to *work* is, I feel, one of the requirements before moving to alpha :) thanks, Mark From pabs at pablotron.org Tue Apr 26 16:22:26 2005 From: pabs at pablotron.org (Paul Duncan) Date: Tue Apr 26 16:16:31 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems Message-ID: <20050426202226.GF26233@vault.home.pablotron.org> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050426/7838c431/attachment-0001.bin From chad at chadfowler.com Tue Apr 26 18:49:21 2005 From: chad at chadfowler.com (Chad Fowler) Date: Tue Apr 26 18:43:21 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems In-Reply-To: <20050426202226.GF26233@vault.home.pablotron.org> References: <20050426202226.GF26233@vault.home.pablotron.org> Message-ID: On 26-Apr-05, at 4:22 PM, Paul Duncan wrote: > Hi Everyone, > > Attached is a patch against RubyGems 0.8.10 that adds cryptographic > signature support to Ruby Gems via OpenSSL. Attached to this email > (and included in the patch under doc/) is some fairly detailed and > (hopefully) straightforward documentation explaining how to adjust your > security policy, create a gem signing certificate, and sign your own > gems. > > These changes should be backwards compatible (ie, signed gems will work > properly in older versions of Ruby Gems). > > The patch (and PGP signature) are also available online at the > following > URLs: > > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz.asc > > PS. I let Chad know that this patch was coming a couple weeks ago, so > if > it doesn't apply clean for any reason, he's the one to throw rocks at, > not me! :) > Wow, Paul. This is great. I haven't had a chance to try it out yet, but i read the docs and was very impressed. Wonderful job documenting, too! Any other RubyGemmers that are more signing-savvy than me want to take a look? Chad From pabs at pablotron.org Tue Apr 26 19:02:37 2005 From: pabs at pablotron.org (Paul Duncan) Date: Tue Apr 26 18:56:39 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems In-Reply-To: References: <20050426202226.GF26233@vault.home.pablotron.org> Message-ID: <20050426230237.GG26233@vault.home.pablotron.org> * Chad Fowler (chad@chadfowler.com) wrote: > > On 26-Apr-05, at 4:22 PM, Paul Duncan wrote: > > >Hi Everyone, > > > >Attached is a patch against RubyGems 0.8.10 that adds cryptographic > >signature support to Ruby Gems via OpenSSL. Attached to this email > >(and included in the patch under doc/) is some fairly detailed and > >(hopefully) straightforward documentation explaining how to adjust your > >security policy, create a gem signing certificate, and sign your own > >gems. > > > >These changes should be backwards compatible (ie, signed gems will work > >properly in older versions of Ruby Gems). > > > >The patch (and PGP signature) are also available online at the > >following > >URLs: > > > > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz > > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz.asc > > > >PS. I let Chad know that this patch was coming a couple weeks ago, so > >if > >it doesn't apply clean for any reason, he's the one to throw rocks at, > >not me! :) > > > > Wow, Paul. This is great. I haven't had a chance to try it out yet, > but i read the docs and was very impressed. Wonderful job documenting, > too! You're just worried about the rocks at the end of the message! But thanks either way :). > Any other RubyGemmers that are more signing-savvy than me want to take > a look? > > Chad -- Paul Duncan OpenPGP Key ID: 0x82C29562 http://www.pablotron.org/ http://www.paulduncan.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050426/c88caf2c/attachment.bin From pabs at pablotron.org Tue Apr 26 19:32:13 2005 From: pabs at pablotron.org (Paul Duncan) Date: Tue Apr 26 19:26:15 2005 Subject: [Rubygems-developers] Deprecating gems In-Reply-To: <200504162308.44350.jim@weirichhouse.org> References: <17360926788.20050417113348@soyabean.com.au> <200504162308.44350.jim@weirichhouse.org> Message-ID: <20050426233213.GH26233@vault.home.pablotron.org> * Jim Weirich (jim@weirichhouse.org) wrote: > On Saturday 16 April 2005 09:33 pm, Gavin Sinclair wrote: > > On the rails list, some confusion has permeated surrounding the wad of > > gems surrounding sqlite. The main problem is that one of them is > > deprecated. > > > > I suggested to Jamis that he update the description of the deprecated > > one ("sqlite") which informs the user that it's deprecated and they > > should use sqlite-ruby or sqlite3-ruby instead. > > > > As far as I'm concerned, that's a sufficient solution. Just thought > > I'd mention the issue here, though, in case someone thinks an explicit > > way of deprecating gems is a useful idea. > > I was actually thinking about such things recently. Although its cool that > rubyforge lists all gems that were /ever/ uploaded (minus the handfull that > have been explicitly withdrawn), I'm wondering if that is a sustainable > model. The yaml.Z file is enormous and most of those older gems that have > been replaced by newer versions are of little use to most people. What I'd also like is a way of sending deltas on the yaml.Z file. For example, a query of the remote list could send the last query date as an HTTP header (HTTP 1.0 has "If-Modified-Since/Last-Modified", and HTTP 1.1 has "If-None-Match/ETag", which is an opaque value, but serves a similar purpose), and the server could generate a response which contains only the changes since that date. Alternatively, RubyGems could define it's own HTTP header ("X-RubyGems-Last-Update:" or something comparably benign), or even pass the last updated timestamp as a GET parameter. It would also be nice to set up RubyGems mirrors -- I could spare 50-150G a month, and I'm sure we've got other people who could do the same. The combination of sending deltas and having a set of official mirrors should significantly speed up remote operations in RubyGems. > Here's an idea. Establish some kind of policy on archiving older versions of > gems. Hmmm ... something like keeping the last 10 version or the last year's > worth of versions (whichever is less) on the normal gem server > (http://gems.rubyforge.org). When a version falls off the map, move it to > http://gems.rubyforge.org/archive, where it will remain available. If > someone really needs it, they can use the --source option. (the 10 version / > 1 year criteria is offered as an example... feel free to debate the merits of > other policies). > > That will keep the main gem index from growing so large so fast. > > Beyond that, we should have an explicit interface for gem authors to mark > archive versions and remove flawed gems on the server. Something like this > would allow the gem author to remove the deprecated gems themselves. There > would be some effort to put the interface together, but perhaps someone would > like to take it on as a RAILSDAY project :). > > Just some random thoughts on the topic. > > -- > -- 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 -- Paul Duncan OpenPGP Key ID: 0x82C29562 http://www.pablotron.org/ http://www.paulduncan.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050426/4fcd8b2d/attachment.bin From marcel at vernix.org Wed Apr 27 11:07:38 2005 From: marcel at vernix.org (Marcel Molina Jr.) Date: Wed Apr 27 11:01:41 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems In-Reply-To: <20050426202226.GF26233@vault.home.pablotron.org> References: <20050426202226.GF26233@vault.home.pablotron.org> Message-ID: <20050427150738.GC25392@simons-rock.edu> On Tue, Apr 26, 2005 at 04:22:26PM -0400, Paul Duncan wrote: > Hi Everyone, > > Attached is a patch against RubyGems 0.8.10 that adds cryptographic > signature support to Ruby Gems via OpenSSL. Attached to this email > (and included in the patch under doc/) is some fairly detailed and > (hopefully) straightforward documentation explaining how to adjust your > security policy, create a gem signing certificate, and sign your own > gems. > > These changes should be backwards compatible (ie, signed gems will work > properly in older versions of Ruby Gems). > > The patch (and PGP signature) are also available online at the following > URLs: > > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz > http://pablotron.org/files/rubygems-0.8.10-sign.diff.gz.asc > > PS. I let Chad know that this patch was coming a couple weeks ago, so if > it doesn't apply clean for any reason, he's the one to throw rocks at, > not me! :) Wow. This is really, *really* awesome. Thanks so much. The docs themselves are worth the price of admission. >From the Bugs/TODO section: * right now I'm using ENV['HOME'] + '.rubygems/trust' for the trusted cert list. this has a couple of problems: it won't work in windows, and there's no way to define a system-wide trust list. The code base provides Gem#find_home, which seems to do a pretty good job of being platform agnostic. Reminder: Your great work is really appreciated. marcel -- Marcel Molina Jr. From marcel at vernix.org Wed Apr 27 11:26:53 2005 From: marcel at vernix.org (Marcel Molina Jr.) Date: Wed Apr 27 11:20:56 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems In-Reply-To: <20050427150738.GC25392@simons-rock.edu> References: <20050426202226.GF26233@vault.home.pablotron.org> <20050427150738.GC25392@simons-rock.edu> Message-ID: <20050427152653.GA18534@foxy.vernix.org> On Wed, Apr 27, 2005 at 11:07:38AM -0400, Marcel Molina Jr. wrote: > > Attached is a patch against RubyGems 0.8.10 that adds cryptographic > > signature support to Ruby Gems via OpenSSL. Attached to this email > > (and included in the patch under doc/) is some fairly detailed and > > (hopefully) straightforward documentation explaining how to adjust your > > security policy, create a gem signing certificate, and sign your own > > gems. One other thing: Your CertCommand uses 'puts' in several places when from what I gather most output in the gem_command.rb uses the 'say' method, defined in user_interaction.rb. thanks again, marcel -- Marcel Molina Jr. From pabs at pablotron.org Fri Apr 29 07:13:42 2005 From: pabs at pablotron.org (Paul Duncan) Date: Fri Apr 29 07:07:38 2005 Subject: [Rubygems-developers] [PATCH] Add Gem Signing Support to RubyGems In-Reply-To: <20050427152653.GA18534@foxy.vernix.org> References: <20050426202226.GF26233@vault.home.pablotron.org> <20050427150738.GC25392@simons-rock.edu> <20050427152653.GA18534@foxy.vernix.org> Message-ID: <20050429111342.GJ26233@vault.home.pablotron.org> * Marcel Molina Jr. (marcel@vernix.org) wrote: > On Wed, Apr 27, 2005 at 11:07:38AM -0400, Marcel Molina Jr. wrote: > > > Attached is a patch against RubyGems 0.8.10 that adds cryptographic > > > signature support to Ruby Gems via OpenSSL. Attached to this email > > > (and included in the patch under doc/) is some fairly detailed and > > > (hopefully) straightforward documentation explaining how to adjust your > > > security policy, create a gem signing certificate, and sign your own > > > gems. > > One other thing: Your CertCommand uses 'puts' in several places when from > what I gather most output in the gem_command.rb uses the 'say' method, > defined in user_interaction.rb. Hi Marcel, You're right on the money on both of your replies. I'll whip up a patch this afternoon that fixes both of those problems. PS. I'm glad this is the kind of problems that are cropping up, rather than something like "I applied your patch and my computer exploded, aaah my eyes, the pain!" :) > thanks again, > marcel -- Paul Duncan OpenPGP Key ID: 0x82C29562 http://www.pablotron.org/ http://www.paulduncan.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20050429/569808d4/attachment.bin