From aslak.hellesoy at gmail.com Thu Sep 1 20:55:17 2005 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Thu Sep 1 20:48:58 2005 Subject: [Rubygems-developers] MetaProject Message-ID: <8d961d9005090117558d0cfea@mail.gmail.com> Hi all, The past month I've been working on a project (MetaProject: http://xforge.rubyforge.org/) that among other things includes a quick release system (QRS) for (among other places) RubyForge. With MetaProject's Rake task, releasing new gems on RubyForge is a breeze: task :release_files => [:gem] do release_files = FileList[ "pkg/#{PKG_FILE_NAME}.gem" ] Rake::XForge::Release.new(MetaProject::Project::XForge::RubyForge.new('xforge')) do |release| # Never hardcode user name and password in the Rakefile! release.user_name = ENV['RUBYFORGE_USER'] release.password = ENV['RUBYFORGE_PASSWORD'] release.files = release_files.to_a release.release_name = "MetaProject #{PKG_VERSION}" # The rest of the options are defaults (among others, release_notes and release_changes, parsed from CHANGES) end end Would you consider mentioning this in the RubyGems documentation? Cheers, Aslak From chad at chadfowler.com Fri Sep 2 15:21:28 2005 From: chad at chadfowler.com (Chad Fowler) Date: Fri Sep 2 15:14:43 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: <8d961d9005090117558d0cfea@mail.gmail.com> References: <8d961d9005090117558d0cfea@mail.gmail.com> Message-ID: On 01-Sep-05, at 8:55 PM, aslak hellesoy wrote: > Hi all, > > The past month I've been working on a project (MetaProject: > http://xforge.rubyforge.org/) that among other things includes a quick > release system (QRS) for (among other places) RubyForge. > > With MetaProject's Rake task, releasing new gems on RubyForge is a > breeze: > > task :release_files => [:gem] do > release_files = FileList[ > "pkg/#{PKG_FILE_NAME}.gem" > ] > > Rake::XForge::Release.new > (MetaProject::Project::XForge::RubyForge.new('xforge')) > do |release| > # Never hardcode user name and password in the Rakefile! > > release.user_name = ENV['RUBYFORGE_USER'] > > release.password = ENV['RUBYFORGE_PASSWORD'] > release.files = release_files.to_a > release.release_name = "MetaProject #{PKG_VERSION}" > > # The rest of the options are defaults (among others, > release_notes and release_changes, parsed from CHANGES) > end > end > > Would you consider mentioning this in the RubyGems documentation? > > Aslak, definitely! Where do you think it would best fit? Chad > From hgs at dmu.ac.uk Fri Sep 2 16:08:44 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri Sep 2 16:02:25 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: References: <8d961d9005090117558d0cfea@mail.gmail.com> Message-ID: On Fri, 2 Sep 2005, Chad Fowler wrote: > > On 01-Sep-05, at 8:55 PM, aslak hellesoy wrote: I managed to miss that. > >> Hi all, >> >> The past month I've been working on a project (MetaProject: >> http://xforge.rubyforge.org/) that among other things includes a quick >> release system (QRS) for (among other places) RubyForge. >> >> With MetaProject's Rake task, releasing new gems on RubyForge is a breeze: I like the irony! QRS means "send more slowly" :-) http://hharc.sa.utoronto.ca/q-codes.php >> >> task :release_files => [:gem] do >> release_files = FileList[ >> "pkg/#{PKG_FILE_NAME}.gem" >> ] >> >> Rake::XForge::Release.new(MetaProject::Project::XForge::RubyForge.new('xforge')) >> do |release| >> # Never hardcode user name and password in the Rakefile! >> >> release.user_name = ENV['RUBYFORGE_USER'] >> >> release.password = ENV['RUBYFORGE_PASSWORD'] Umm, you probably shouldn't leave them in the ENVIRONMENT either, because it can be picked up with the PS command. >> release.files = release_files.to_a >> release.release_name = "MetaProject #{PKG_VERSION}" >> >> # The rest of the options are defaults (among others, >> release_notes and release_changes, parsed from CHANGES) >> end >> end Nice. >> >> Would you consider mentioning this in the RubyGems documentation? >> >> > Hugh From aslak.hellesoy at gmail.com Sat Sep 3 21:29:13 2005 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat Sep 3 21:22:21 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: References: <8d961d9005090117558d0cfea@mail.gmail.com> Message-ID: <8d961d9005090318298601076@mail.gmail.com> On 9/2/05, Chad Fowler wrote: > > On 01-Sep-05, at 8:55 PM, aslak hellesoy wrote: > > > Hi all, > > > > The past month I've been working on a project (MetaProject: > > http://xforge.rubyforge.org/) that among other things includes a quick > > release system (QRS) for (among other places) RubyForge. > > > > With MetaProject's Rake task, releasing new gems on RubyForge is a > > breeze: > > > > task :release_files => [:gem] do > > release_files = FileList[ > > "pkg/#{PKG_FILE_NAME}.gem" > > ] > > > > Rake::XForge::Release.new > > (MetaProject::Project::XForge::RubyForge.new('xforge')) > > do |release| > > # Never hardcode user name and password in the Rakefile! > > > > release.user_name = ENV['RUBYFORGE_USER'] > > > > release.password = ENV['RUBYFORGE_PASSWORD'] > > release.files = release_files.to_a > > release.release_name = "MetaProject #{PKG_VERSION}" > > > > # The rest of the options are defaults (among others, > > release_notes and release_changes, parsed from CHANGES) > > end > > end > > > > Would you consider mentioning this in the RubyGems documentation? > > > > > > Aslak, definitely! Where do you think it would best fit? > Under here: http://docs.rubygems.org/read/chapter/6 I have created a aslak_hellesoy user. If you give me write access I'll write the chapter myself. Cheers, Aslak > Chad > > > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From aslak.hellesoy at gmail.com Sat Sep 3 21:32:08 2005 From: aslak.hellesoy at gmail.com (aslak hellesoy) Date: Sat Sep 3 21:25:16 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: References: <8d961d9005090117558d0cfea@mail.gmail.com> Message-ID: <8d961d9005090318325e84c732@mail.gmail.com> > >> # Never hardcode user name and password in the Rakefile! > >> > >> release.user_name = ENV['RUBYFORGE_USER'] > >> > >> release.password = ENV['RUBYFORGE_PASSWORD'] > > Umm, you probably shouldn't leave them in the ENVIRONMENT either, > because it can be picked up with the PS command. > not even if you do rake release RUBYFORGE_USER=aslak_hellesoy RUBYFORGE_PASSWORD=blech ? Anyway, MetaProject will prompt you if you haven't specified it. Aslak From ryan.raaum at gmail.com Tue Sep 6 17:12:41 2005 From: ryan.raaum at gmail.com (Ryan Raaum) Date: Tue Sep 6 17:05:43 2005 Subject: [Rubygems-developers] rubygems LoadError driving me insane Message-ID: Hello everyone, I am slowly being driven over the edge by a small loading problem in Mac OS X. I want my ruby/gems install to be self-contained and capable of being moved around on the system - feeding it the appropriate paths and what not through environment variables. If I set PATH and RUBYLIB on the command line to point to my mobile ruby install, everything seems to work fine. I can run anything I try. I can fire up irb and require 'rubygems', etc. BUT, when I do the exact same thing programmatically (NSTask from Cocoa) - that is, set PATH, set RUBYLIB, then try to fire off a script, I get: No such file to load -- rubygems (LoadError) Any ideas?? I'm setting PATH=/path/to/mobile/ruby/bin:$PATH RUBYLIB=/path/to/mobile/ruby/lib/ruby/site-ruby/1.8:...site-ruby/1.8/powerpc-darwin7.9.0:.../site-ruby:...1.8:...1.8/powerpc-darwin7.9.0 (with ... just cutting out the verbosity for this post). It doesn't seem to matter if the shebang in the script I am trying to run points directly to the ruby interpreter or use /usr/bin/env Thanks very much! -r -- Ryan Raaum http://www.rockefeller.edu -- Bacterial Pathogenesis and Immunology http://www.worldmartial.com -- Black Belt Instructor http://locomotive.sourceforge.net -- Self contained one-click Rails for Mac OS X From chad at chadfowler.com Wed Sep 7 10:18:26 2005 From: chad at chadfowler.com (Chad Fowler) Date: Wed Sep 7 10:11:36 2005 Subject: [Rubygems-developers] rubygems LoadError driving me insane In-Reply-To: References: Message-ID: <4B3EF25F-F880-4DD5-BE65-0B5FFBEC8B7F@chadfowler.com> On 06-Sep-05, at 5:12 PM, Ryan Raaum wrote: > Hello everyone, > > I am slowly being driven over the edge by a small loading problem > in Mac OS X. > > I want my ruby/gems install to be self-contained and capable of being > moved around on the system - feeding it the appropriate paths and what > not through environment variables. > > If I set PATH and RUBYLIB on the command line to point to my mobile > ruby install, everything seems to work fine. I can run anything I > try. I can fire up irb and require 'rubygems', etc. > > BUT, when I do the exact same thing programmatically (NSTask from > Cocoa) - that is, set PATH, set RUBYLIB, then try to fire off a > script, I get: > > No such file to load -- rubygems (LoadError) > > Any ideas?? > > I'm setting > > PATH=/path/to/mobile/ruby/bin:$PATH > RUBYLIB=/path/to/mobile/ruby/lib/ruby/site-ruby/1.8:...site-ruby/ > 1.8/powerpc-darwin7.9.0:.../site-ruby:...1.8:...1.8/powerpc- > darwin7.9.0 > (with ... just cutting out the verbosity for this post). > > It doesn't seem to matter if the shebang in the script I am trying to > run points directly to the ruby interpreter or use /usr/bin/env > > Hi Ryan! Can you perhaps print out the contents of $: from within the forked script? Chad From ryan.raaum at gmail.com Wed Sep 7 12:48:35 2005 From: ryan.raaum at gmail.com (Ryan Raaum) Date: Wed Sep 7 12:41:35 2005 Subject: [Rubygems-developers] rubygems LoadError driving me insane In-Reply-To: <4B3EF25F-F880-4DD5-BE65-0B5FFBEC8B7F@chadfowler.com> References: <4B3EF25F-F880-4DD5-BE65-0B5FFBEC8B7F@chadfowler.com> Message-ID: Hi Chad, > Hi Ryan! Can you perhaps print out the contents of $: from within > the forked script? Ok. (long long paths...). The /Users/ryan/... path is the one I am trying to use. The /Applications/Locomotive.app/... path is where I initially configured the ruby/gems tree - however, that file tree no longer exists, but seems to be hardcoded into ruby somewhere that I haven't been able to find... If I clean out my environment on the command line and set my PATH and RUBYLIB there - things work... /Users/ryan/Development/locomotive-trunk/build/Locomotive.app/rails-0.13.1/lib/ruby/site-ruby/1.8 /Users/ryan/Development/locomotive-trunk/build/Locomotive.app/rails-0.13.1/lib/ruby/site-ruby/1.8/powerpc-darwin7.9.0 /Users/ryan/Development/locomotive-trunk/build/Locomotive.app/rails-0.13.1/lib/ruby/site-ruby /Users/ryan/Development/locomotive-trunk/build/Locomotive.app/rails-0.13.1/lib/ruby/1.8 /Users/ryan/Development/locomotive-trunk/build/Locomotive.app/rails-0.13.1/lib/ruby/1.8/powerpc-darwin7.9.0 /Applications/Locomotive.app/rails-0.13.1/lib/ruby/site_ruby/1.8 /Applications/Locomotive.app/rails-0.13.1/lib/ruby/site_ruby/1.8/powerpc-darwin7.9.0 /Applications/Locomotive.app/rails-0.13.1/lib/ruby/site_ruby /Applications/Locomotive.app/rails-0.13.1/lib/ruby/1.8 /Applications/Locomotive.app/rails-0.13.1/lib/ruby/1.8/powerpc-darwin7.9.0 . Any ideas you have would be great! Thanks! --ryan From tilman at code-monkey.de Wed Sep 7 15:14:32 2005 From: tilman at code-monkey.de (Tilman Sauerbeck) Date: Wed Sep 7 15:07:33 2005 Subject: [Rubygems-developers] [PATCH] Support extensions built with rake In-Reply-To: <20050830230621.4fe3add9.tilman@code-monkey.de> References: <20050812135812.GA5828@code-monkey.de> <3FF6741F-6FD5-4B26-B0E6-622CF62F772E@chadfowler.com> <20050830215620.22432409.tilman@code-monkey.de> <20050830230621.4fe3add9.tilman@code-monkey.de> Message-ID: <20050907211432.2b2007fd.tilman@code-monkey.de> On Tue, 30 Aug 2005 23:06:21 +0200 Tilman Sauerbeck wrote: > > Are you able to install your ruby-eet gem using this patch? I get this: > > > > $ sudo gem install ruby-eet-0.1.3.gem --backtrace > > Attempting local installation of 'ruby-eet-0.1.3.gem' > > Building native extensions. This could take a while... > > ERROR: Error installing gem ruby-eet-0.1.3.gem[.gem]: undefined > > method `join' for nil:NilClass > > Ugh, I think I attached the wrong diff :O > Try this one, I just verified that it's working for me. I don't want to be a PITA, but did you get a chance to try the patch? :) Regards, Tilman -- learn to quote: http://www.netmeister.org/news/learn2quote.html From halostatue at gmail.com Fri Sep 9 22:34:36 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Fri Sep 9 22:27:32 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: <8d961d9005090318325e84c732@mail.gmail.com> References: <8d961d9005090117558d0cfea@mail.gmail.com> <8d961d9005090318325e84c732@mail.gmail.com> Message-ID: <9e7db91105090919345fc72793@mail.gmail.com> By the way, folks, this project ROCKS. -austin From chad at chadfowler.com Sun Sep 11 10:00:50 2005 From: chad at chadfowler.com (Chad Fowler) Date: Sun Sep 11 09:53:56 2005 Subject: [Rubygems-developers] MetaProject In-Reply-To: <8d961d9005090318325e84c732@mail.gmail.com> References: <8d961d9005090117558d0cfea@mail.gmail.com> <8d961d9005090318325e84c732@mail.gmail.com> Message-ID: On 03-Sep-05, at 9:32 PM, aslak hellesoy wrote: >>>> # Never hardcode user name and password in the Rakefile! >>>> >>>> release.user_name = ENV['RUBYFORGE_USER'] >>>> >>>> release.password = ENV['RUBYFORGE_PASSWORD'] >>>> >> >> Umm, you probably shouldn't leave them in the ENVIRONMENT either, >> because it can be picked up with the PS command. >> >> > > not even if you do > > rake release RUBYFORGE_USER=aslak_hellesoy RUBYFORGE_PASSWORD=blech > ? > > Anyway, MetaProject will prompt you if you haven't specified it. > > Aslak > Hi Aslak. Sorry this has taken so long. I had some trouble with the Hieraki installation for docs.rubygems.org. I _believe_ you should be set up now. Can you try it? Thanks, Chad From dougkearns at gmail.com Mon Sep 12 00:33:29 2005 From: dougkearns at gmail.com (Doug Kearns) Date: Mon Sep 12 00:35:10 2005 Subject: [Rubygems-developers] Rubyforge - deleting released gems Message-ID: <20050912043329.GA12906@localhost.localdomain> I was just wondering if the rubyforge 'integration' works both ways. Will a previously released file which has been deleted, from rubyforge, also be deleted from the gems repository? Thanks, Doug From jim.weirich at gmail.com Mon Sep 12 08:10:24 2005 From: jim.weirich at gmail.com (Jim Weirich) Date: Mon Sep 12 08:03:15 2005 Subject: [Rubygems-developers] Rubyforge - deleting released gems In-Reply-To: <20050912043329.GA12906@localhost.localdomain> References: <20050912043329.GA12906@localhost.localdomain> Message-ID: On 9/12/05, Doug Kearns wrote: > > I was just wondering if the rubyforge 'integration' works both ways. > Will a previously released file which has been deleted, from rubyforge, > also be deleted from the gems repository? As far as I know, the gems must be manually deleted from the gem repository. There is no automatic procedure that does that. -- -- -- 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20050912/5da581d0/attachment.htm From jim at weirichhouse.org Tue Sep 13 07:51:49 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Tue Sep 13 07:42:46 2005 Subject: [Rubygems-developers] Re: gem & require -> returns false? In-Reply-To: <64F88BD9-BA46-47EC-A99C-E6FA94AC1F82@segment7.net> References: <200509120111.49863.jim@weirichhouse.org> <64F88BD9-BA46-47EC-A99C-E6FA94AC1F82@segment7.net> Message-ID: <200509130751.50204.jim@weirichhouse.org> On Monday 12 September 2005 02:18 pm, Eric Hodel wrote: > $ cat x.rb > puts "rubygems: #{require 'rubygems'}" > puts "active_record: #{require 'active_record'}" > puts "required? #{defined? ActiveRecord}" > puts "RubyGemsVersion: #{Gem::RubyGemsVersion}" > $ ruby x.rb > rubygems: true > active_record: false > required? constant > RubyGemsVersion: 0.8.10 Thanks. I took a bit to figure out, but here's what is happening. Gem goes to load active_record and cannot find it, so it recognizes that there is an active_record file in a gem named 'activerecord'. It actives the gem with autorequire enabled. It then attempts to require the active_record file again, but since the gem was activated with autorequire, the file is already loaded by the activation step. Since it is already load, require returns false. We can fix this by turning off autorequire during the gem activation. I am tempted to do this, but want some testing time to make sure we don't break something else. > I also see this behavior when required files can't be loaded. > Sparklines requires RMagick, but if RMagick isn't available (I moved > it aside) then no LoadError is given. > > [11:16] drbrain@kaa$ irb > irb(main):001:0> require 'rubygems' > => true > irb(main):002:0> require 'sparklines' > => false > irb(main):003:0> Sparklines.plot([1,2]) > NameError: uninitialized constant Sparklines > from (irb):3 Hmmm ... surprisingly disabling autorequire fixes this behavior too. The original exception must not propagate out of the activation step. This confirms my long held belief that autorequire is evil. (I've CC'ed the rubygems list to make sure everyone there sees this as well). 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 jim at weirichhouse.org Tue Sep 13 08:10:37 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Tue Sep 13 08:01:27 2005 Subject: [Rubygems-developers] Re: gem & require -> returns false? In-Reply-To: <200509130751.50204.jim@weirichhouse.org> References: <64F88BD9-BA46-47EC-A99C-E6FA94AC1F82@segment7.net> <200509130751.50204.jim@weirichhouse.org> Message-ID: <200509130810.37241.jim@weirichhouse.org> On Tuesday 13 September 2005 07:51 am, Jim Weirich wrote: > Hmmm ... surprisingly disabling autorequire fixes this behavior too. The > original exception must not propagate out of the activation step. This > confirms my long held belief that autorequire is evil. > > (I've CC'ed the rubygems list to make sure everyone there sees this as > well). Just to followup to the gem devel list ... I've made a beta version of rubygems with autorequire disabled and would like people to install it and run with it for a while to make sure that doesn't break anything else. You can install the beta version 0.8.11.2 with the following: sudo gem update --system --source http://onestepback.org/betagems There are a couple of other changes in this version, see the ChangeLog file for details. However, I do want to point out that I removed the requirements for SSL when a signed gem is found. Now gem only requires SSL if the requested security policy requires /checking/ the signature. This allows folks with badly installed SSL libraries to still install signed gems. (The latest version of Rake is a signed gem) Ok, enough rambling. As always, report and problems with the beta gem here. Thanks. -- -- 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 Thu Sep 15 13:04:15 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 15 Sep 2005 18:04:15 +0100 (WEST) Subject: [Rubygems-developers] gem update -- Select which gem[...]18. Cancel Message-ID: I can't remmeber if I raised this before, but doing gem update I get Select which gem to install for your platform (sparc-solaris2.9) and get 17 choices for FXRuby, and 18. Cancel installation If I chose this gem install halts. I think there should be a 19. Skip update for this gem so the other gems which don't have prerequisites of the same kind can be dealt with. Hugh From rubygems-dev at whytheluckystiff.net Tue Sep 20 11:42:22 2005 From: rubygems-dev at whytheluckystiff.net (why the lucky stiff) Date: Tue, 20 Sep 2005 09:42:22 -0600 Subject: [Rubygems-developers] getting gems in the ruby dist Message-ID: <43302DDE.8000101@whytheluckystiff.net> Hey, everybody, team. Matz has given the OK to start checking RubyGems into the Ruby trunk. I'm afraid it's probably too late for 1.8.3 (which is due out today), but Matz has planned 1.8.4 for December. He loves dropping versions on Christmas, so I'll bet he sticks to his plan. Whatever the case, I think we're long overdue on this. How should we do this? Do you want to move your repository to Ruby CVS or stay where you are? Matz says either: "It's up to them. They can develop separatedly and check in their latests time to time, as you did for syck, or they can move their development on our repository." _why From chad at chadfowler.com Tue Sep 20 12:59:05 2005 From: chad at chadfowler.com (Chad Fowler) Date: Tue, 20 Sep 2005 12:59:05 -0400 Subject: [Rubygems-developers] getting gems in the ruby dist In-Reply-To: <43302DDE.8000101@whytheluckystiff.net> References: <43302DDE.8000101@whytheluckystiff.net> Message-ID: <89D519E4-5704-4A3D-80AA-3BA710DF3259@chadfowler.com> On 20-Sep-05, at 11:42 AM, why the lucky stiff wrote: > Hey, everybody, team. Matz has given the OK to start checking > RubyGems > into the Ruby trunk. I'm afraid it's probably too late for 1.8.3 > (which > is due out today), but Matz has planned 1.8.4 for December. He loves > dropping versions on Christmas, so I'll bet he sticks to his plan. > Whatever the case, I think we're long overdue on this. > > How should we do this? Do you want to move your repository to Ruby > CVS > or stay where you are? > > Matz says either: "It's up to them. They can develop separatedly and > check in their latests time to time, as you did for syck, or they can > move their development on our repository." Fantastic news! Thanks Why! Where did this conversation take place? I haven't been following -core lately, and since I haven't been committing I didn't get a basecamp account set up. What do the other RubyGems people think about where we should host the code? I'm thinking Ruby's CVS would be good in some ways and bad in others. Most notably, I bet we'll still want to make independent faster-than-ruby-core releases, and i"m not sure of the best way to setup such a structure in Ruby's CVS. Chad From rubygems-dev at whytheluckystiff.net Tue Sep 20 13:07:39 2005 From: rubygems-dev at whytheluckystiff.net (why the lucky stiff) Date: Tue, 20 Sep 2005 11:07:39 -0600 Subject: [Rubygems-developers] getting gems in the ruby dist In-Reply-To: <89D519E4-5704-4A3D-80AA-3BA710DF3259@chadfowler.com> References: <43302DDE.8000101@whytheluckystiff.net> <89D519E4-5704-4A3D-80AA-3BA710DF3259@chadfowler.com> Message-ID: <433041DB.3080806@whytheluckystiff.net> Chad Fowler wrote: > Fantastic news! Thanks Why! Where did this conversation take place? I > haven't been following -core lately, and since I haven't been > committing I didn't get a basecamp account set up. We are passing messages in Basecamp. >Most notably, I bet we'll still want to make independent faster-than-ruby-core releases, and i"m not sure of the best way to setup such a structure in Ruby's CVS. > > Also, if you want to add new developers, you don't have to bug knu or shugo. I'm just using Rake to copy files. Rake modifies my source code to strip out 1.6-specific pragmas and move files into place. I like keeping the extension separate so updates are available to older Ruby versions. _why From chad at chadfowler.com Tue Sep 20 13:12:01 2005 From: chad at chadfowler.com (Chad Fowler) Date: Tue, 20 Sep 2005 13:12:01 -0400 Subject: [Rubygems-developers] getting gems in the ruby dist In-Reply-To: <433041DB.3080806@whytheluckystiff.net> References: <43302DDE.8000101@whytheluckystiff.net> <89D519E4-5704-4A3D-80AA-3BA710DF3259@chadfowler.com> <433041DB.3080806@whytheluckystiff.net> Message-ID: <0E0AC2C7-84F6-4A2B-A6AE-BEB3D7FE0177@chadfowler.com> On 20-Sep-05, at 1:07 PM, why the lucky stiff wrote: > Chad Fowler wrote: > > >> Fantastic news! Thanks Why! Where did this conversation take place? I >> haven't been following -core lately, and since I haven't been >> committing I didn't get a basecamp account set up. >> > > We are passing messages in Basecamp. > > >> Most notably, I bet we'll still want to make independent faster- >> than-ruby-core releases, and i"m not sure of the best way to setup >> such a structure in Ruby's CVS. >> >> >> > Also, if you want to add new developers, you don't have to bug knu > or shugo. > > I'm just using Rake to copy files. Rake modifies my source code to > strip out 1.6-specific pragmas and move files into place. I like > keeping the extension separate so updates are available to older Ruby > versions. > How often do you update ruby CVS? With every marked release of the "golden" copy? Thanks, Chad From rubygems-dev at whytheluckystiff.net Tue Sep 20 13:45:14 2005 From: rubygems-dev at whytheluckystiff.net (why the lucky stiff) Date: Tue, 20 Sep 2005 11:45:14 -0600 Subject: [Rubygems-developers] getting gems in the ruby dist In-Reply-To: <0E0AC2C7-84F6-4A2B-A6AE-BEB3D7FE0177@chadfowler.com> References: <43302DDE.8000101@whytheluckystiff.net> <89D519E4-5704-4A3D-80AA-3BA710DF3259@chadfowler.com> <433041DB.3080806@whytheluckystiff.net> <0E0AC2C7-84F6-4A2B-A6AE-BEB3D7FE0177@chadfowler.com> Message-ID: <43304AAA.2020801@whytheluckystiff.net> Chad Fowler wrote: > How often do you update ruby CVS? With every marked release of the > "golden" copy? Yeah, I try to keep HEAD and ruby_1_8 both walking lockstep with the Syck stable branch. A Rake recipe to clean out site_ruby would probably be useful as well. _why From halostatue at gmail.com Thu Sep 22 00:12:55 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Thu, 22 Sep 2005 00:12:55 -0400 Subject: [Rubygems-developers] RubyGems TODO In-Reply-To: <5040BBC0-4029-4A99-A7D9-D385C0420C5D@chadfowler.com> References: <4331E9DD.3000102@whytheluckystiff.net> <5040BBC0-4029-4A99-A7D9-D385C0420C5D@chadfowler.com> Message-ID: <9e7db91105092121124441c242@mail.gmail.com> Okay. I said in the main thread on ruby-core that I'm putting together a proposal for this. Here's the set of proposals. I would happily assist in the development of any of these, but I am completely swamped until after RubyConf. None of the problems are conceptually difficult and I believe that the model that we should encourage is that package maintainers should trust RubyGems to do its job properly, because it does its job a *lot* better than CPAN does (IMO). To be clear, I *do not* think that we should encourage the manual unpacking and installation of gems and that if repackagers do that, they're doing something that is contraindicated and they're hanging their users out to dry. This list, obviously, is my opinion. None of this eliminates other possible improvements already on this thread. 1. require_gem needs to go away. We still need a way of saying that gem foo-1.3.5 represents foo/bar version 1.3.5, but I believe that this can be done with modifications to Kernel#require to accept a version parameter. The drawback, of course, is that this means that the require code has to be smarter. Eliminating require_gem will also eliminate the auto_require feature, something I think I'm going to get rid of from my own gems moving forward in any case. 2. If require_gem is eliminated and replaced with activation (per earlier discussions, also #4 on Chad's -core list), then we can even get RPA-like "stable release suite" concepts, so that you can have a metagem (no different than a real gem) such that you might do: require 'gemreview/rails', '1.0.0' This could activate a series of gems related to Rails produced by the "gemreview" team. Activation would be the equivalent of locking a gem's path into $LOAD_PATH. The search order should be: manually activated gems site_ruby installed gems ruby-lib 3. Eliminate case-sensitivity. Having a Usage gem or a RedCloth gem is confusing. At the same time, I will also acknowledge that there's a mismatch between gem names (e.g., pdf-writer, color-tools) and what they provide (e.g., pdf/writer and color). There's got to be a better way to handle gem naming issues and mapping issues. This is, IMO, vital to #2. 4. DATADIR must be addressed. However, it must be addressed in a Ruby and RubyGems way. That is to say that I need something like $DATA_PATH as an equivalent for $LOAD_PATH, and I need versioning. Ruwiki includes its documentation as a read-only wiki that's installed with Ruwiki. It also has a version-specific default package. PDF::Writer needs this less, but I absolutely need a way -- in code -- that I can get a clean data directory that will work whether or not a package is installed as a gem. This is an opportunity to fix what I consider a Ruby problem. Also note that IMO, this is especially important on Win32, as what's in rbconfig MAY NOT be in the same place as when it was built. I don't think this is a huge issue, here, but it's still important. Unless the DATADIR solution is solved in a version-aware way, however, I will continue to package data relative to __FILE__, and I will continue to Not Care what this does to repackagers -- because I know what my application requires. 5. T.'s problem of detecting manual installation dependencies is a good one, and I'm not sure that there's a good answer. Ultimately, it's not a problem when *running*, but perhaps RubyGems should be a little more tolerant of missing gem dependencies. 6. Post-installation message capabilities. Let me give the user a message to see after they've installed the gem. 7. It might be useful to have a LICENCE field so that users could possibly develop installation policies (for those zealots who won't install anything that isn't GNU GPLed). 8. This is also not completely Gem related, but it would be nice, for extensions, to be able to detect where one's development environment might be on Windows. 9. External (e.g., non-Ruby) dependencies references would be useful. I'm thinking something like: spec.external_dependencies = { 'ImageMagick' => 'http://....' } 10. "Optional" dependencies. That is, things that aren't *required* to make the gem work, but can add additional functionality. This would apply to both gem dependencies (as Text::Format can use Text::Hyphen, but doesn't require it for basic operation) and external dependencies. 11. Architecture-dependent and architecture-independent directories. This is potentially a big shift in the way things work, as it goes out of the dir-per-gem-version style. Sort of. The current installation is something like: /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb /usr/local/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo/bar.so (This is approximate, nothing more. I don't have any compiled gems handy to verify). There's no reason that can't be changed to: /usr/share/lib/ruby/gems/1.8/gems/foogem-1.3/lib/foo.rb /usr/local/lib/ruby/i386-linux/gems/1.8/gems/lib/foo/bar.so or something like that. Up front, I don't really care HOW it's done. Since it will be in a predictable prefix location with a predictable path pattern, it shouldn't be significantly harder to remove on uninstall than the current dir-per-gem-version mechanism. In this way, RubyGems can help those who give a damn about FHS or LSB the tools they need to make things work while not forcing the rest of us who don't care to adapt to their particular neurosis. This would ideally require a "gem rebuild" command or something to force the arch-dependent stuff to be rebuilt. 12. Add the Rake support patch. (There's a patch available to allow Rake-driven extension builds.) Incomplete, but I think it's thorough and covers the current discussion. -austin From halostatue at gmail.com Thu Sep 22 10:02:27 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Thu, 22 Sep 2005 10:02:27 -0400 Subject: [Rubygems-developers] RubyGems TODO In-Reply-To: <9e7db91105092121124441c242@mail.gmail.com> References: <4331E9DD.3000102@whytheluckystiff.net> <5040BBC0-4029-4A99-A7D9-D385C0420C5D@chadfowler.com> <9e7db91105092121124441c242@mail.gmail.com> Message-ID: <9e7db9110509220702162dc32b@mail.gmail.com> On 9/22/05, Austin Ziegler wrote: > To be clear, I *do not* think that we should encourage the manual > unpacking and installation of gems and that if repackagers do that, > they're doing something that is contraindicated and they're hanging > their users out to dry. I think some people may have missed this point. This is an important point that I think cannot be ignored. Gems should be the preferred way of installing gem packages and other packaging systems should use and trust gems as much as is possible. New items: 13. Make it dead-simple EASY to have precompiled binary gems. This is also something that I believe will help repackagers. 14. Allow for a signed install. This is *not* the same as a signed gem, but could be used by repackagers to make it hard to uninstall a gem installed by an external packaging system. That is, you might do: gem install rails-0.13.0.gem --sign Then, to uninstall version 0.13.0, you have to do: gem uninstall rails --version 0.13.0 --sign -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From drbrain at segment7.net Thu Sep 22 20:38:37 2005 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 22 Sep 2005 17:38:37 -0700 Subject: [Rubygems-developers] Gems built on 1.8.3 fail to install using 1.8.2. Message-ID: <36085057-5E21-4A6D-AD35-4C871C2CBCF1@segment7.net> Something in YAML has changed, apparently, and rubygems on 1.8.2 can't parse the gemspec anymore. The source (gem building) machine is: $ uname -a Darwin kaa.coop.robotcoop.com 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh powerpc $ ruby -v ruby 1.8.3 (2005-09-21) [powerpc-darwin8.2.0] $ gem --version 0.8.11 The installing machine is: $ uname -a FreeBSD RUR-5.coop.robotcoop.com 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE- p1 #1: Tue May 17 12:34:03 PDT 2005 root at RUR-5.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR i386 $ ruby -v ruby 1.8.2 (2004-12-25) [i386-freebsd5] $ gem --version 0.8.11 Attempting to install the gem does this: $ sudo gem install rails_analyzer_tools-1.1.0.gem Attempting local installation of 'rails_analyzer_tools-1.1.0.gem' ERROR: Error installing gem rails_analyzer_tools-1.1.0.gem[.gem]: parse error on line 0, col 31: `!ruby/object:Gem::Specification ' The gem installs just fine when built from the 1.8.2 machine. A Rakefile using Rake 0.6.0 was used to generate the gem on both machines. (Slightly hacked to work around 1.8.3 breakage of Rake.) The two gems can be found here: http://segment7.net/temp/bad-rails_analyzer_tools-1.1.0.gem - 1.8.3 http://segment7.net/temp/good-rails_analyzer_tools-1.1.0.gem - 1.8.2 -- Eric Hodel - drbrain at segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 From drbrain at segment7.net Thu Sep 22 20:45:42 2005 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 22 Sep 2005 17:45:42 -0700 Subject: [Rubygems-developers] Gems built on 1.8.3 fail to install using 1.8.2. In-Reply-To: <36085057-5E21-4A6D-AD35-4C871C2CBCF1@segment7.net> References: <36085057-5E21-4A6D-AD35-4C871C2CBCF1@segment7.net> Message-ID: <4F17ABD5-1A18-493A-9AFF-D14B19939B0E@segment7.net> On 22 Sep 2005, at 17:38, Eric Hodel wrote: > Something in YAML has changed, apparently, and rubygems on 1.8.2 > can't parse the gemspec anymore. > > The source (gem building) machine is: > > $ uname -a > Darwin kaa.coop.robotcoop.com 8.2.0 Darwin Kernel Version 8.2.0: Fri > Jun 24 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power > Macintosh powerpc > $ ruby -v > ruby 1.8.3 (2005-09-21) [powerpc-darwin8.2.0] > $ gem --version > 0.8.11 > > The installing machine is: > > $ uname -a > FreeBSD RUR-5.coop.robotcoop.com 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE- > p1 #1: Tue May 17 12:34:03 PDT 2005 > root at RUR-5.coop.robotcoop.com:/usr/obj/usr/src/sys/RUR i386 > $ ruby -v > ruby 1.8.2 (2004-12-25) [i386-freebsd5] > $ gem --version > 0.8.11 > > Attempting to install the gem does this: > > $ sudo gem install rails_analyzer_tools-1.1.0.gem > Attempting local installation of 'rails_analyzer_tools-1.1.0.gem' > ERROR: Error installing gem rails_analyzer_tools-1.1.0.gem[.gem]: > parse error on line 0, col 31: `!ruby/object:Gem::Specification ' > > The gem installs just fine when built from the 1.8.2 machine. > > A Rakefile using Rake 0.6.0 was used to generate the gem on both > machines. (Slightly hacked to work around 1.8.3 breakage of Rake.) > > The two gems can be found here: > > http://segment7.net/temp/bad-rails_analyzer_tools-1.1.0.gem - 1.8.3 > http://segment7.net/temp/good-rails_analyzer_tools-1.1.0.gem - 1.8.2 Running the tests from Rubygems CVS gives one assertion, but I doubt it is related: $ rake (in /Users/drbrain/Work/cvs/rubygems/rubygems) Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.6.0/lib/rake/ rake_test_loader Started ........................................................................ ................................F....................................... ................................................................ Finished in 9.736798 seconds. 1) Failure: test_cache_is_properly_setup(TestIncrementalFetcher) [./test/ test_incremental_fetcher.rb:69]: <966> expected but was <950>. 208 tests, 864 assertions, 1 failures, 0 errors rake aborted! Command failed with status (1): [/usr/local/bin/ruby18 -Ilib "/usr/ local/li...] -- Eric Hodel - drbrain at segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 From jim at weirichhouse.org Fri Sep 23 00:21:48 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Fri, 23 Sep 2005 00:21:48 -0400 Subject: [Rubygems-developers] Gems built on 1.8.3 fail to install using 1.8.2. In-Reply-To: <4F17ABD5-1A18-493A-9AFF-D14B19939B0E@segment7.net> References: <36085057-5E21-4A6D-AD35-4C871C2CBCF1@segment7.net> <4F17ABD5-1A18-493A-9AFF-D14B19939B0E@segment7.net> Message-ID: <200509230021.48633.jim@weirichhouse.org> On Thursday 22 September 2005 08:45 pm, Eric Hodel wrote: > Running the tests from Rubygems CVS gives one assertion, but I doubt > it is related: > > $ rake > (in /Users/drbrain/Work/cvs/rubygems/rubygems) > Loaded suite /usr/local/lib/ruby/gems/1.8/gems/rake-0.6.0/lib/rake/ > rake_test_loader > Started > ........................................................................ > ................................F....................................... > ................................................................ > Finished in 9.736798 seconds. > > 1) Failure: > test_cache_is_properly_setup(TestIncrementalFetcher) [./test/ > test_incremental_fetcher.rb:69]: > <966> expected but was > <950>. Hmmm ... its related but not directly. The incremental fetcher is new code that implements an incremental download of the source index. Its not ready, nor is it in production, but that particular test is a check on the size of the expected yaml spec. Its now 16 bytes different. Interesting. I just got home and haven't had time to look at this any deeper yet. Sorry. -- -- Jim Weirich jim at 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 halostatue at gmail.com Fri Sep 23 09:00:07 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 23 Sep 2005 09:00:07 -0400 Subject: [Rubygems-developers] Repackaging vs RubyGems (RubyGems TODO) In-Reply-To: <007101c5c021$6b76d1d0$65d919ac@Whatever> References: <9e7db9110509220702162dc32b@mail.gmail.com> <007101c5c021$6b76d1d0$65d919ac@Whatever> Message-ID: <9e7db91105092306003be5e89b@mail.gmail.com> On 9/23/05, Warren Seltzer wrote: > Repackagers etc. need to support non-programming users of Ruby > software. Nothing I've said denies this. What I *have* said is that the Debian whinging has ignored the fact that Ruby (and therefore any packaging solution for Ruby) has to support far more than just the little Debian contingent out there. Frankly, if RubyGems were to pick just *one* repackaging platform to pick, it wouldn't be .deb -- it'd be RPM. Fortunately, the people who *are* developing RubyGems aren't platform bigots and realise that a packaging solution for Ruby needs to satisfy the same platforms that Ruby itself does, and that Ruby provides such a platform. Debian isn't the be-all-end-all of package management, and "relying" on Debian repackagers when all they're going to look out for is their users is a loser's game for the rest of Ruby's users and developers. My stance on this is very simple: RubyGems needs to make it easy to install packages in ways that continue to conform to the RubyGems multiple version solution while also making it easy to conform to a variety of configuration policies (e.g., the FHS neurosis). This will avoid the equivalent of DLL-hell or the neverending upgrade cycle on Debian et al. Repackagers, on the other hand, should *use* the RubyGems installer (like FreeBSD and Gentoo do) to actually install the .gem with the configuration parameters set up to satisfy their packaging systems' needs. This means allowing for separated arch-dependent and arch- independent installs as well as a standard *versioned* DATADIR solution. If the RubyGems team is going to add features to make DATADIR workable and separated installation targets, then they should be used and trusted to do their job properly. If repackagers *aren't* going to trust RubyGems to do its job right, then most of this discussion is, IMO, moot. The repackagers are right now asking for special features to help them with their jobs. I don't have a problem with special requests as long as they don't amount to per-platform special support -- the long list of features that I hvae said should be implemented to help this particular series of problems should clearly indicate that, even to the most zealous of Debian repackager. They've got to bend from their philosophies here. I've had people tell me that wrapping a .gem in a .deb isn't appropriate because Debian isn't a source-based distro, but these people aren't really thinking the problem through. RubyGems *already* supports the installation of precompiled binary gems. While it should be made a lot easier to create such precompiled gems, it is already possible to support a binary-based distro like Debian. I'm not against people who *want* to do: % apt-get rails I *am* against RubyGems making single-platform concessions to simply support apt-get while hanging the rest of the platforms out to dry -- including those without active repackaging efforts, or whose repackaging efforts don't go to the neurotic level of subpackages (which is what I generally consider RubyGems to be). Fortunately, I think it's safe to say that the RubyGems development team agrees that one-off platform support is a non-starter and that solutions for Ruby are cross-platform. I'll also add one more item: 15. Add the ability for RubyGems to communicate back with a system-level hook to say that a package was installed, removed, or updated so that other packaging systems can be informed of this fact. It will be up to the Debian team to provide the necessary hook implementation for Debian, etc. Not the RubyGems team. [...] > Think of all the employees in an insurance company or a call center > re-configuring their machines. Fortunately, it's usually the IT person that does that. > So IBM and MS and Sun and their corporate users all have tools and > policies to control configuration, and they aren't going to want to > learn RubyGems to do that. RubyGems is probably only for developers > and maybe power users. People providing toolsets to toddlers shouldn't > be giving them a hi-power buzz saw, they'll only cut off their feet > and start crying for Mommy. I'm not sure what this has to do with anything. Frankly, apt-get is a high-power buzz saw, too. -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From halostatue at gmail.com Fri Sep 23 14:59:29 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 23 Sep 2005 14:59:29 -0400 Subject: [Rubygems-developers] [BUG?] RubyGems $LOAD_PATH Alteration Message-ID: <9e7db91105092311597bd07005@mail.gmail.com> Guys, I just noticed that $LOAD_PATH does an unshift of discovered directories. I'm not sure this is a good thing. It seems to me that it should be appended or even spliced so that RubyGems results are *after* site_ruby but before stdlib. -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From jim at weirichhouse.org Fri Sep 23 16:12:37 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Fri, 23 Sep 2005 20:12:37 -0000 (UTC) Subject: [Rubygems-developers] [BUG?] RubyGems $LOAD_PATH Alteration In-Reply-To: <9e7db91105092311597bd07005@mail.gmail.com> References: <9e7db91105092311597bd07005@mail.gmail.com> Message-ID: <50823.192.223.163.6.1127506357.squirrel@weirichhouse.org> Austin Ziegler said: > Guys, > > I just noticed that $LOAD_PATH does an unshift of discovered > directories. I'm not sure this is a good thing. It seems to me that it > should be appended or even spliced so that RubyGems results are > *after* site_ruby but before stdlib. I disagree, but am will to hear different opinions. The current design allows site_ruby first crack at supplying a required file. If the file is there, great!, the fill is used from site-ruby. If the file is not there, then rubygems kicks in and activates a gem containing the missing file at the front of the search list. Putting it *after* site_ruby would allow old or partial installations in site-ruby (which are already known to be inadequate because the file was missing after all) to hide portions of a newly activated gem. -- -- Jim Weirich jim at 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 tilman at code-monkey.de Sun Sep 25 04:11:23 2005 From: tilman at code-monkey.de (Tilman Sauerbeck) Date: Sun, 25 Sep 2005 10:11:23 +0200 Subject: [Rubygems-developers] [PATCH] Support extensions built with rake In-Reply-To: <20050907211432.2b2007fd.tilman@code-monkey.de> References: <20050812135812.GA5828@code-monkey.de> <3FF6741F-6FD5-4B26-B0E6-622CF62F772E@chadfowler.com> <20050830215620.22432409.tilman@code-monkey.de> <20050830230621.4fe3add9.tilman@code-monkey.de> <20050907211432.2b2007fd.tilman@code-monkey.de> Message-ID: <20050925081121.GA5808@code-monkey.de> Tilman Sauerbeck [2005-09-07 21:14]: > [...] Chad discussed my last patch with me on IRC, and I fixed the issues he pointed out. * if make (for extconf-based extensions) or rake fail building the extension, the gem install process is aborted. * Always call the "extension" task for rake-based extensions. The "extension" task is supposed to build and install the extension, and clean up the build directory. I also changed how results are passed from the extension builder classes to the caller. If the extension builder raised an error, all of the log entries (results) were lost. Regards, Tilman -- learn to quote: http://www.netmeister.org/news/learn2quote.html -------------- next part -------------- diff -aur rubygems-0.8.11.orig/lib/rubygems/installer.rb rubygems-0.8.11/lib/rubygems/installer.rb --- rubygems-0.8.11.orig/lib/rubygems/installer.rb 2005-06-12 23:33:19.000000000 +0200 +++ rubygems-0.8.11/lib/rubygems/installer.rb 2005-09-25 09:45:37.000000000 +0200 @@ -284,29 +284,36 @@ say "Building native extensions. This could take a while..." start_dir = Dir.pwd dest_path = File.join(directory, spec.require_paths[0]) + ran_rake = false # only run rake once + spec.extensions.each do |extension| - Dir.chdir File.join(directory, File.dirname(extension)) - results = ["#{Gem.ruby} #{File.basename(extension)} #{ARGV.join(" ")}"] - results << `#{Gem.ruby} #{File.basename(extension)} #{ARGV.join(" ")}` - if File.exist?('Makefile') - mf = File.read('Makefile') - mf = mf.gsub(/^RUBYARCHDIR\s*=\s*\$.*/, "RUBYARCHDIR = #{dest_path}") - mf = mf.gsub(/^RUBYLIBDIR\s*=\s*\$.*/, "RUBYLIBDIR = #{dest_path}") - File.open('Makefile', 'wb') {|f| f.print mf} - make_program = ENV['make'] - unless make_program - make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make' - end - results << "#{make_program}" - results << `#{make_program}` - results << "#{make_program} install" - results << `#{make_program} install` - say results.join("\n") + break if ran_rake + results = [] + + if extension.match(/extconf/) + builder = ExtExtConfBuilder + elsif extension.match(/rakefile/i) + builder = ExtRakeBuilder + ran_rake = true else - File.open(File.join(Dir.pwd, 'gem_make.out'), 'wb') {|f| f.puts results.join("\n")} - raise "ERROR: Failed to build gem native extension.\nGem files will remain installed in #{directory} for inspection.\n #{results.join('\n')}\n\nResults logged to #{File.join(Dir.pwd, 'gem_make.out')}" + builder = nil + results = ["No builder for extension '#{extension}'"] + end + + begin + err = false + Dir.chdir File.join(directory, File.dirname(extension)) + builder.build(extension, directory, dest_path, results) + rescue + err = true end + + say results.join("\n") File.open('gem_make.out', 'wb') {|f| f.puts results.join("\n")} + + if err + raise "ERROR: Failed to build gem native extension.\nGem files will remain installed in #{directory} for inspection.\n #{results.join('\n')}\n\nResults logged to #{File.join(Dir.pwd, 'gem_make.out')}" + end end Dir.chdir start_dir end @@ -535,4 +542,43 @@ end # class Uninstaller + class ExtExtConfBuilder + def self.build(extension, directory, dest_path, results) + results << "#{Gem.ruby} #{File.basename(extension)} #{ARGV.join(" ")}" + results << `#{Gem.ruby} #{File.basename(extension)} #{ARGV.join(" ")}` + + raise unless File.exist?('Makefile') + mf = File.read('Makefile') + mf = mf.gsub(/^RUBYARCHDIR\s*=\s*\$.*/, "RUBYARCHDIR = #{dest_path}") + mf = mf.gsub(/^RUBYLIBDIR\s*=\s*\$.*/, "RUBYLIBDIR = #{dest_path}") + File.open('Makefile', 'wb') {|f| f.print mf} + + make_program = ENV['make'] + unless make_program + make_program = (/mswin/ =~ RUBY_PLATFORM) ? 'nmake' : 'make' + end + + ['', 'install', 'clean'].each do |target| + results << "#{make_program} #{target}".strip + results << `#{make_program} #{target}` + raise unless $?.exitstatus.zero? + end + + results + end + end + + class ExtRakeBuilder + def ExtRakeBuilder.build(ext, directory, dest_path, results) + make_program = ENV['rake'] || 'rake' + make_program += " RUBYARCHDIR=#{dest_path} RUBYLIBDIR=#{dest_path}" + + results << "#{make_program} extension".strip + results << `#{make_program} extension` + + raise unless $?.exitstatus.zero? + + results + end + end end # module Gem From jim at weirichhouse.org Sun Sep 25 23:21:44 2005 From: jim at weirichhouse.org (Jim Weirich) Date: Sun, 25 Sep 2005 23:21:44 -0400 Subject: [Rubygems-developers] Gems created in 1.8.3 Message-ID: <200509252321.44768.jim@weirichhouse.org> I've seen some reports of gems created in 1.8.3 not being readable in 1.8.2. Its been a crazy week at work this week for me and I haven't yet tried 1.8.3. Does someone have the straight skinny on this topic? Thanks. -- -- Jim Weirich jim at 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 halostatue at gmail.com Mon Sep 26 07:33:26 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 26 Sep 2005 07:33:26 -0400 Subject: [Rubygems-developers] Gems created in 1.8.3 In-Reply-To: <200509252321.44768.jim@weirichhouse.org> References: <200509252321.44768.jim@weirichhouse.org> Message-ID: <9e7db91105092604337604255e@mail.gmail.com> On 9/25/05, Jim Weirich wrote: > I've seen some reports of gems created in 1.8.3 not being readable in 1.8.2. > Its been a crazy week at work this week for me and I haven't yet tried 1.8.3. > Does someone have the straight skinny on this topic? Thanks. I haven't seen this, yet, but I'm dealing with bigger pre-RubyConf issues (like a DOA laptop :( -- however, it could be changes in YAML. -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From chad at chadfowler.com Mon Sep 26 08:54:42 2005 From: chad at chadfowler.com (Chad Fowler) Date: Mon, 26 Sep 2005 08:54:42 -0400 Subject: [Rubygems-developers] Gems created in 1.8.3 (YAML/Syck change?) In-Reply-To: <200509252321.44768.jim@weirichhouse.org> References: <200509252321.44768.jim@weirichhouse.org> Message-ID: On Sun, 25 Sep 2005 23:21:44 -0400, Jim Weirich wrote: > I've seen some reports of gems created in 1.8.3 not being readable in > 1.8.2. > Its been a crazy week at work this week for me and I haven't yet tried > 1.8.3. > Does someone have the straight skinny on this topic? Thanks. > I've been in a similar situation and haven't had time to look at it closely. Looking at the first lines of the specs that Eric provided, I see for the 1.8.2-created gem, --- !ruby/object:Gem::Specification and for the 1.8.3 created gem, !ruby/object:Gem::Specification There are various other YAML differences throughout the file. Looking at the CVS log for Syck in the ruby repository, it looks like Why has done a lot of refactoring of the YAML emitter in this release. Why, did you intend for the YAML produced to be incompatible with previous versions of Syck? Thanks, Chad From rubygems-dev at whytheluckystiff.net Mon Sep 26 15:40:04 2005 From: rubygems-dev at whytheluckystiff.net (why the lucky stiff) Date: Mon, 26 Sep 2005 13:40:04 -0600 Subject: [Rubygems-developers] Gems created in 1.8.3 (YAML/Syck change?) In-Reply-To: References: <200509252321.44768.jim@weirichhouse.org> Message-ID: <43384E94.8060203@whytheluckystiff.net> Chad Fowler wrote: > Looking at the CVS log for Syck in the ruby repository, it looks like > Why has done a lot of > refactoring of the YAML emitter in this release. Why, did you intend > for the YAML produced to be incompatible with previous versions of Syck? No, I didn't. This is in Basecamp, I am due to repair this for 1.8.3.1/1.8.4, whichever comes next. The solution is to put the document separator "---\n" before the document. Blechh, this is such a stupid mistake, it makes me ill. I have a whole testing suite for round-tripping documents and crap like that. But it isn't rigged to test 1.8.3 <-> 1.8.2 <-> 1.8.3 kinds of compatibility testing. _why From mfp at acm.org Wed Sep 28 19:42:45 2005 From: mfp at acm.org (Mauricio =?iso-8859-1?Q?Fern=E1ndez?=) Date: Thu, 29 Sep 2005 01:42:45 +0200 Subject: [Rubygems-developers] TODO Message-ID: <20050928234245.GB22676@tux-chan> Hi, any news about the TODO? I'd appreciate any information regarding * what is finally going to be done * how it's going to happen --- any schedule? So far I've been asking Austin but he doesn't seem to know for sure either. Here follows a snippet of a message I sent to ruby-core with some references for your convenience: >_why proposed a list [ruby-core:5877] and further refined it in >[ruby-core:5950]; the latter incorporated items added by Chad Fowler >[ruby-core:5880] and Jim Weirich, who also prioritized them in >[ruby-core:5901], without specifying the sorting criteria, though. >Austin Ziegler created the so far most detailed list [ruby-core:5882]. >I tried to assign priorities to the latter based on the impact on >upstream code in [ruby-core:5890]. Unfortunately, the latter was largely >disregarded, but I'd appreciate constructive criticism. -- Mauricio Fernandez From chad at chadfowler.com Wed Sep 28 20:40:51 2005 From: chad at chadfowler.com (Chad Fowler) Date: Wed, 28 Sep 2005 20:40:51 -0400 Subject: [Rubygems-developers] TODO In-Reply-To: <20050928234245.GB22676@tux-chan> References: <20050928234245.GB22676@tux-chan> Message-ID: On Wed, 28 Sep 2005 19:42:45 -0400, Mauricio Fern?ndez wrote: > Hi, > > any news about the TODO? I'd appreciate any information regarding > * what is finally going to be done > * how it's going to happen --- any schedule? > Nothing yet. We are very busy and will remain so at least until RubyConf. Are you in a hurry? Chad From hgs at dmu.ac.uk Fri Sep 30 09:23:23 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 30 Sep 2005 14:23:23 +0100 (WEST) Subject: [Rubygems-developers] A ToDo list. Message-ID: I asked Chad if I could put together a TODO list on the wiki based on list traffic, and as I put it on Ruby-(Core|Talk): I have made an attempt to collect the main points people raised here: http://rubygarden.org/ruby?RubyGemsToDoList Which Chad Fowler agreed to me doing. The formatting is a bit iffy, threre is no attribution -- it can be added but I thought it wouldn't really help. The list is not prioritized in any way yet. As I'm not a developer of RubyGems though I try to provide useful input, I think it isn't my place to prioritize. Trying to get rid of invisible newlines is a nightmare. Anyway, if you and others could look at this and kick and beat it into shape, hopefully it will provide a useful focus for activity. HTH Hugh From eivind at FreeBSD.ORG Fri Sep 30 09:46:59 2005 From: eivind at FreeBSD.ORG (Eivind Eklund) Date: Fri, 30 Sep 2005 13:46:59 +0000 Subject: [Rubygems-developers] A ToDo list. In-Reply-To: References: Message-ID: <20050930134659.GA39400@FreeBSD.org> On Fri, Sep 30, 2005 at 02:23:23PM +0100, Hugh Sasse wrote: > I asked Chad if I could put together a TODO list on the wiki based > on list traffic, and as I put it on Ruby-(Core|Talk): > > I have made an attempt to collect the main points people raised > here: > > http://rubygarden.org/ruby?RubyGemsToDoList This links gives an empty (new) wiki page. I tried some capitalization changes and found nothing. Eivind. From hgs at dmu.ac.uk Fri Sep 30 09:55:43 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 30 Sep 2005 14:55:43 +0100 (WEST) Subject: [Rubygems-developers] A ToDo list. In-Reply-To: <20050930134659.GA39400@FreeBSD.org> References: <20050930134659.GA39400@FreeBSD.org> Message-ID: On Fri, 30 Sep 2005, Eivind Eklund wrote: > On Fri, Sep 30, 2005 at 02:23:23PM +0100, Hugh Sasse wrote: >> http://rubygarden.org/ruby?RubyGemsToDoList > > This links gives an empty (new) wiki page. I tried some > capitalization changes and found nothing. I copied it from my browser (firefox 1.0.7, Win98) http://rubygarden.org/ruby?RubyGemsToDoList And the Search box finds it ok for me if I prune that down to: http://rubygarden.org/ruby? and search for RubyGemsToDoList So, in short, I don't know why you're having these problems. Proxies? Caching? Hugh From halostatue at gmail.com Fri Sep 30 10:03:19 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 30 Sep 2005 10:03:19 -0400 Subject: [Rubygems-developers] A ToDo list. In-Reply-To: <20050930134659.GA39400@FreeBSD.org> References: <20050930134659.GA39400@FreeBSD.org> Message-ID: <9e7db9110509300703s7a83f665va72a3e814fb0805d@mail.gmail.com> On 9/30/05, Eivind Eklund wrote: > On Fri, Sep 30, 2005 at 02:23:23PM +0100, Hugh Sasse wrote: > > I asked Chad if I could put together a TODO list on the wiki based > > on list traffic, and as I put it on Ruby-(Core|Talk): > > > > I have made an attempt to collect the main points people raised > > here: > > > > http://rubygarden.org/ruby?RubyGemsToDoList > > This links gives an empty (new) wiki page. I tried some > capitalization changes and found nothing. Make sure you're not in the RubyGarden tarpit. If the home page says RUBY in the title, you're in the tarpit. Log in and you should get out of the tarpit. -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From eivind at FreeBSD.ORG Fri Sep 30 10:18:18 2005 From: eivind at FreeBSD.ORG (Eivind Eklund) Date: Fri, 30 Sep 2005 14:18:18 +0000 Subject: [Rubygems-developers] A ToDo list. In-Reply-To: <9e7db9110509300703s7a83f665va72a3e814fb0805d@mail.gmail.com> References: <20050930134659.GA39400@FreeBSD.org> <9e7db9110509300703s7a83f665va72a3e814fb0805d@mail.gmail.com> Message-ID: <20050930141818.GB39400@FreeBSD.org> On Fri, Sep 30, 2005 at 10:03:19AM -0400, Austin Ziegler wrote: > On 9/30/05, Eivind Eklund wrote: > > On Fri, Sep 30, 2005 at 02:23:23PM +0100, Hugh Sasse wrote: > > > I asked Chad if I could put together a TODO list on the wiki based > > > on list traffic, and as I put it on Ruby-(Core|Talk): > > > > > > I have made an attempt to collect the main points people raised > > > here: > > > > > > http://rubygarden.org/ruby?RubyGemsToDoList > > > > This links gives an empty (new) wiki page. I tried some > > capitalization changes and found nothing. > > Make sure you're not in the RubyGarden tarpit. If the home page says > RUBY in the title, you're in the tarpit. Log in and you should get out > of the tarpit. That was it. Weird. Could it be because the NAT gateway I'm behind doesn't have a reverse lookup? (I promise you, I've not been spamming the Wiki - I actually deleted spam from it yesterday...) Eivind. From chad at chadfowler.com Fri Sep 30 10:29:34 2005 From: chad at chadfowler.com (Chad Fowler) Date: Fri, 30 Sep 2005 10:29:34 -0400 Subject: [Rubygems-developers] A ToDo list. In-Reply-To: <20050930141818.GB39400@FreeBSD.org> References: <20050930134659.GA39400@FreeBSD.org> <9e7db9110509300703s7a83f665va72a3e814fb0805d@mail.gmail.com> <20050930141818.GB39400@FreeBSD.org> Message-ID: On Fri, 30 Sep 2005 10:18:18 -0400, Eivind Eklund wrote: > On Fri, Sep 30, 2005 at 10:03:19AM -0400, Austin Ziegler wrote: >> On 9/30/05, Eivind Eklund wrote: >> > On Fri, Sep 30, 2005 at 02:23:23PM +0100, Hugh Sasse wrote: >> > > I asked Chad if I could put together a TODO list on the wiki based >> > > on list traffic, and as I put it on Ruby-(Core|Talk): >> > > >> > > I have made an attempt to collect the main points people raised >> > > here: >> > > >> > > http://rubygarden.org/ruby?RubyGemsToDoList >> > >> > This links gives an empty (new) wiki page. I tried some >> > capitalization changes and found nothing. >> >> Make sure you're not in the RubyGarden tarpit. If the home page says >> RUBY in the title, you're in the tarpit. Log in and you should get out >> of the tarpit. > > That was it. Weird. Could it be because the NAT gateway I'm behind > doesn't > have a reverse lookup? (I promise you, I've not been spamming the Wiki > - I > actually deleted spam from it yesterday...) > Good guess. That's exactly right. Thanks, Hugh! Chad From eivind at FreeBSD.ORG Fri Sep 30 11:30:42 2005 From: eivind at FreeBSD.ORG (Eivind Eklund) Date: Fri, 30 Sep 2005 15:30:42 +0000 Subject: [Rubygems-developers] A ToDo list. In-Reply-To: References: <20050930134659.GA39400@FreeBSD.org> <9e7db9110509300703s7a83f665va72a3e814fb0805d@mail.gmail.com> <20050930141818.GB39400@FreeBSD.org> Message-ID: <20050930153042.GC39400@FreeBSD.org> On Fri, Sep 30, 2005 at 10:29:34AM -0400, Chad Fowler wrote: > Thanks, Hugh! >From me, too - this is a good way of collecting the issues and generating high quality (usable) input. I've added a reference to the RPA collection of native packaging information, and a sentence to the point on the "More repackaging friendly" saying that as far as I know, the sum of the datadir and "create gem-setup.rb file" proposals would mostly solve this (as long as people used the datadir support instead of __FILE__ hacks, and the correct dirs were supported.) Eivind. From jpshack at gmail.com Fri Sep 30 12:23:45 2005 From: jpshack at gmail.com (John-Mason P. Shackelford) Date: Fri, 30 Sep 2005 11:23:45 -0500 Subject: [Rubygems-developers] ri support w/ gem rdoc install Message-ID: <83f770ff0509300923p272c2634w39ba2764191968b0@mail.gmail.com> I'd love to see gems offer an rdoc install that would support ri as well as rdoc since it would be very handy for ruby IDEs which use the ri data. It occurs to me that this may require a patch to both gems and ri. Have the ruby gems developers reached any conclusions about how they would like to see this implemented? -- John-Mason Shackelford Software Developer Pearson Educational Measurement 2510 North Dodge St. Iowa City, IA 52245 ph. 319-354-9200x6214 john-mason.shackelford at pearson.com http://pearsonedmeasurement.com From halostatue at gmail.com Fri Sep 30 12:26:41 2005 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 30 Sep 2005 12:26:41 -0400 Subject: [Rubygems-developers] ri support w/ gem rdoc install In-Reply-To: <83f770ff0509300923p272c2634w39ba2764191968b0@mail.gmail.com> References: <83f770ff0509300923p272c2634w39ba2764191968b0@mail.gmail.com> Message-ID: <9e7db9110509300926j44cc1613j5969b939749b55a8@mail.gmail.com> On 9/30/05, John-Mason P. Shackelford wrote: > I'd love to see gems offer an rdoc install that would support ri as > well as rdoc since it would be very handy for ruby IDEs which use the > ri data. It occurs to me that this may require a patch to both gems > and ri. Have the ruby gems developers reached any conclusions about > how they would like to see this implemented? This is mostly something where ri will probably need to be reengineered. Right now it's useful for single system-wide installs only. It doesn't update well. -austin -- Austin Ziegler * halostatue at gmail.com * Alternate: austin at halostatue.ca From chad at chadfowler.com Fri Sep 30 13:36:45 2005 From: chad at chadfowler.com (chad@chadfowler.com) Date: Fri, 30 Sep 2005 13:36:45 -0400 (EDT) Subject: [Rubygems-developers] ri support w/ gem rdoc install In-Reply-To: <9e7db9110509300926j44cc1613j5969b939749b55a8@mail.gmail.com> References: <83f770ff0509300923p272c2634w39ba2764191968b0@mail.gmail.com> <9e7db9110509300926j44cc1613j5969b939749b55a8@mail.gmail.com> Message-ID: <1888.12.223.42.166.1128101805.squirrel@12.223.42.166> > On 9/30/05, John-Mason P. Shackelford wrote: >> I'd love to see gems offer an rdoc install that would support ri as >> well as rdoc since it would be very handy for ruby IDEs which use the >> ri data. It occurs to me that this may require a patch to both gems >> and ri. Have the ruby gems developers reached any conclusions about >> how they would like to see this implemented? > > This is mostly something where ri will probably need to be > reengineered. Right now it's useful for single system-wide installs > only. It doesn't update well. > Actually Dave, Mauricio, and I exchanged a few emails some time back about how to handle this. It is true that the merge problem would exist (you couldn't uninstall ri documentation), but we did talk about putting in a new rdoc ri directory for holding the ri data for packaging systems. The patch would be trivial on both sides, actually. It probably makes sense to do this with the inclusion of RubyGems with ruby 1.8.4. Chad