From drbrain at segment7.net Mon Oct 1 03:32:06 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 1 Oct 2007 00:32:06 -0700 Subject: [Rubygems-developers] Questions about Gem Platform Matching In-Reply-To: <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com> <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com> <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com> <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com> <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net> <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> Message-ID: On Sep 30, 2007, at 08:38 , Luis Lavena wrote: >> Should we make this check in Gem::Platform.local and choose x86- >> mswin32-80 or x86-mswin32-60 (I think those are right) based on which >> one it is? >> > > This sounds good, since Ruby set the platform to mswin32_80 .. adding > -60 to the VC6 version sounds right. I modified your patch and committed this: -------------- next part -------------- A non-text attachment was scrubbed... Name: platform.rb.vc6.patch Type: application/octet-stream Size: 3140 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071001/be94161f/attachment-0001.obj -------------- next part -------------- Does it look right? (Next changelog commit will have proper credit, oops!) -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From listsub at twelve71.com Mon Oct 1 08:37:11 2007 From: listsub at twelve71.com (Alan C Francis) Date: Mon, 1 Oct 2007 13:37:11 +0100 Subject: [Rubygems-developers] Patch added. In-Reply-To: <0EFE6DA9-9E6E-482E-B00E-E6404D619BCA@segment7.net> References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com> <2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net> <223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com> <9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com> <11F9E65B-CB1F-4E03-BA65-DC3323D29001@twelve71.com> <0EFE6DA9-9E6E-482E-B00E-E6404D619BCA@segment7.net> Message-ID: <11C8DA7C-FB99-4B52-B070-41222FA6A18D@twelve71.com> > I decided to go the opposite way around, and use > Gem.configuration.update_sources instead of the hash-type access. It > would probably be better to remove the hash access going forward, > since it adds lots of complication and requires more manual > documentation. Great. Thanks! > Fixed, I'm dumb. Phew. Thought I'd hosed myself :-) Are the team open to patches which are more refactoring than new features ? I'd like to take a crack at tidying up the config_file and maybe local_remote_options. A. -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 1 Oct 2007, at 01:01, Eric Hodel wrote: > On Sep 29, 2007, at 23:44 , Alan C Francis wrote: >> >> >> I've added >> >> instance_variable_set("@#{key.to_sym}", value) if respond_to? >> key.to_sym >> >> to Gem::ConfigFile # []= >> >> Which seems to work on the command line. Unfortunately I can't >> seem to run the tests so can't verify I haven't broken anything :-) > > >> ------ >> >> Harpo:~/work/rubygems_trunk acf$ rake >> (in /Users/acf/work/rubygems_trunk) >> ./lib/rubygems/custom_require.rb:27:in `gem_original_require': ./ >> lib/rubygems/digest/md5.rb:16: syntax error, unexpected '.', >> expecting '\n' or ';' (SyntaxError) >> def Gem::MD5.md5(string) >> ^ > > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate > Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Mon Oct 1 10:53:58 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 1 Oct 2007 07:53:58 -0700 Subject: [Rubygems-developers] Patch added. In-Reply-To: <11C8DA7C-FB99-4B52-B070-41222FA6A18D@twelve71.com> References: <3423E221-D0C3-44AE-9F86-698DA88385EC@twelve71.com> <2D0FC98B-0562-4140-9763-74F262A4A6A4@segment7.net> <223B7AFD-2BBE-4CAC-A04C-714004A35D49@twelve71.com> <9E306CC7-D23B-4F07-8402-CDFE80EA3103@twelve71.com> <11F9E65B-CB1F-4E03-BA65-DC3323D29001@twelve71.com> <0EFE6DA9-9E6E-482E-B00E-E6404D619BCA@segment7.net> <11C8DA7C-FB99-4B52-B070-41222FA6A18D@twelve71.com> Message-ID: <26086666-F917-45AE-8B37-678A5541F0F2@segment7.net> On Oct 1, 2007, at 05:37 , Alan C Francis wrote: >> I decided to go the opposite way around, and use >> Gem.configuration.update_sources instead of the hash-type access. It >> would probably be better to remove the hash access going forward, >> since it adds lots of complication and requires more manual >> documentation. > > Great. Thanks! > >> Fixed, I'm dumb. > > Phew. Thought I'd hosed myself :-) > > Are the team open to patches which are more refactoring than new > features ? I'd like to take a crack at tidying up the config_file > and maybe local_remote_options. Yes, but I'd like to keep things stable until after RubyGems is merged into ruby 1.9. I think there's one more thing to go in before a beta release. There has been heavy refactoring in RubyGems in the last couple of releases, primarily driven by tinderbox, and I'm all for more. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Mon Oct 1 19:21:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 1 Oct 2007 20:21:02 -0300 Subject: [Rubygems-developers] Questions about Gem Platform Matching In-Reply-To: References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com> <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com> <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com> <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com> <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net> <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> Message-ID: <71166b3b0710011621m6df7a2f1l51d65d12c09257e9@mail.gmail.com> On 10/1/07, Eric Hodel wrote: > On Sep 30, 2007, at 08:38 , Luis Lavena wrote: > >> Should we make this check in Gem::Platform.local and choose x86- > >> mswin32-80 or x86-mswin32-60 (I think those are right) based on which > >> one it is? > >> > > > > This sounds good, since Ruby set the platform to mswin32_80 .. adding > > -60 to the VC6 version sounds right. > > I modified your patch and committed this: > > > Does it look right? > It seems, but no. The case matching msvcrt seems a bit odd, since a few test fails: 1) Failure: test_initialize(TestGemPlatform) [test/test_gem_platform.rb:66:in `test_initialize' test/test_gem_platform.rb:64:in `each' test/test_gem_platform.rb:64:in `test_initialize']: "i386-mswin32". <["x86", "mswin32", nil]> expected but was <["x86", "mswin32", "60"]>. 2) Failure: test_initialize_command_line(TestGemPlatform) [test/test_gem_platform.rb:75]: i386-mswin32. <["x86", "mswin32", nil]> expected but was <["x86", "mswin32", "60"]>. 3) Failure: test_initialize_mswin32_vc6(TestGemPlatform) [test/test_gem_platform.rb:92]: i386-mswin32 VC6. <["x86", "mswin32", "nil"]> expected but was <["x86", "mswin32", "60"]>. 4) Failure: test_to_s(TestGemPlatform) [test/test_gem_platform.rb:124]: <"x86-mswin32"> expected but was <"x86-mswin32-60">. I'm working on a up-to-date patch for this. so: RUBY_PLATFORM == 'i386-mswin32' should be ['x86', 'mswin32', '60'] (and nil seems valid too). RUBY_PLATFORM == 'i386-mswin32_80' should be ['x86', 'mswin32', '80'] > (Next changelog commit will have proper credit, oops!) No problem :-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 1 20:09:16 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 1 Oct 2007 21:09:16 -0300 Subject: [Rubygems-developers] Questions about Gem Platform Matching In-Reply-To: <71166b3b0710011621m6df7a2f1l51d65d12c09257e9@mail.gmail.com> References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com> <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com> <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com> <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com> <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net> <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> <71166b3b0710011621m6df7a2f1l51d65d12c09257e9@mail.gmail.com> Message-ID: <71166b3b0710011709h660cbac8n9a3f2fda20cd897d@mail.gmail.com> On 10/1/07, Luis Lavena wrote: > > I'm working on a up-to-date patch for this. > As we talk on #irc, this is the patch for this. I don't like the #self.local stuff... but with inline condition ( a == b ? true : false ) looks worse. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi -------------- next part -------------- A non-text attachment was scrubbed... Name: better-platform-matching-2.patch Type: application/octet-stream Size: 1949 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071001/e88f039a/attachment.obj From luislavena at gmail.com Mon Oct 1 20:11:27 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 1 Oct 2007 21:11:27 -0300 Subject: [Rubygems-developers] Questions about Gem Platform Matching In-Reply-To: <71166b3b0710011709h660cbac8n9a3f2fda20cd897d@mail.gmail.com> References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com> <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com> <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com> <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com> <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net> <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> <71166b3b0710011621m6df7a2f1l51d65d12c09257e9@mail.gmail.com> <71166b3b0710011709h660cbac8n9a3f2fda20cd897d@mail.gmail.com> Message-ID: <71166b3b0710011711p706bddd5u8d47f15e8fb992e1@mail.gmail.com> On 10/1/07, Luis Lavena wrote: > On 10/1/07, Luis Lavena wrote: > > > > I'm working on a up-to-date patch for this. > > > > As we talk on #irc, this is the patch for this. > > I don't like the #self.local stuff... but with inline condition ( a == > b ? true : false ) looks worse. > Forgot to mention: Gem that match new Gem::Platform.local will be 'x86-mswin32-60'... Current available gems will be compatible with that platform. Future gems using that local will not be compatible when Gem::Platform.local match 'x86-mswin32-80' (due version mismatch?) Guess that cover all the cases, except for old gems that lack the new Gem::Platform specification (odd cases as you said). Regards and hope this helps. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Tue Oct 2 03:39:13 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 2 Oct 2007 00:39:13 -0700 Subject: [Rubygems-developers] Questions about Gem Platform Matching In-Reply-To: <71166b3b0710011711p706bddd5u8d47f15e8fb992e1@mail.gmail.com> References: <71166b3b0709271839h5710f55cl754f877f797a38cd@mail.gmail.com> <71166b3b0709281640r75495af4sdadfd394fbbe5729@mail.gmail.com> <71166b3b0709281722g560b7ff2va82542526ffa6ca@mail.gmail.com> <71166b3b0709291537yddf4833jff3b25f449dd04f6@mail.gmail.com> <940EFC50-E6B0-4DFD-A666-CC60AA8A4D3F@segment7.net> <71166b3b0709300838jffa05e2rad5b1578e99f8893@mail.gmail.com> <71166b3b0710011621m6df7a2f1l51d65d12c09257e9@mail.gmail.com> <71166b3b0710011709h660cbac8n9a3f2fda20cd897d@mail.gmail.com> <71166b3b0710011711p706bddd5u8d47f15e8fb992e1@mail.gmail.com> Message-ID: On Oct 1, 2007, at 17:11 , Luis Lavena wrote: > On 10/1/07, Luis Lavena wrote: >> On 10/1/07, Luis Lavena wrote: >>> >>> I'm working on a up-to-date patch for this. >>> >> >> As we talk on #irc, this is the patch for this. >> >> I don't like the #self.local stuff... but with inline condition >> ( a == >> b ? true : false ) looks worse. >> > > Forgot to mention: > > Gem that match new Gem::Platform.local will be 'x86-mswin32-60'... > > Current available gems will be compatible with that platform. > > Future gems using that local will not be compatible when > Gem::Platform.local match 'x86-mswin32-80' (due version mismatch?) > > Guess that cover all the cases, except for old gems that lack the new > Gem::Platform specification (odd cases as you said). > > Regards and hope this helps. Yes, I think this the best we can do. I have set the new constant Gem::Platform::MSWIN32 to match VC6 also, so maybe this will help. Hopefully people will use CURRENT instead. Thanks for your help and time! -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From Daniel.Berger at qwest.com Fri Oct 5 10:19:16 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 5 Oct 2007 09:19:16 -0500 Subject: [Rubygems-developers] GC.start after "require 'rubygems'" Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E77@ITOMAE2KM01.AD.QINTRA.COM> Hi all, Just saw this, thought it might be of interest: http://blog.ra66i.org/archives/informatics/2007/10/05/calling-on-the-gc- after-rubygems/ Basically, the OP says that calling GC.start after require'ing rubygems saved a good amount of memory. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From drbrain at segment7.net Fri Oct 5 11:13:26 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 5 Oct 2007 08:13:26 -0700 Subject: [Rubygems-developers] GC.start after "require 'rubygems'" In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72E77@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72E77@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7A184BFC-1045-4CA0-B5B6-07AFFC8DA261@segment7.net> On Oct 5, 2007, at 07:19 , Berger, Daniel wrote: > Just saw this, thought it might be of interest: > > http://blog.ra66i.org/archives/informatics/2007/10/05/calling-on- > the-gc- > after-rubygems/ > > Basically, the OP says that calling GC.start after require'ing > rubygems > saved a good amount of memory. I've reduced the number of classes RubyGems loads at startup. No longer does require 'rubygems' load anything that won't be used by the custom require or the gem methods. On my platform I've got ruby using up 1.30M virgin, 3.23M after require 'rubygems', and 3.23M after the suggested GC.start. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From Daniel.Berger at qwest.com Fri Oct 5 11:14:57 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 5 Oct 2007 10:14:57 -0500 Subject: [Rubygems-developers] GC.start after "require 'rubygems'" In-Reply-To: <7A184BFC-1045-4CA0-B5B6-07AFFC8DA261@segment7.net> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72E78@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Eric Hodel > Sent: Friday, October 05, 2007 9:13 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] GC.start after "require 'rubygems'" > > > On Oct 5, 2007, at 07:19 , Berger, Daniel wrote: > > Just saw this, thought it might be of interest: > > > > http://blog.ra66i.org/archives/informatics/2007/10/05/calling-on- > > the-gc- > > after-rubygems/ > > > > Basically, the OP says that calling GC.start after require'ing > > rubygems > > saved a good amount of memory. > > I've reduced the number of classes RubyGems loads at startup. No > longer does require 'rubygems' load anything that won't be used by > the custom require or the gem methods. > > On my platform I've got ruby using up 1.30M virgin, 3.23M after > require 'rubygems', and 3.23M after the suggested GC.start. Excellent, good to know. :) Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From drbrain at segment7.net Fri Oct 5 13:32:30 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 5 Oct 2007 10:32:30 -0700 Subject: [Rubygems-developers] Beta time for real? Message-ID: Tom has installed the indexer for the latest checkout on RubyGems, so I think its time to ship a beta. I'd like all of you to bang on RubyGems, and if it looks solid we can ship a 0.9.4.5 beta early next week. After beta feedback we can ship 0.9.5. (RubyGems may go into ruby 1.9 independent of 0.9.5, depending upon time constraints.) -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From hgs at dmu.ac.uk Fri Oct 5 13:43:42 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 5 Oct 2007 18:43:42 +0100 (WEST) Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: Message-ID: On Fri, 5 Oct 2007, Eric Hodel wrote: > Tom has installed the indexer for the latest checkout on RubyGems, so > I think its time to ship a beta. Is the mem_inspect gem visible with the beta-to-be? [cf: gc thread on Ruby-core]. Thank you Hugh From drbrain at segment7.net Fri Oct 5 14:23:54 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 5 Oct 2007 11:23:54 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: Message-ID: <9B4BAEBE-552C-43A2-BADB-7F940DF0E424@segment7.net> On Oct 5, 2007, at 10:43 , Hugh Sasse wrote: > On Fri, 5 Oct 2007, Eric Hodel wrote: >> Tom has installed the indexer for the latest checkout on RubyGems, so >> I think its time to ship a beta. > > Is the mem_inspect gem visible with the beta-to-be? [cf: gc thread on > Ruby-core]. Yup. There may have been a related bug in RubyGems that Wilson Bilkovich found and fixed. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From transfire at gmail.com Sat Oct 6 10:54:05 2007 From: transfire at gmail.com (TRANS) Date: Sat, 6 Oct 2007 07:54:05 -0700 Subject: [Rubygems-developers] Order of require_paths Message-ID: <4b6f054f0710060754o6570b1a1o3e3f456deb7763d5@mail.gmail.com> Discoverd something today. The order in which libs are searched is in reverse of how they are given in the gemspce's require_paths attribute. I realize that order doesn't usually matter, but it can --I have a particular case in which it does. The reverse order seems unintutive. Thought I'd just bring that to light. Maybe it would be better to reverse it for a future version. T. From drbrain at segment7.net Sat Oct 6 15:42:38 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 6 Oct 2007 12:42:38 -0700 Subject: [Rubygems-developers] Order of require_paths In-Reply-To: <4b6f054f0710060754o6570b1a1o3e3f456deb7763d5@mail.gmail.com> References: <4b6f054f0710060754o6570b1a1o3e3f456deb7763d5@mail.gmail.com> Message-ID: <65E0950A-6DBC-4505-85AA-9E0072C1D285@segment7.net> On Oct 6, 2007, at 07:54 , TRANS wrote: > The order in which libs are searched is in reverse of how they are > given in the gemspce's require_paths attribute. I realize that order > doesn't usually matter, but it can --I have a particular case in which > it does. The reverse order seems unintutive. Thought I'd just bring > that to light. Maybe it would be better to reverse it for a future > version. By the same token, changing it may break gems that inadvertently depend on the order. I think it is best to leave it alone. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sat Oct 6 15:43:38 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 6 Oct 2007 12:43:38 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: Message-ID: On Oct 5, 2007, at 10:32 , Eric Hodel wrote: > Tom has installed the indexer for the latest checkout on RubyGems, so > I think its time to ship a beta. > > I'd like all of you to bang on RubyGems, and if it looks solid we can > ship a 0.9.4.5 beta early next week. > > After beta feedback we can ship 0.9.5. > > (RubyGems may go into ruby 1.9 independent of 0.9.5, depending upon > time constraints.) I am working on some speed improvements to loading the source_cache file. It is too slow now. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sun Oct 7 04:06:41 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 7 Oct 2007 01:06:41 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: Message-ID: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> On Oct 6, 2007, at 12:43 , Eric Hodel wrote: > On Oct 5, 2007, at 10:32 , Eric Hodel wrote: >> Tom has installed the indexer for the latest checkout on RubyGems, so >> I think its time to ship a beta. >> >> I'd like all of you to bang on RubyGems, and if it looks solid we can >> ship a 0.9.4.5 beta early next week. >> >> After beta feedback we can ship 0.9.5. >> >> (RubyGems may go into ruby 1.9 independent of 0.9.5, depending upon >> time constraints.) > > I am working on some speed improvements to loading the source_cache > file. It is too slow now. Ok, I made it 5x faster with revision 1433. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From transfire at gmail.com Sun Oct 7 10:16:59 2007 From: transfire at gmail.com (TRANS) Date: Sun, 7 Oct 2007 07:16:59 -0700 Subject: [Rubygems-developers] Order of require_paths In-Reply-To: <65E0950A-6DBC-4505-85AA-9E0072C1D285@segment7.net> References: <4b6f054f0710060754o6570b1a1o3e3f456deb7763d5@mail.gmail.com> <65E0950A-6DBC-4505-85AA-9E0072C1D285@segment7.net> Message-ID: <4b6f054f0710070716w372606a6g651607e6f6265803@mail.gmail.com> On 10/6/07, Eric Hodel wrote: > On Oct 6, 2007, at 07:54 , TRANS wrote: > > The order in which libs are searched is in reverse of how they are > > given in the gemspce's require_paths attribute. I realize that order > > doesn't usually matter, but it can --I have a particular case in which > > it does. The reverse order seems unintutive. Thought I'd just bring > > that to light. Maybe it would be better to reverse it for a future > > version. > > By the same token, changing it may break gems that inadvertently > depend on the order. I think it is best to leave it alone. Looks like the problem is worse than I thought. I reversed the order of my require paths and now my gem works on Windows systems but not Linux systems. It would appear that the order is dependent on the platform. T. From listsub at twelve71.com Wed Oct 10 03:00:06 2007 From: listsub at twelve71.com (Alan C Francis) Date: Wed, 10 Oct 2007 08:00:06 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: ..and yet... irb(main):001:0> require 'uri' => true irb(main):002:0> p URI.split("http://gems.rubyonrails.org/") ["http", nil, "gems.rubyonrails.org", nil, nil, "/", nil, nil, nil] => nil irb(main):003:0> A. -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 7 Oct 2007, at 09:06, Eric Hodel wrote: > > On Oct 6, 2007, at 12:43 , Eric Hodel wrote: > >> On Oct 5, 2007, at 10:32 , Eric Hodel wrote: >>> Tom has installed the indexer for the latest checkout on >>> RubyGems, so >>> I think its time to ship a beta. >>> >>> I'd like all of you to bang on RubyGems, and if it looks solid we >>> can >>> ship a 0.9.4.5 beta early next week. >>> >>> After beta feedback we can ship 0.9.5. >>> >>> (RubyGems may go into ruby 1.9 independent of 0.9.5, depending upon >>> time constraints.) >> >> I am working on some speed improvements to loading the source_cache >> file. It is too slow now. > > Ok, I made it 5x faster with revision 1433. > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate > Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From listsub at twelve71.com Wed Oct 10 02:54:57 2007 From: listsub at twelve71.com (Alan C Francis) Date: Wed, 10 Oct 2007 07:54:57 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: I've just done an svn up to 1488 and am seeing: Harpo:~ acf$ sudo gem install rails --backtrace --source http:// gems.rubyonrails.org/ ERROR: While executing gem ... (URI::InvalidURIError) bad URI(is not URI?): http://gems.rubyonrails.org/ /usr/local/lib/ruby/1.8/uri/common.rb:436:in `split' /usr/local/lib/ruby/1.8/uri/common.rb:485:in `parse' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:118:in `download' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:202:in `install' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:194:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:194:in `install' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:69:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:104:in `process_args' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:74:in `run' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb: 39:in `run' /usr/local/bin/gem:22 Harpo:~ acf$ Anyone getting the same ? A. -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 7 Oct 2007, at 09:06, Eric Hodel wrote: > > On Oct 6, 2007, at 12:43 , Eric Hodel wrote: > >> On Oct 5, 2007, at 10:32 , Eric Hodel wrote: >>> Tom has installed the indexer for the latest checkout on >>> RubyGems, so >>> I think its time to ship a beta. >>> >>> I'd like all of you to bang on RubyGems, and if it looks solid we >>> can >>> ship a 0.9.4.5 beta early next week. >>> >>> After beta feedback we can ship 0.9.5. >>> >>> (RubyGems may go into ruby 1.9 independent of 0.9.5, depending upon >>> time constraints.) >> >> I am working on some speed improvements to loading the source_cache >> file. It is too slow now. > > Ok, I made it 5x faster with revision 1433. > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate > Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Wed Oct 10 12:25:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 10 Oct 2007 09:25:50 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: On Oct 9, 2007, at 23:54 , Alan C Francis wrote: > I've just done an svn up to 1488 and am seeing: 1448? with the rubyforge move I'm two hours away from DNS pointing to the right box so I can svn up. I'm not seeing this with 1446 > Harpo:~ acf$ sudo gem install rails --backtrace --source http:// > gems.rubyonrails.org/ > ERROR: While executing gem ... (URI::InvalidURIError) > bad URI(is not URI?): http://gems.rubyonrails.org/ > /usr/local/lib/ruby/1.8/uri/common.rb:436:in `split' > /usr/local/lib/ruby/1.8/uri/common.rb:485:in `parse' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/ > dependency_installer.rb:118:in `download' Can I see the output of `gem env` ? -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Wed Oct 10 12:29:40 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 10 Oct 2007 09:29:40 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: On Oct 9, 2007, at 23:54 , Alan C Francis wrote: > I've just done an svn up to 1488 and am seeing: > > Harpo:~ acf$ sudo gem install rails --backtrace --source http:// > gems.rubyonrails.org/ > ERROR: While executing gem ... (URI::InvalidURIError) > bad URI(is not URI?): http://gems.rubyonrails.org/ > /usr/local/lib/ruby/1.8/uri/common.rb:436:in `split' > /usr/local/lib/ruby/1.8/uri/common.rb:485:in `parse' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/ > dependency_installer.rb:118:in `download' Should have looked first. Change that line to: source_uri = URI.parse source_uri unless URI::Generic === source_uri Let me know if that fixes. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From listsub at twelve71.com Wed Oct 10 15:13:26 2007 From: listsub at twelve71.com (Alan C Francis) Date: Wed, 10 Oct 2007 20:13:26 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: Hi Eric, It does. However... Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= 1.2.4.7794' Updating metadata for 6 gems from http://gems.rubyforge.org ...... complete ERROR: While executing gem ... (NoMethodError) undefined method `collect' for nil:NilClass Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= 1.2.4.7794' --backtrace ERROR: While executing gem ... (NoMethodError) undefined method `collect' for nil:NilClass /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 95:in `as_list' /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 90:in `to_s' /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 153:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 706:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb: 70:in `inject' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `inject' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:176:in `[]' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:176:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:175:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:175:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:172:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:172:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:81:in `initialize' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:67:in `new' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:67:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:104:in `process_args' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:74:in `run' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb: 39:in `run' /usr/local/bin/gem:22 -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 10 Oct 2007, at 17:29, Eric Hodel wrote: > source_uri = URI.parse source_uri unless URI::Generic === source_uri From listsub at twelve71.com Wed Oct 10 15:15:14 2007 From: listsub at twelve71.com (Alan C Francis) Date: Wed, 10 Oct 2007 20:15:14 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: <6458FF1E-1351-4B74-9FAB-D9E817C31B0C@twelve71.com> Apologies for just dumping stack traces on you and not doing any investigation...I'm typing in between baths, nappy changes and washing machine repair :-) A. -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 10 Oct 2007, at 17:29, Eric Hodel wrote: > source_uri = URI.parse source_uri unless URI::Generic === source_uri From drbrain at segment7.net Wed Oct 10 17:11:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 10 Oct 2007 14:11:05 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> Message-ID: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> On Oct 10, 2007, at 12:13 , Alan C Francis wrote: > It does. However... > > Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= > 1.2.4.7794' > Updating metadata for 6 gems from http://gems.rubyforge.org > ...... > complete > ERROR: While executing gem ... (NoMethodError) > undefined method `collect' for nil:NilClass > Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= > 1.2.4.7794' --backtrace > ERROR: While executing gem ... (NoMethodError) > undefined method `collect' for nil:NilClass > /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: > 95:in `as_list' > > [...] > > /usr/local/lib/ruby/site_ruby/1.8/rubygems/ > dependency_installer.rb:176:in `[]' I can't reproduce. Can you add: require 'yaml' y dep_spec above this line? I don't know if you changed this, but I ran your commands with: $ ruby -Ilib bin/gem sources *** CURRENT SOURCES *** http://gems.rubyforge.org -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From listsub at twelve71.com Wed Oct 10 17:31:23 2007 From: listsub at twelve71.com (Alan C Francis) Date: Wed, 10 Oct 2007 22:31:23 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> Message-ID: Hi Eric, I have done a ruby setup.rb so I'm running trunk as amy system gem now. Also, I've done gem sources --add http://gems.rubyonrails.org/ The version I specifed *does* exist on gems.rubyonrails.org/ Here's the output with the dep_spec dumped Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= 1.2.4.7794' --backtrace Updating metadata for 1 gems from http://gems.rubyforge.org . complete --- !ruby/object:Gem::Specification rubygems_version: 0.9.4.4 specification_version: 2 name: rake version: !ruby/object:Gem::Version ints: - 0 - 7 - 3 version: 0.7.3 date: 2007-04-20 05:00:00 +01:00 summary: Ruby based make-like utility. require_paths: - lib email: jim at weirichhouse.org homepage: http://rake.rubyforge.org rubyforge_project: rake description: Rake is a Make-like program implemented in Ruby. Tasks and dependencies are specified in standard Ruby syntax. autorequire: default_executable: bindir: bin has_rdoc: true required_ruby_version: !ruby/object:Gem::Requirement requirements: version: required_rubygems_version: !ruby/object:Gem::Requirement requirements: version: platform: ruby signing_key: cert_chain: [] post_install_message: authors: - Jim Weirich files: [] test_files: [] rdoc_options: [] extra_rdoc_files: [] executables: [] extensions: [] requirements: [] dependencies: [] ERROR: While executing gem ... (NoMethodError) undefined method `collect' for nil:NilClass /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 95:in `as_list' /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 90:in `to_s' /usr/local/lib/ruby/site_ruby/1.8/rubygems/requirement.rb: 153:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 706:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb: 27:in `inject' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `inject' /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb: 705:in `hash' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:178:in `[]' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:178:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:175:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:175:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:172:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:172:in `gather_dependencies' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ dependency_installer.rb:81:in `initialize' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:67:in `new' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:67:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `each' /usr/local/lib/ruby/site_ruby/1.8/rubygems/commands/ install_command.rb:65:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:104:in `process_args' /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:74:in `run' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb: 39:in `run' /usr/local/bin/gem:22 Harpo:~/work/rubygems_trunk acf$ -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ From drbrain at segment7.net Wed Oct 10 21:30:09 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 10 Oct 2007 18:30:09 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> Message-ID: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> On Oct 10, 2007, at 14:31 , Alan C Francis wrote: > Hi Eric, I have done a ruby setup.rb so I'm running trunk as amy > system gem now. > > Also, I've done gem sources --add http://gems.rubyonrails.org/ > > The version I specifed *does* exist on gems.rubyonrails.org/ > > Here's the output with the dep_spec dumped > > > Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= > 1.2.4.7794' --backtrace > Updating metadata for 1 gems from http://gems.rubyforge.org > . > complete > --- !ruby/object:Gem::Specification > [...] > required_ruby_version: !ruby/object:Gem::Requirement > requirements: > version: > required_rubygems_version: !ruby/object:Gem::Requirement > requirements: > version: Can you try gem sources -c and run again? It looks like these are all set in the index, but there was a bug that may have caused these to be nil'd out that was fixed a couple days ago. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From listsub at twelve71.com Thu Oct 11 01:56:17 2007 From: listsub at twelve71.com (Alan C Francis) Date: Thu, 11 Oct 2007 06:56:17 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> Message-ID: Hi Eric, sorry for the ping pong across timezones. I cleared the caches, then tried the install and gems reported it couldn't find that version. It definitely seems to be there...see the first item on the first line. It also has already been installed (via gem install rails --source http://gems.rubypnrails.org) Harpo:~/work/rubygems_trunk acf$ sudo gem sources -c Password: *** Removed user source cache *** *** Removed system source cache *** Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= 1.2.4.7794' --backtrace Bulk updating Gem source index for: http://gems.rubyforge.org Bulk updating Gem source index for: http://gems.rubyonrails.org/ ERROR: could not find rails locally or in a repository Harpo:~/work/rubygems_trunk acf$ gem list rails --remote *** REMOTE GEMS *** rails (1.2.4.7794, 1.2.4, 1.2.4, 1.2.3.7707, 1.2.3.7702, 1.2.3.7679, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 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) rails-app-installer (0.2.0, 0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.1.0) rails-toolkit (7.10.1, 0.0.6, 0.0.5, 0.0.4, 0.0.3, 0.0.2, 0.0.1) rails_analyzer_tools (1.4.0) rails_config_model_generator (1.1.0) rails_creator (0.5.2) rails_env (0.1.0) rails_extensions (1.0.0) rails_jumpstart (1.0.0) rails_product (0.6, 0.5) rails_sql_views (0.6.1, 0.6.0, 0.5.1, 0.5.0, 0.4.0, 0.3.0, 0.2.0, 0.1.0) railsbench (0.9.2, 0.9.1, 0.9.0, 0.8.4) RailsEditor (0.0.28, 0.0.27, 0.0.26, 0.0.25, 0.0.24, 0.0.23, 0.0.22, 0.0.21) railsmachine (0.1.2, 0.1.1, 0.1.0) RailsRemoteControl (1.0.0) -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 11 Oct 2007, at 02:30, Eric Hodel wrote: > On Oct 10, 2007, at 14:31 , Alan C Francis wrote: > >> Hi Eric, I have done a ruby setup.rb so I'm running trunk as amy >> system gem now. >> >> Also, I've done gem sources --add http://gems.rubyonrails.org/ >> >> The version I specifed *does* exist on gems.rubyonrails.org/ >> >> Here's the output with the dep_spec dumped >> >> >> Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= >> 1.2.4.7794' --backtrace >> Updating metadata for 1 gems from http://gems.rubyforge.org >> . >> complete >> --- !ruby/object:Gem::Specification > >> [...] > >> required_ruby_version: !ruby/object:Gem::Requirement >> requirements: >> version: >> required_rubygems_version: !ruby/object:Gem::Requirement >> requirements: >> version: > > Can you try gem sources -c and run again? It looks like these are > all set in the index, but there was a bug that may have caused these > to be nil'd out that was fixed a couple days ago. > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate > Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From a at k27.net Thu Oct 11 00:14:23 2007 From: a at k27.net (Alex Ostleitner) Date: Thu, 11 Oct 2007 06:14:23 +0200 Subject: [Rubygems-developers] manual installation of rubygems beta 0.9.4.3 Message-ID: As my 256MB VPS was swapping to death for hours (!) when attempting to install any gem (while bulk updating the source it was eating 300-350MB RAM), I attempted to install the beta gem as suggested by Jim Weirich in a post in this list some months ago: > I would like those who are experiencing memory problems to give the > beta version a try and report back. You can get the beta version using > (using sudo if necessary on your system): > > gem update --system --source http://onestepback.org/betagems > > Of course, if you are having problems due to memory, the above might > not work. You can download the update explicitly using the following > URL: > > http://onestepback.org/betagems/gems/rubygems-update-0.9.4.1.gem > > and then install locally. Never having installed a local gem before, I was a bit unsure how to do so, and tried a simple "sudo gem install rubygems- update-0.9.4.3.gem" from the folder I downloaded it to - which successfully installed it, but I was still sitting at 0.9.4. After a hint in #ruby-lang I found out that I needed to unpack the gem and then run "ruby setup.rb" to successfully update to 0.9.4.3. Probably most of you know this. I'm just mentioning it here so people might find it when googling for "gem memory problem". best wishes, alex From drbrain at segment7.net Thu Oct 11 03:59:39 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 11 Oct 2007 00:59:39 -0700 Subject: [Rubygems-developers] manual installation of rubygems beta 0.9.4.3 In-Reply-To: References: Message-ID: On Oct 10, 2007, at 21:14 , Alex Ostleitner wrote: > As my 256MB VPS was swapping to death for hours (!) when attempting > to install any gem (while bulk updating the source it was eating > 300-350MB RAM), I attempted to install the beta gem as suggested by > Jim Weirich in a post in this list some months ago: > >> I would like those who are experiencing memory problems to give the >> beta version a try and report back. You can get the beta version > using >> (using sudo if necessary on your system): >> >> gem update --system --source http://onestepback.org/betagems >> >> Of course, if you are having problems due to memory, the above might >> not work. You can download the update explicitly using the following >> URL: >> >> http://onestepback.org/betagems/gems/rubygems-update-0.9.4.1.gem >> >> and then install locally. > > Never having installed a local gem before, I was a bit unsure how to > do so, and tried a simple "sudo gem install rubygems- > update-0.9.4.3.gem" from the folder I downloaded it to - which > successfully installed it, but I was still sitting at 0.9.4. > > After a hint in #ruby-lang I found out that I needed to unpack the > gem and then run "ruby setup.rb" to successfully update to 0.9.4.3. update_rubygems is provided for this task. > Probably most of you know this. I'm just mentioning it here so people > might find it when googling for "gem memory problem". The memory problems should be largely fixed by trunk. There should be a beta this week. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Thu Oct 11 04:36:01 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 11 Oct 2007 01:36:01 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> Message-ID: <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> On Oct 10, 2007, at 22:56 , Alan C Francis wrote: > Hi Eric, sorry for the ping pong across timezones. > > I cleared the caches, then tried the install and gems reported it > couldn't find that version. It definitely seems to be there...see the > first item on the first line. It also has already been installed > (via gem install rails --source http://gems.rubypnrails.org) > > Harpo:~/work/rubygems_trunk acf$ sudo gem sources -c > Password: > *** Removed user source cache *** > *** Removed system source cache *** > Harpo:~/work/rubygems_trunk acf$ gem install rails --version '= > 1.2.4.7794' --backtrace > Bulk updating Gem source index for: http://gems.rubyforge.org > Bulk updating Gem source index for: http://gems.rubyonrails.org/ > ERROR: could not find rails locally or in a repository > Harpo:~/work/rubygems_trunk acf$ gem list rails --remote > > *** REMOTE GEMS *** > > rails (1.2.4.7794 Ok, I ran through those steps, and still didn't get a repro. Can you replace these lines in dependency_installer.rb (around 66): @dep = Gem::Dependency.new gem_name, version spec_and_sources = find_gems_with_sources(@dep).reverse with: @dep = Gem::Dependency.new gem_name, version p @dep spec_and_sources = find_gems_with_sources(@dep).reverse p spec_and_sources.map { |spec, uri| [spec.full_name, uri] } I see: $ ruby -Ilib bin/gem install rails --version '= 1.2.4.7794' #]], @version=nil>, @version_requirement=nil, @name="rails"> [["rails-1.2.4.7794", "http://gems.rubyonrails.org"]] ... -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From listsub at twelve71.com Thu Oct 11 18:14:04 2007 From: listsub at twelve71.com (Alan C Francis) Date: Thu, 11 Oct 2007 23:14:04 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> Message-ID: <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> Weird. First it didn't work, then I did a search, and then it did. I'm thinking maybe the update-sources stuff is a little too erratic for release ? Harpo:~/work/rubygems_trunk acf$ sudo gem install rails --version '= 1.2.4.7794' #]]>, @name="rails"> Bulk updating Gem source index for: http://gems.rubyforge.org Bulk updating Gem source index for: http://gems.rubyonrails.org/ [] ERROR: could not find rails locally or in a repository Harpo:~/work/rubygems_trunk acf$ gem list --remote *** REMOTE GEMS *** Updating metadata for 12 gems from http://gems.rubyforge.org ............ complete abstract (1.0.0) ackbar (0.1.1, 0.1.0) rails (1.2.4.7794, 1.2.4, 1.2.4, 1.2.3.7707, 1.2.3.7702, 1.2.3.7679, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 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) zoom (0.4.0, 0.3.0) zyps (0.5.2, 0.5.1, 0.4.1, 0.3.1, 0.2.1, 0.1.1) Harpo:~/work/rubygems_trunk acf$ gem search rails --remote *** REMOTE GEMS *** ajp-rails (0.1.0, 0.0.4, 0.0.3, 0.0.2, 0.0.1, 0.0.0) atlas_on_rails (0.1.0) ec2onrails (0.9.3) gemsonrails (0.7.0, 0.6.4, 0.6.3, 0.6.1, 0.6.0, 0.5.0, 0.4.4, 0.4.3, 0.4.2, 0.3.0, 0.2.0) odbc-rails (1.4, 1.3, 1.2) rails (1.2.4.7794, 1.2.4, 1.2.4, 1.2.3.7707, 1.2.3.7702, 1.2.3.7679, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.0, 0.14.4, 0.14.3, 0.14.2, 0.14.1, 0.13.1, 0.13.0, 0.12.1, 0.12.0, 0.11.1, 0.11.0, 0.10.1, 0.10.0, 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) rails-app-installer (0.2.0, 0.1.5, 0.1.4, 0.1.3, 0.1.2, 0.1.1, 0.1.0) rails-toolkit (7.10.1, 0.0.6, 0.0.5, 0.0.4, 0.0.3, 0.0.2, 0.0.1) rails_analyzer_tools (1.4.0) rails_config_model_generator (1.1.0) rails_creator (0.5.2) rails_env (0.1.0) rails_extensions (1.0.0) rails_jumpstart (1.0.0) rails_product (0.6, 0.5) rails_sql_views (0.6.1, 0.6.0, 0.5.1, 0.5.0, 0.4.0, 0.3.0, 0.2.0, 0.1.0) railsbench (0.9.2, 0.9.1, 0.9.0, 0.8.4) RailsEditor (0.0.28, 0.0.27, 0.0.26, 0.0.25, 0.0.24, 0.0.23, 0.0.22, 0.0.21) railsmachine (0.1.2, 0.1.1, 0.1.0) RailsRemoteControl (1.0.0) Harpo:~/work/rubygems_trunk acf$ sudo gem install rails --version '= 1.2.4.7794' #]]>, @name="rails"> [["rails-1.2.4.7794", "http://gems.rubyonrails.org/"]] Successfully installed rails-1.2.4.7794 1 gem installed Harpo:~/work/rubygems_trunk acf$ -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ On 11 Oct 2007, at 09:36, Eric Hodel wrote: > ruby -Ilib bin/gem install rails --version '= 1.2.4.7794' From drbrain at segment7.net Thu Oct 11 18:50:11 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 11 Oct 2007 15:50:11 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> References: <05673D94-430D-44AA-A81B-5671C8D3BA50@segment7.net> <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> Message-ID: <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> On Oct 11, 2007, at 15:14 , Alan C Francis wrote: > Weird. First it didn't work, then I did a search, and then it did. > I'm thinking maybe the update-sources stuff is a little too erratic > for release ? I fear it is an existing bug that hasn't yet been discovered. People are reporting "missing" gems with 0.9.4 with bulk updates of the YAML index with the same symptoms you are showing. I think it is ok to push a beta tonight, then. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Thu Oct 11 19:30:20 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 11 Oct 2007 20:30:20 -0300 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> References: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> Message-ID: <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> On 10/11/07, Eric Hodel wrote: > I fear it is an existing bug that hasn't yet been discovered. People > are reporting "missing" gems with 0.9.4 with bulk updates of the YAML > index with the same symptoms you are showing. > I've experienced that with 0.9.4 too. Not with the beta... seems odd. Sometimes requesting the install again works ok, sometimes I need to clear the cache... > I think it is ok to push a beta tonight, then. Yeah, I broad audience could be more helpful. I found also that unpacking certain kind of gems brake the Zlib package... which is now fixed in the trunk. Could be possible add a "--debug" option to get the backtrace when "no gem NAME found" is shown? maybe that could provide us more information to pin-point the problem. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Thu Oct 11 20:29:26 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 11 Oct 2007 17:29:26 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> References: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> Message-ID: <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> On Oct 11, 2007, at 16:30 , Luis Lavena wrote: > On 10/11/07, Eric Hodel wrote: >> I fear it is an existing bug that hasn't yet been discovered. People >> are reporting "missing" gems with 0.9.4 with bulk updates of the YAML >> index with the same symptoms you are showing. > > I've experienced that with 0.9.4 too. Not with the beta... seems odd. > > Sometimes requesting the install again works ok, sometimes I need to > clear the cache... I think the new Marshal index hides it better. >> I think it is ok to push a beta tonight, then. > > Yeah, I broad audience could be more helpful. > > I found also that unpacking certain kind of gems brake the Zlib > package... which is now fixed in the trunk. > > Could be possible add a "--debug" option to get the backtrace when "no > gem NAME found" is shown? maybe that could provide us more information > to pin-point the problem. $ gem install --debug no_such_gem Exception `NameError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/ command_manager.rb:132 - uninitialized constant Gem::Commands::InstallCommand Exception `Gem::GemNotFoundException' at /usr/local/lib/ruby/ site_ruby/1.8/rubygems/dependency_installer.rb:75 - could not find no_such_gem locally or in a repository ERROR: could not find no_such_gem locally or in a repository Since the exception gets rescued, you don't get a backtrace, but this is good enough. I think I can find the error, but I don't think its worth delaying the beta for it. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Thu Oct 11 20:32:47 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 11 Oct 2007 21:32:47 -0300 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> References: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> Message-ID: <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> On 10/11/07, Eric Hodel wrote: > On Oct 11, 2007, at 16:30 , Luis Lavena wrote: > > Could be possible add a "--debug" option to get the backtrace when "no > > gem NAME found" is shown? maybe that could provide us more information > > to pin-point the problem. > > $ gem install --debug no_such_gem > Exception `NameError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/ > command_manager.rb:132 - uninitialized constant > Gem::Commands::InstallCommand > Exception `Gem::GemNotFoundException' at /usr/local/lib/ruby/ > site_ruby/1.8/rubygems/dependency_installer.rb:75 - could not find > no_such_gem locally or in a repository > ERROR: could not find no_such_gem locally or in a repository > > Since the exception gets rescued, you don't get a backtrace, but this > is good enough. I think I can find the error, but I don't think its > worth delaying the beta for it. > I thought about that, but don't have a ruby handy to try it ;-) Yeah, please roll out the beta so we could get more "in the field" information. I'll try to test building new mongrel gems for win32 with the beta and let you know. Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Fri Oct 12 00:15:17 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 11 Oct 2007 21:15:17 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> References: <7CAECC47-5BC8-459B-92F1-ECE6413AA4FA@segment7.net> <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> Message-ID: On Oct 11, 2007, at 17:32 , Luis Lavena wrote: > Yeah, please roll out the beta so we could get more "in the field" > information. > > I'll try to test building new mongrel gems for win32 with the beta and > let you know. Please change the platform to Gem::Platform::CURRENT when you do. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Fri Oct 12 00:19:29 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 12 Oct 2007 01:19:29 -0300 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> Message-ID: <71166b3b0710112119mb94aa3bmfef9315c527a8983@mail.gmail.com> On 10/12/07, Eric Hodel wrote: > On Oct 11, 2007, at 17:32 , Luis Lavena wrote: > > Yeah, please roll out the beta so we could get more "in the field" > > information. > > > > I'll try to test building new mongrel gems for win32 with the beta and > > let you know. > > Please change the platform to Gem::Platform::CURRENT when you do. > Yes, I'm aware of that. I don't know how that will affect building it on linux, since the binary extension will not be bundled. (Currently I'm using RUBY_PLATFORM =~ /mswin/ to include the precompiled gem and was making it WIN32...). I'll give it a whirl and let you know ;-) Thanks, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From Prashant.Srinivasan at sun.com Fri Oct 12 02:32:26 2007 From: Prashant.Srinivasan at sun.com (Prashant Srinivasan) Date: Thu, 11 Oct 2007 23:32:26 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. Message-ID: <470F14FA.3080002@Sun.COM> Hello Rubygems developers, I'm hoping to get rubygems bundled with the OpenSolaris OS, and have some questions about rubygems compatibility/stability etc., which I couldn't find direct answers to. Any thoughts/pointers are most appreciated. -> Are rubygems versions compatible with previous releases(or previous minor releases . . . or previous point releases)? -> are certain releases labeled "development releases". ie., like in Ruby? -> Does the integration into Ruby 1.9 mean that rubygems will follow the same concept of development and production releases that Ruby[3] does? -> Stability of the gem format is implied in [1]. Will the gem format be stable across a set of versions of rubygems? If yes, what's the range of versions across the format will remain stable? -> It seems that the repository format changed in an incompatible way, in a certain release[2]. This was worked around by having install.rb migrate the repository to the new format. I'm curious if other changes in the repository format are imminent . . . and if they are, are we planning to provide migration programs? Thanks, -ps [1] http://rubyforge.org/forum/forum.php?forum_id=2578 [2] http://rubyforge.org/pipermail/rubygems-developers/2004-March/000199.html [3] http://blogs.sun.com/prashant/entry/whats_a_stable_ruby_version From drbrain at segment7.net Fri Oct 12 11:05:40 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Oct 2007 08:05:40 -0700 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: <71166b3b0710112119mb94aa3bmfef9315c527a8983@mail.gmail.com> References: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> <71166b3b0710112119mb94aa3bmfef9315c527a8983@mail.gmail.com> Message-ID: On Oct 11, 2007, at 21:19 , Luis Lavena wrote: > On 10/12/07, Eric Hodel wrote: >> On Oct 11, 2007, at 17:32 , Luis Lavena wrote: >>> Yeah, please roll out the beta so we could get more "in the field" >>> information. >>> >>> I'll try to test building new mongrel gems for win32 with the >>> beta and >>> let you know. >> >> Please change the platform to Gem::Platform::CURRENT when you do. > > Yes, I'm aware of that. > > I don't know how that will affect building it on linux, since the > binary extension will not be bundled. When the binary extension is not being bundled, the platform should stay Gem::Platform::RUBY (the default). > (Currently I'm using RUBY_PLATFORM =~ /mswin/ to include the > precompiled gem and was making it WIN32...). > > I'll give it a whirl and let you know ;-) Cool. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Fri Oct 12 12:15:43 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Oct 2007 09:15:43 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. In-Reply-To: <470F14FA.3080002@Sun.COM> References: <470F14FA.3080002@Sun.COM> Message-ID: On Oct 11, 2007, at 23:32 , Prashant Srinivasan wrote: > I'm hoping to get rubygems bundled with the OpenSolaris OS, and have > some questions about rubygems compatibility/stability etc., which I > couldn't find direct answers to. Any thoughts/pointers are most > appreciated. Cool. I hope it will be possible for people to upgrade RubyGems upon new RubyGems releases. > -> Are rubygems versions compatible with previous releases(or previous > minor releases . . . or previous point releases)? We've made a best effort to keep RubyGems backwards and forwards compatible across all releases, but sometimes we've made mistakes. RubyGems versioning scheme seems nonexistent, so I don't know what the distinction has been between minor and teeny releases. Sometimes features become deprecated over the course of at least two releases before being removed. Kernel#require_gem has been deprecated, Time::today has been marked for deprecation, and will warn on the next release. > -> are certain releases labeled "development releases". ie., like > in Ruby? There are occasional beta releases, but there are never development releases like in Ruby. > -> Does the integration into Ruby 1.9 mean that rubygems will > follow the same concept of development and production releases > that Ruby[3] does? No. RubyGems may have releases independent of Ruby. Bundled RubyGems versions will not contain experimental features. > -> Stability of the gem format is implied in [1]. Will the gem format > be stable across a set of versions of rubygems? If yes, what's the > range of versions across the format will remain stable? There are no plans to change the format of gems. (Of course, there may be bugs.) > -> It seems that the repository format changed in an incompatible way, > in a certain release[2]. This was worked around by having install.rb > migrate the repository to the new format. I'm curious if other > changes > in the repository format are imminent . . . and if they are, are we > planning to provide migration programs? No repository format changes are planned. If any are necessary, we'll provide a migration tool. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From Prashant.Srinivasan at Sun.COM Fri Oct 12 13:23:15 2007 From: Prashant.Srinivasan at Sun.COM (Prashant Srinivasan) Date: Fri, 12 Oct 2007 10:23:15 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. In-Reply-To: References: <470F14FA.3080002@Sun.COM> Message-ID: <470FAD83.4040702@Sun.COM> Eric Hodel wrote: > On Oct 11, 2007, at 23:32 , Prashant Srinivasan wrote: > >> I'm hoping to get rubygems bundled with the OpenSolaris OS, and have >> some questions about rubygems compatibility/stability etc., which I >> couldn't find direct answers to. Any thoughts/pointers are most >> appreciated. >> > > Cool. I hope it will be possible for people to upgrade RubyGems upon > new RubyGems releases. > > Yes, that will be possible( and encouraged, since I'm the only volunteer at this time, and I'll probably be able to update the Solaris packages only occasionally). I'm proposing that OpenSolaris bundle the latest stable snapshot as it is. So the upgradeability will not be affected. The Gem repository location will be in /var/ruby. This is is to provide users of sparse root zones with rubygems, while giving them the ability to modify their local copy of the gem repository. (in a sparse root zone, /usr is read-only, since it's loopback mounted across different zones on the system. But /var is a file system that is local to each zone, and it's contents are replicated across zones). >> -> Are rubygems versions compatible with previous releases(or previous >> minor releases . . . or previous point releases)? >> > > We've made a best effort to keep RubyGems backwards and forwards > compatible across all releases, but sometimes we've made mistakes. > That makes it easy to package. > RubyGems versioning scheme seems nonexistent, so I don't know what > the distinction has been between minor and teeny releases. > > Sometimes features become deprecated over the course of at least two > releases before being removed. Just to verify, 2 releases here means two minor releases? Thanks, this makes things very clear. -ps -- Prashant Srinivasan F/OSS Enthusiast Sun Microsystems, Inc. http://blogs.sun.com/prashant GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A From Prashant.Srinivasan at Sun.COM Fri Oct 12 13:26:11 2007 From: Prashant.Srinivasan at Sun.COM (Prashant Srinivasan) Date: Fri, 12 Oct 2007 10:26:11 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. In-Reply-To: References: <470F14FA.3080002@Sun.COM> Message-ID: <470FAE33.4090200@Sun.COM> > No. RubyGems may have releases independent of Ruby. Bundled > RubyGems versions will not contain experimental features. > > Which versions of rubygems will have experimental features? Are such reserved for the beta versions, or will experimental features make it into teeny(or higher) releases as well? Thanks, -ps -- Prashant Srinivasan F/OSS Enthusiast Sun Microsystems, Inc. http://blogs.sun.com/prashant GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A From drbrain at segment7.net Fri Oct 12 14:59:51 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Oct 2007 11:59:51 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. In-Reply-To: <470FAD83.4040702@Sun.COM> References: <470F14FA.3080002@Sun.COM> <470FAD83.4040702@Sun.COM> Message-ID: <85B85B9A-C726-4729-9C41-998C2638A137@segment7.net> On Oct 12, 2007, at 10:23 , Prashant Srinivasan wrote: > Eric Hodel wrote: >> On Oct 11, 2007, at 23:32 , Prashant Srinivasan wrote: >>> I'm hoping to get rubygems bundled with the OpenSolaris OS, and >>> have >>> some questions about rubygems compatibility/stability etc., which I >>> couldn't find direct answers to. Any thoughts/pointers are most >>> appreciated. >> >> Cool. I hope it will be possible for people to upgrade RubyGems upon >> new RubyGems releases. > > Yes, that will be possible( and encouraged, since I'm the only > volunteer at this time, and I'll probably be able to update the > Solaris > packages only occasionally). > > I'm proposing that OpenSolaris bundle the latest stable snapshot > as it > is. So the upgradeability will not be affected. The Gem repository > location will be in /var/ruby. This is is to provide users of sparse > root zones with rubygems, while giving them the ability to modify > their > local copy of the gem repository. (in a sparse root zone, /usr is > read-only, since it's loopback mounted across different zones on the > system. But /var is a file system that is local to each zone, and > it's > contents are replicated across zones). Ok. RubyGems has a feature that may be helpful. Multiple gem repositories may be used if they are specified in GEM_PATH. >>> -> Are rubygems versions compatible with previous releases(or >>> previous minor releases . . . or previous point releases)? >> >> We've made a best effort to keep RubyGems backwards and forwards >> compatible across all releases, but sometimes we've made mistakes. > > That makes it easy to package. > >> RubyGems versioning scheme seems nonexistent, so I don't know what >> the distinction has been between minor and teeny releases. >> >> Sometimes features become deprecated over the course of at least two >> releases before being removed. > > Just to verify, 2 releases here means two minor releases? For the past several releases there has been no distinction between the minor and major releases in version numbers, so for now, deprecated features will exist for at least six months after being marked for deprecation. This should be at least two "minor" releases. I would like to move RubyGems to 1.0 and give it a sane versioning scheme. After that, two minor releases will be the minimum. Hopefully this will happen by year-end. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Fri Oct 12 15:00:44 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Oct 2007 12:00:44 -0700 Subject: [Rubygems-developers] rubygems compatibiilty and stability across releases. In-Reply-To: <470FAE33.4090200@Sun.COM> References: <470F14FA.3080002@Sun.COM> <470FAE33.4090200@Sun.COM> Message-ID: <09285491-188E-4B70-8E6C-E88A5F1D7EF7@segment7.net> On Oct 12, 2007, at 10:26 , Prashant Srinivasan wrote: >> No. RubyGems may have releases independent of Ruby. Bundled >> RubyGems versions will not contain experimental features. > > Which versions of rubygems will have experimental features? > Are such reserved for the beta versions, or will experimental features > make it into teeny(or higher) releases as well? Only beta versions will have experimental features. If the feature doesn't work out, another beta will be released with the feature fixed or removed. When the feature is working a full release will be made. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sat Oct 13 01:24:14 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Oct 2007 22:24:14 -0700 Subject: [Rubygems-developers] [ANN] RubyGems Beta 0.9.4.5 Message-ID: NOTE: If you recently installed RubyGems from trunk, the --source option may be broken. You can fetch the beta manually here: http://segment7.net/gems/rubygems-update-0.9.4.5.gem Then run: gem install rubygems-update-0.9.4.5.gem update_rubygems RubyGems 0.9.4.5 is a beta release for the upcoming 0.9.5 which adds several new features and fixes several bugs. To upgrade to the beta: gem update --system --source http://segment7.net/ To file bugs: http://rubyforge.org/tracker/?func=add&group_id=126&atid=575 When filing a bug, `gem env` output will be helpful in diagnosing the issue. If you find a bug where RubyGems crashes, please provide debug output. You can do that with `gem --debug the_command`. For example: $ gem --debug unknown_command Exception `RuntimeError' at [...]/rubygems/command_manager.rb:114 - Unknown command unknown_command ERROR: While executing gem ... (RuntimeError) Unknown command unknown_command [...]/rubygems/command_manager.rb:114:in `find_command' [...]/rubygems/command_manager.rb:103:in `process_args' [...]/rubygems/command_manager.rb:74:in `run' [...]/rubygems/gem_runner.rb:39:in `run' /usr/local/bin/gem:22 == Changes Select new features include: * Automatic installation of platform gems * New bandwidth and memory friendlier index file format * "Offline" mode (--no-update-sources) * Bulk update threshold can be specified (-B, --bulk-threshold) * New `gem fetch` command * `gem` now has "really verbose" output when you specify -v * Ruby 1.9 compatible Other changes include: * Time::today is deprecated and will be removed at a future date * `gem install --include-dependencies` (-y) is now deprecated since it is the default, use --ignore-dependencies to turn off automatic dependency installation * Multi-version diamond dependencies only are installed once * Processing a YAML bulk index update takes less memory * `gem install -i` makes sure all depenencies are installed * `gem update --system` reinstalls into the prefix it was originally installed in * `gem update --system` respects --no-rdoc and --no-ri flags * HTTP basic authentication support for proxies * Gem::Specification#platforms should no longer be a String, use Gem::Platform::CURRENT when building binary gems instead * `gem env` has more diagnostic information * require 'rubygems' loads less code * sources.gem is gone, RubyGems now uses built-in defaults * `gem install --source` will no longer add --source by default, use `gem sources --add` to make it a permanent extra source * `gem query` (list) no longer prints details by default * Exact gem names are matched in various places * mkrf extensions are now supported * A gem can depend on a specific RubyGems version * `gem_server` is now `gem server` * `gemlock` is now `gem lock` * `gem_mirror` is now `gem mirror` * `gemwhich` is now `gem which` * `gemri` is no longer included with RubyGems * `index_gem_repository.rb` is now `gem generate_index` * `gem` performs more validation of parameters * Custom rdoc styles are now supported * Gem indexer no longer removes quick index during index creation * Kernel#require only rescues a LoadError for the file being required now * `gem dependencies` can now display some information for remote gems Notes and issues: * Old gem scripts (gem_mirror, gem_server, gemlock, gemri, gemwhich, index_gem_repository.rb) are not cleaned up * There still appears to be a bug related to bulk updates of YAML indexes == Special Thanks * Daniel Berger for win32 testing of early betas * Luis Lavena for help with win32 platforms * Tom Copeland for help testing and releasing the new indexer * Wilson Bilkovich for the new index format * To the rest of the RubyGems bug reporters and patch contributors The full set of changes including contributors is included in the ChangeLog. == Platforms RubyGems now automatically handles platform gems. This means that `gem install` will no longer prompt for gem selection. RubyGems uses Ruby's built-in configuration to match the running ruby's platform to choose the correct gem to install. The automatically chosen platform may be overridden with the --platform option. The dependency, fetch, install, outdated, specification, uninstall and update commands all respond to --platform. For more information, see `gem help platforms` == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From djberg96 at gmail.com Sun Oct 14 04:37:40 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 14 Oct 2007 02:37:40 -0600 Subject: [Rubygems-developers] Problem with latest beta on Windows Message-ID: <4711D554.4030607@gmail.com> Hi, Ruby 1.8.6 one-click Windows XP I did: gem update --system --source http://segment7.net/ cp gem C:/DOCUME~1/djberge/LOCALS~1/Temp/gem install -c -m 0755 C:/DOCUME~1/djberge/LOCALS~1/Temp/gem C:/ruby/bin/gem rm C:/DOCUME~1/djberge/LOCALS~1/Temp/gem setup.rb:87: undefined method `win_platform?' for Gem:Module (NoMethodError) from setup.rb:69:in `each' from setup.rb:69 from setup.rb:66:in `chdir' from setup.rb:66 RubyGems system software updated I think it's toast: C:\Documents and Settings\djberge>gem -v C:/ruby/bin/gem.bat:24: uninitialized constant Gem::GemRunner (NameError) Not sure what the fix is, since Gem.win_platform? does actually exist. Regards, Dan From luislavena at gmail.com Sun Oct 14 15:41:56 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 14 Oct 2007 16:41:56 -0300 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <4711D554.4030607@gmail.com> References: <4711D554.4030607@gmail.com> Message-ID: <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> On 10/14/07, Daniel Berger wrote: > Hi, > > Ruby 1.8.6 one-click > Windows XP > > I did: gem update --system --source http://segment7.net/ > > cp gem C:/DOCUME~1/djberge/LOCALS~1/Temp/gem > install -c -m 0755 C:/DOCUME~1/djberge/LOCALS~1/Temp/gem C:/ruby/bin/gem > rm C:/DOCUME~1/djberge/LOCALS~1/Temp/gem > setup.rb:87: undefined method `win_platform?' for Gem:Module (NoMethodError) > from setup.rb:69:in `each' > from setup.rb:69 > from setup.rb:66:in `chdir' > from setup.rb:66 > RubyGems system software updated > > I think it's toast: > > C:\Documents and Settings\djberge>gem -v > C:/ruby/bin/gem.bat:24: uninitialized constant Gem::GemRunner (NameError) > > Not sure what the fix is, since Gem.win_platform? does actually exist. > I had problems with One-Click due the injecting of "gem" script inside the .cmd file. I updated succesfuly, but the generated .cmd file is broken: D:\Users\Developer>gem C:/Ruby/bin/ruby.exe: No such file or directory -- gem (LoadError) D:\Users\Developer>ruby c:\Ruby\bin\gem -v 0.9.4.5 The contents of the generated .cmd file: @"C:/Ruby/bin/ruby.exe" "gem" %1 %2 %3 %4 %5 %6 %7 %8 %9 Which is wrong, since "gem" will only be found if current directory (pwd) is C:/Ruby/bin I'll take a look at the repository and submit a patch for this. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From djberg96 at gmail.com Sun Oct 14 15:51:35 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sun, 14 Oct 2007 13:51:35 -0600 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> References: <4711D554.4030607@gmail.com> <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> Message-ID: <47127347.3000207@gmail.com> Luis Lavena wrote: > On 10/14/07, Daniel Berger wrote: >> Hi, >> >> Ruby 1.8.6 one-click >> Windows XP >> >> I did: gem update --system --source http://segment7.net/ >> >> cp gem C:/DOCUME~1/djberge/LOCALS~1/Temp/gem >> install -c -m 0755 C:/DOCUME~1/djberge/LOCALS~1/Temp/gem C:/ruby/bin/gem >> rm C:/DOCUME~1/djberge/LOCALS~1/Temp/gem >> setup.rb:87: undefined method `win_platform?' for Gem:Module (NoMethodError) >> from setup.rb:69:in `each' >> from setup.rb:69 >> from setup.rb:66:in `chdir' >> from setup.rb:66 >> RubyGems system software updated >> >> I think it's toast: >> >> C:\Documents and Settings\djberge>gem -v >> C:/ruby/bin/gem.bat:24: uninitialized constant Gem::GemRunner (NameError) >> >> Not sure what the fix is, since Gem.win_platform? does actually exist. >> > > I had problems with One-Click due the injecting of "gem" script inside > the .cmd file. > > I updated succesfuly, but the generated .cmd file is broken: > > D:\Users\Developer>gem > C:/Ruby/bin/ruby.exe: No such file or directory -- gem (LoadError) > > D:\Users\Developer>ruby c:\Ruby\bin\gem -v > 0.9.4.5 > > The contents of the generated .cmd file: > > @"C:/Ruby/bin/ruby.exe" "gem" %1 %2 %3 %4 %5 %6 %7 %8 %9 > > Which is wrong, since "gem" will only be found if current directory > (pwd) is C:/Ruby/bin > > I'll take a look at the repository and submit a patch for this. Actually, I fixed it by simply sticking "require 'rubygems/gem_runner'" at the top of rubygems.rb. But yeah, the drive letter issue should be handled as well. Regards, Dan From luislavena at gmail.com Sun Oct 14 16:33:31 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 14 Oct 2007 17:33:31 -0300 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <47127347.3000207@gmail.com> References: <4711D554.4030607@gmail.com> <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> <47127347.3000207@gmail.com> Message-ID: <71166b3b0710141333t2a6503f2y1da763c986677236@mail.gmail.com> On 10/14/07, Daniel Berger wrote: > Actually, I fixed it by simply sticking "require 'rubygems/gem_runner'" > at the top of rubygems.rb. But yeah, the drive letter issue should be > handled as well. > Question: we should care about Win9x users? I don't want, since I could use extensions only available in CMD.exe: @ECHO OFF IF NOT "%~f0" == "~f0" ECHO WinNT :WinNT ECHO.d0: %~d0 ECHO.p0: %~p0 ECHO.f0: %~f0 SET RUBYSCRIPT=%~f0 SET RUBYSCRIPT=%RUBYSCRIPT:.cmd=% ECHO.Command generated: ECHO."%~d0%~p0ruby.exe" "%RUBYSCRIPT%" %* SET RUBYSCRIPT= Just as example, Since I don't have an old command.com to test, this will work as stub for rubygems scripts. What do you think? Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Sun Oct 14 22:12:21 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 14 Oct 2007 19:12:21 -0700 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <4711D554.4030607@gmail.com> References: <4711D554.4030607@gmail.com> Message-ID: <9F554516-0DA8-47BA-A61D-115F7A6887C1@segment7.net> On Oct 14, 2007, at 01:37 , Daniel Berger wrote: > Hi, > > Ruby 1.8.6 one-click > Windows XP > > I did: gem update --system --source http://segment7.net/ > > cp gem C:/DOCUME~1/djberge/LOCALS~1/Temp/gem > install -c -m 0755 C:/DOCUME~1/djberge/LOCALS~1/Temp/gem C:/ruby/ > bin/gem > rm C:/DOCUME~1/djberge/LOCALS~1/Temp/gem > setup.rb:87: undefined method `win_platform?' for Gem:Module > (NoMethodError) > from setup.rb:69:in `each' > from setup.rb:69 > from setup.rb:66:in `chdir' > from setup.rb:66 > RubyGems system software updated > > I think it's toast: > > C:\Documents and Settings\djberge>gem -v > C:/ruby/bin/gem.bat:24: uninitialized constant Gem::GemRunner > (NameError) > > Not sure what the fix is, since Gem.win_platform? does actually exist. Does cmd.exe prefer .bat files over .cmd files? setup.rb installs 'gem.cmd', not 'gem.bat'... -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sun Oct 14 22:14:56 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 14 Oct 2007 19:14:56 -0700 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <71166b3b0710141333t2a6503f2y1da763c986677236@mail.gmail.com> References: <4711D554.4030607@gmail.com> <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> <47127347.3000207@gmail.com> <71166b3b0710141333t2a6503f2y1da763c986677236@mail.gmail.com> Message-ID: <9BFCA0B6-5316-4C33-A1A9-9DBE76DC8484@segment7.net> On Oct 14, 2007, at 13:33 , Luis Lavena wrote: > Question: we should care about Win9x users? I don't want, since I > could use extensions only available in CMD.exe: > > @ECHO OFF > IF NOT "%~f0" == "~f0" ECHO WinNT > :WinNT > ECHO.d0: %~d0 > ECHO.p0: %~p0 > ECHO.f0: %~f0 > SET RUBYSCRIPT=%~f0 > SET RUBYSCRIPT=%RUBYSCRIPT:.cmd=% > ECHO.Command generated: > ECHO."%~d0%~p0ruby.exe" "%RUBYSCRIPT%" %* > SET RUBYSCRIPT= > > Just as example, Since I don't have an old command.com to test, this > will work as stub for rubygems scripts. > > What do you think? Gem::Installer uses %*, and I'm told its not Win 9x. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Mon Oct 15 00:06:05 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 01:06:05 -0300 Subject: [Rubygems-developers] Problem with latest beta on Windows In-Reply-To: <9BFCA0B6-5316-4C33-A1A9-9DBE76DC8484@segment7.net> References: <4711D554.4030607@gmail.com> <71166b3b0710141241t22b6ca08n794635e79c36bb6@mail.gmail.com> <47127347.3000207@gmail.com> <71166b3b0710141333t2a6503f2y1da763c986677236@mail.gmail.com> <9BFCA0B6-5316-4C33-A1A9-9DBE76DC8484@segment7.net> Message-ID: <71166b3b0710142106y2369436fvf23f7dfab5aca84b@mail.gmail.com> On 10/14/07, Eric Hodel wrote: > > Gem::Installer uses %*, and I'm told its not Win 9x. Yeah, but the problem is the stub .cmd generated by RubyGems call C:\path\to\bin\ruby.exe with "gem" (note the pathless script name) I was working on a patch for installer.rb and setup.rb this afternoon, submitting in a while. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 15 03:01:27 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 04:01:27 -0300 Subject: [Rubygems-developers] Problems with mirrors Message-ID: <71166b3b0710150001i2dcb8036rfc2ed82fd66b2ec7@mail.gmail.com> Hello List, Found a problem checking the tests for the beta. First I must apologize for not correctly test this, was too focus on platform that ignored the other stuff. I have found what I commented before about creating my own local mirror for gems. Zlib problems... It seems that AbstractIndexBuilder#compress was reading the file 'as-is' and not forcing binary mode, like the other places. The following patch correct this, but raises other issues regarding OpenURI and proper support of Windows paths. I'll look further into this. http://pastie.caboo.se/107249 Again, sorry that I missed these things before RubyGems hit beta. Was overwhelmed due work. Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi -------------- next part -------------- A non-text attachment was scrubbed... Name: compressing-binary-data.diff Type: text/x-diff Size: 540 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071015/6d240cfc/attachment.bin From luislavena at gmail.com Mon Oct 15 03:51:29 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 04:51:29 -0300 Subject: [Rubygems-developers] Installing echoe end installing termios?!? Message-ID: <71166b3b0710150051i526a7599he421696748fcb44@mail.gmail.com> Hey Eric, It seems that somehow, installing one gem end trying to install other: gem install echoe... actually tries to install termios (which builds its extension and fails). And termios isn't part of echoe dependencies: s.add_dependency(%q, ["> 0.0.0"]) s.add_dependency(%q, [">= 0.4.3"]) s.add_dependency(%q, ["> 0.0.0"]) So something is broken here... or I just scr**ed my installation :-P -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Mon Oct 15 04:59:54 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 15 Oct 2007 01:59:54 -0700 Subject: [Rubygems-developers] Installing echoe end installing termios?!? In-Reply-To: <71166b3b0710150051i526a7599he421696748fcb44@mail.gmail.com> References: <71166b3b0710150051i526a7599he421696748fcb44@mail.gmail.com> Message-ID: On Oct 15, 2007, at 24:51 , Luis Lavena wrote: > It seems that somehow, installing one gem end trying to install other: > > gem install echoe... > > actually tries to install termios (which builds its extension and > fails). > > And termios isn't part of echoe dependencies: > > s.add_dependency(%q, ["> 0.0.0"]) > s.add_dependency(%q, [">= 0.4.3"]) > s.add_dependency(%q, ["> 0.0.0"]) > > So something is broken here... or I just scr**ed my installation :-P $ grep -l termios */Rakefile highline-0.6.0/Rakefile highline-0.6.1/Rakefile highline-1.0.0/Rakefile highline-1.0.1/Rakefile highline-1.0.2/Rakefile highline-1.0.4/Rakefile highline-1.2.0/Rakefile So its picking up a stale dependency. I think it OK to go to 0.9.5 with this bug. Could you file it in the tracker? -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Mon Oct 15 05:00:52 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 15 Oct 2007 02:00:52 -0700 Subject: [Rubygems-developers] Problems with mirrors In-Reply-To: <71166b3b0710150001i2dcb8036rfc2ed82fd66b2ec7@mail.gmail.com> References: <71166b3b0710150001i2dcb8036rfc2ed82fd66b2ec7@mail.gmail.com> Message-ID: <123CCFC1-3B91-4C05-A3C1-3D88945393F3@segment7.net> On Oct 15, 2007, at 24:01 , Luis Lavena wrote: > Found a problem checking the tests for the beta. > > First I must apologize for not correctly test this, was too focus on > platform that ignored the other stuff. > > I have found what I commented before about creating my own local > mirror for gems. Zlib problems... > > It seems that AbstractIndexBuilder#compress was reading the file > 'as-is' and not forcing binary mode, like the other places. > > The following patch correct this, but raises other issues regarding > OpenURI and proper support of Windows paths. What issues? > I'll look further into this. > > http://pastie.caboo.se/107249 > > Again, sorry that I missed these things before RubyGems hit beta. Was > overwhelmed due work. Its ok, I think 0.9.6 will quickly follow (relative to past releases). -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Mon Oct 15 05:09:57 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 06:09:57 -0300 Subject: [Rubygems-developers] Installing echoe end installing termios?!? In-Reply-To: References: <71166b3b0710150051i526a7599he421696748fcb44@mail.gmail.com> Message-ID: <71166b3b0710150209v13ab4e4bm34eb2c21e34def55@mail.gmail.com> On 10/15/07, Eric Hodel wrote: > On Oct 15, 2007, at 24:51 , Luis Lavena wrote: > > It seems that somehow, installing one gem end trying to install other: > > > > gem install echoe... > > > > actually tries to install termios (which builds its extension and > > fails). > > > > And termios isn't part of echoe dependencies: > > > > s.add_dependency(%q, ["> 0.0.0"]) > > s.add_dependency(%q, [">= 0.4.3"]) > > s.add_dependency(%q, ["> 0.0.0"]) > > > > So something is broken here... or I just scr**ed my installation :-P > > $ grep -l termios */Rakefile > highline-0.6.0/Rakefile > highline-0.6.1/Rakefile > highline-1.0.0/Rakefile > highline-1.0.1/Rakefile > highline-1.0.2/Rakefile > highline-1.0.4/Rakefile > highline-1.2.0/Rakefile > > So its picking up a stale dependency. I think it OK to go to 0.9.5 > with this bug. Could you file it in the tracker? > Err. I don't get it... Highline don't depend on termios. termios don't depend on highline. ... Why this raised? :-P I'll fill a bug report... -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 15 05:13:46 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 06:13:46 -0300 Subject: [Rubygems-developers] Problems with mirrors In-Reply-To: <123CCFC1-3B91-4C05-A3C1-3D88945393F3@segment7.net> References: <71166b3b0710150001i2dcb8036rfc2ed82fd66b2ec7@mail.gmail.com> <123CCFC1-3B91-4C05-A3C1-3D88945393F3@segment7.net> Message-ID: <71166b3b0710150213r12723236kc6123088fdf1033b@mail.gmail.com> On 10/15/07, Eric Hodel wrote: > On Oct 15, 2007, at 24:01 , Luis Lavena wrote: > > Found a problem checking the tests for the beta. > > > > First I must apologize for not correctly test this, was too focus on > > platform that ignored the other stuff. > > > > I have found what I commented before about creating my own local > > mirror for gems. Zlib problems... > > > > It seems that AbstractIndexBuilder#compress was reading the file > > 'as-is' and not forcing binary mode, like the other places. > > > > The following patch correct this, but raises other issues regarding > > OpenURI and proper support of Windows paths. > > What issues? > D:\Users\Developer\code\OpenSource\rubygems-trunk>ruby -w -Ilib;ext test\test_gem_commands_mirror_command.rb Loaded suite test/test_gem_commands_mirror_command Started E Finished in 4.75 seconds. 1) Error: test_execute(TestGemCommandsMirrorCommand): Errno::ENOENT: No such file or directory - //D/Temp/test_rubygems_3088/Marshal.4 .8.Z ./lib/rubygems/open-uri.rb:33:in `initialize' ./lib/rubygems/open-uri.rb:33:in `rubygems_open_uri_original_open' ./lib/rubygems/open-uri.rb:33:in `open' ./lib/rubygems/commands/mirror_command.rb:66:in `execute' ./lib/rubygems/commands/mirror_command.rb:36:in `each' ./lib/rubygems/commands/mirror_command.rb:36:in `execute' test/test_gem_commands_mirror_command.rb:42:in `test_execute' ./lib/rubygems/user_interaction.rb:45:in `use_ui' ./lib/rubygems/user_interaction.rb:27:in `use_ui' test/test_gem_commands_mirror_command.rb:41:in `test_execute' 1 tests, 0 assertions, 0 failures, 1 errors D:\Users\Developer\code\OpenSource\rubygems-trunk>echo %TEMP% D:\Temp Testing on different ruby version right now: D:\Users\Developer\code\OpenSource\rubygems-trunk>gem env RubyGems Environment: - RUBYGEMS VERSION: 0.9.4.5 (0.9.4.5) - RUBY VERSION: 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32] - INSTALLATION DIRECTORY: C:/Ruby/lib/ruby/gems/1.8 - RUBY EXECUTABLE: C:/Ruby/bin/ruby.exe - RUBYGEMS PLATFORMS: - ruby - x86-mswin32-60 - GEM PATHS: - C:/Ruby/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - REMOTE SOURCES: - http://gems.rubyforge.org OpenURI don't like Windows paths... I faced that problem when patching SVNauto. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 15 06:16:31 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 07:16:31 -0300 Subject: [Rubygems-developers] Is rubygems expecting sources > 0.0.1? Message-ID: <71166b3b0710150316g48ad09dasd4ab1c82ae5e8908@mail.gmail.com> Eric, This is annoying. When running with debug information on, found that rubygems.rb states: gem 'sources', '> 0.0.1' this shouldn't be '>= 0.0.1' since there aren't sources gem higher than 0.0.1, so it automatically revert to default sources. Anyway, collecting the patches I posted here and adding them to tracker. rake reports: 497 tests, 1683 assertions, 0 failures, 1 errors -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 15 06:59:25 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 07:59:25 -0300 Subject: [Rubygems-developers] Better stub scripts for Windows Message-ID: <71166b3b0710150359j3a74c2e1tb1d60d5ae01e8dec@mail.gmail.com> Hello List, The current and beta versions of RubyGems suffer from a location specific problem: Installing RubyGems (ruby setup.rb install) will mark the .cmd to a specific path (Gem.ruby) which will brake if user move the folder around (or during creation of installer like One-Click installer). Also, installing gems create stubs that call the same ruby executable (Gem.ruby) and the script "without path", which is broken (since it will try to locate "script" in the current directory). http://pastie.caboo.se/107250 This patch provides a "naive" solution to the problem, using the ruby installation where the stub is located, and also using the extension-less ruby script. As shown in the stub script, there is a door open to provide a workaround for win9x, but I didn't (since I commented on previous post: lack the installation to try it). Later, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi -------------- next part -------------- A non-text attachment was scrubbed... Name: locationless-stubs-for-windows.diff Type: text/x-diff Size: 1555 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071015/a0e2d975/attachment.bin From luislavena at gmail.com Mon Oct 15 06:59:42 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 15 Oct 2007 07:59:42 -0300 Subject: [Rubygems-developers] More organized pending patches. Message-ID: <71166b3b0710150359x66471313q2cb74f25a610dacd@mail.gmail.com> Hello List, Please excuse the noise, but took the time to submit the patches I made before to the tracker: More intelligent script stubs for Windows http://rubyforge.org/tracker/index.php?func=detail&aid=14725&group_id=126&atid=577 Patch non-binary file Index compression on Windows http://rubyforge.org/tracker/index.php?func=detail&aid=14726&group_id=126&atid=577 Correct Platform specification tests under Windows http://rubyforge.org/tracker/index.php?func=detail&aid=14727&group_id=126&atid=577 I'm still having problems with the OpenURI issue reported previously (this is due Path handling under Windows). I'll check my mail later to see if I could backport the changes I submitted to SVNauto to solve these issues. 1) Error: test_execute(TestGemCommandsMirrorCommand): Errno::ENOENT: No such file or directory - //D/Temp/test_rubygems_3632/Marshal.4 .8.Z ./lib/rubygems/open-uri.rb:33:in `initialize' ./lib/rubygems/open-uri.rb:33:in `rubygems_open_uri_original_open' ./lib/rubygems/open-uri.rb:33:in `open' ./lib/rubygems/commands/mirror_command.rb:66:in `execute' ./lib/rubygems/commands/mirror_command.rb:36:in `each' ./lib/rubygems/commands/mirror_command.rb:36:in `execute' test/test_gem_commands_mirror_command.rb:42:in `test_execute' ./lib/rubygems/user_interaction.rb:45:in `use_ui' ./lib/rubygems/user_interaction.rb:27:in `use_ui' test/test_gem_commands_mirror_command.rb:41:in `test_execute' 1 tests, 0 assertions, 0 failures, 1 errors -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From halostatue at gmail.com Mon Oct 15 09:10:06 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 15 Oct 2007 09:10:06 -0400 Subject: [Rubygems-developers] Better stub scripts for Windows In-Reply-To: <71166b3b0710150359j3a74c2e1tb1d60d5ae01e8dec@mail.gmail.com> References: <71166b3b0710150359j3a74c2e1tb1d60d5ae01e8dec@mail.gmail.com> Message-ID: <9e7db9110710150610r179e73b5lb7720c5dfbc7e3a7@mail.gmail.com> On 10/15/07, Luis Lavena wrote: > The current and beta versions of RubyGems suffer from a location > specific problem: > > Installing RubyGems (ruby setup.rb install) will mark the .cmd to a > specific path (Gem.ruby) which will brake if user move the folder > around (or during creation of installer like One-Click installer). > > Also, installing gems create stubs that call the same ruby executable > (Gem.ruby) and the script "without path", which is broken (since it > will try to locate "script" in the current directory). > > http://pastie.caboo.se/107250 > > This patch provides a "naive" solution to the problem, using the ruby > installation where the stub is located, and also using the > extension-less ruby script. > > As shown in the stub script, there is a door open to provide a > workaround for win9x, but I didn't (since I commented on previous > post: lack the installation to try it). This may sound callous, but if you're not running at least Win2k, you're not running a Windows worth worrying about. There's too many features missing from command.com to make for a viable Ruby installation for most people to use. (No PATHEXT, no FTYPE, only .bat and not .cmd.) It would also be pretty easy to substitute the appropriate values at install-time rather than relying on cmd.exe variable substitution tricks. -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From listsub at twelve71.com Mon Oct 15 14:34:51 2007 From: listsub at twelve71.com (Alan C Francis) Date: Mon, 15 Oct 2007 19:34:51 +0100 Subject: [Rubygems-developers] Beta time for real? In-Reply-To: References: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> <71166b3b0710112119mb94aa3bmfef9315c527a8983@mail.gmail.com> Message-ID: <45A109B2-F1CE-4CAD-B9BC-C765A330AA6E@twelve71.com> Harpo:~/work/rubygems_trunk acf$ gem_server /usr/local/lib/ruby/site_ruby/1.8/rubygems/server.rb:345:in `[]': Symbol as array index (TypeError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/server.rb: 345:in `run' from /usr/local/bin/gem_server:5 Hmmm server.run looks like: ----------8x----------------------- def self.run(options) new(options[:gemdir], options[:port], options[:daemon]).run end ----------8x----------------------- which aint going to work since it's passed ARGV by bin/gem_server. It used to look like: ----------8x----------------------- def self.process_args(args) options = {} options[:port] = 8808 options[:gemdir] = Gem.dir options[:daemon] = false opts = OptionParser.new do |opts| end def self.run(args = ARGV) options = process_args args new(options[:gemdir], options[:port], options[:daemon]).run end ----------8x----------------------- What happened ? A. -- http://www.alancfrancis.com/ http://www.cardboardsoftware.com/ http://www.scotlandonrails.com/ From drbrain at segment7.net Mon Oct 15 16:15:29 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 15 Oct 2007 13:15:29 -0700 Subject: [Rubygems-developers] Installing echoe end installing termios?!? In-Reply-To: <71166b3b0710150209v13ab4e4bm34eb2c21e34def55@mail.gmail.com> References: <71166b3b0710150051i526a7599he421696748fcb44@mail.gmail.com> <71166b3b0710150209v13ab4e4bm34eb2c21e34def55@mail.gmail.com> Message-ID: <99B27FE9-A2E2-427F-A65A-45713963EE39@segment7.net> On Oct 15, 2007, at 02:09 , Luis Lavena wrote: > On 10/15/07, Eric Hodel wrote: >> On Oct 15, 2007, at 24:51 , Luis Lavena wrote: >>> It seems that somehow, installing one gem end trying to install >>> other: >>> >>> gem install echoe... >>> >>> actually tries to install termios (which builds its extension and >>> fails). >>> >>> And termios isn't part of echoe dependencies: >>> >>> s.add_dependency(%q, ["> 0.0.0"]) >>> s.add_dependency(%q, [">= 0.4.3"]) >>> s.add_dependency(%q, ["> 0.0.0"]) >>> >>> So something is broken here... or I just scr**ed my installation :-P >> >> $ grep -l termios */Rakefile >> highline-0.6.0/Rakefile >> highline-0.6.1/Rakefile >> highline-1.0.0/Rakefile >> highline-1.0.1/Rakefile >> highline-1.0.2/Rakefile >> highline-1.0.4/Rakefile >> highline-1.2.0/Rakefile >> >> So its picking up a stale dependency. I think it OK to go to 0.9.5 >> with this bug. Could you file it in the tracker? >> > > Err. I don't get it... > > Highline don't depend on termios. > termios don't depend on highline. > > ... > > Why this raised? :-P > > I'll fill a bug report... In the past, highline depended upon termios. It doesn't any more. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Mon Oct 15 16:22:20 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 15 Oct 2007 13:22:20 -0700 Subject: [Rubygems-developers] Is rubygems expecting sources > 0.0.1? In-Reply-To: <71166b3b0710150316g48ad09dasd4ab1c82ae5e8908@mail.gmail.com> References: <71166b3b0710150316g48ad09dasd4ab1c82ae5e8908@mail.gmail.com> Message-ID: <3ED531C7-6E58-47A1-9BF8-09CDE30CF774@segment7.net> On Oct 15, 2007, at 03:16 , Luis Lavena wrote: > Eric, > > This is annoying. When running with debug information on, found that > rubygems.rb states: > > gem 'sources', '> 0.0.1' > > this shouldn't be '>= 0.0.1' since there aren't sources gem higher > than 0.0.1, so it automatically revert to default sources. No, this is how it was designed to work. RubyGems doesn't need a sources gem anymore, but if we need to change the sources, we can by releasing a new sources gem. I think its ok for debug information to be annoying. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Mon Oct 15 16:25:40 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 15 Oct 2007 13:25:40 -0700 Subject: [Rubygems-developers] Old gem* commands (Was: Beta time for real?) In-Reply-To: <45A109B2-F1CE-4CAD-B9BC-C765A330AA6E@twelve71.com> References: <5605AC1E-B9A3-47A4-9023-4693BF3883DE@segment7.net> <9FA8C3FE-20FE-4CE5-AC15-A0DB4B37D737@segment7.net> <0BD5657D-32A7-4AE9-BDE0-2B9DA2BDF08B@twelve71.com> <84D651CF-F8A2-4A84-A184-34045DD63540@segment7.net> <71166b3b0710111630k246ec065sc5b2480ad3c32f3f@mail.gmail.com> <715AB3E6-A5AB-4903-85D0-33E814847F9F@segment7.net> <71166b3b0710111732h58f538e4k15823e0335d50bb4@mail.gmail.com> <71166b3b0710112119mb94aa3bmfef9315c527a8983@mail.gmail.com> <45A109B2-F1CE-4CAD-B9BC-C765A330AA6E@twelve71.com> Message-ID: <00FB2B73-6B32-433D-A27C-50281E97AE60@segment7.net> On Oct 15, 2007, at 11:34 , Alan C Francis wrote: > Harpo:~/work/rubygems_trunk acf$ gem_server > /usr/local/lib/ruby/site_ruby/1.8/rubygems/server.rb:345:in `[]': > Symbol as array index (TypeError) > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/server.rb: > 345:in `run' > from /usr/local/bin/gem_server:5 > > Hmmm > > server.run looks like: > > [...] > > which aint going to work since it's passed ARGV by bin/gem_server. > > [...] > > What happened ? gem_server was moved to `gem server`. If it breaks, I guess setup.rb should clean up the old commands, or replace them with compatibility stubs that call the new ones and warn? I'm worried about all the documentation pointing to `gem_server` though... -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Wed Oct 17 00:02:49 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 17 Oct 2007 01:02:49 -0300 Subject: [Rubygems-developers] Simpler deprecation scripts? Message-ID: <71166b3b0710162102m692dd998w8be4dfb8eeb920db@mail.gmail.com> I know this is stupid, but I'm posting this anyway. I've attached a patch that creates the Windows stubs with just the deprecation message, since: 1) Was broken (call "script_name" without path/to/script don't work on windows). 2) Need launch ruby to just show the warning. The alternative just print it, and exit. As I said, it's stupid, but will make the deprecation be shown really. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi -------------- next part -------------- A non-text attachment was scrubbed... Name: simpler-deprecation-scripts.diff Type: text/x-diff Size: 749 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071017/e1e33c75/attachment.bin From drbrain at segment7.net Wed Oct 17 03:01:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Oct 2007 00:01:23 -0700 Subject: [Rubygems-developers] Simpler deprecation scripts? In-Reply-To: <71166b3b0710162102m692dd998w8be4dfb8eeb920db@mail.gmail.com> References: <71166b3b0710162102m692dd998w8be4dfb8eeb920db@mail.gmail.com> Message-ID: <7C571DFB-6235-43B7-8BC2-5F527DAA5A9D@segment7.net> On Oct 16, 2007, at 21:02 , Luis Lavena wrote: > I know this is stupid, but I'm posting this anyway. > > I've attached a patch that creates the Windows stubs with just the > deprecation message, since: > > 1) Was broken (call "script_name" without path/to/script don't work > on windows). > 2) Need launch ruby to just show the warning. > > The alternative just print it, and exit. > > As I said, it's stupid, but will make the deprecation be shown really. Great! Committed. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From han.holl at tietoenator.com Thu Oct 18 10:48:00 2007 From: han.holl at tietoenator.com (han.holl at tietoenator.com) Date: Thu, 18 Oct 2007 16:48:00 +0200 Subject: [Rubygems-developers] Gem update installs some gems twice Message-ID: <200710181648.00130.han.holl@tietoenator.com> Hi, I'm running 0.9.4.5, and did 'gem update'. Output attached. Note that actionpack, actionrecord and actionsupport are installed twice. This behaviour is not new, I've noticed it in the past as well. Also not that ERROR: While generating documentation for actionpack-1.13.5 only occurs when actionpack is installed for the second time. Cheers, Han Holl -------------- next part -------------- A non-text attachment was scrubbed... Name: gemupdate.log Type: text/x-log Size: 3368 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071018/dc882b61/attachment.bin From luislavena at gmail.com Thu Oct 18 18:12:48 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 18 Oct 2007 19:12:48 -0300 Subject: [Rubygems-developers] RubyGems on Win32: .bat and.cmd dilemma. Message-ID: <71166b3b0710181512t1618c3ffk74160775de8b686e@mail.gmail.com> Hi guys, I'm trying to do the final round of patches, and be less noisy about them. Please excuse if I added to you too much work on this. As Curt, Nobu, Eric and Daniel stressed on ruby-forum, ruby-talk and this list too, the use of .cmd files over .bat ones is a bit problematic. We have two kind of scripts stubs (the bat/cmd files that actually launch ruby with the script): - The ones set when rubygems is installed in your ruby installation (setup.rb) - The ones that rubygems create when installing/updating gems (installer.rb) Also, there are two problems with setup.rb and installer.rb: - The path to the ruby installation (Gem.ruby) is fixed. (That means you cannot relocate your ruby from c:/ruby to d:/ruby without requiring manually update all those .bat/.cmd files). - The pathless calling of the script: @"C:/Ruby/bin/ruby.exe" "gem" %* That is wrong... that only will work if current directory (pwd) is C:/Ruby/bin/ The patches I provided in the RubyForge tracker provide a solution for this, but I was using the .cmd extension for those file. Now, taking in consideration the comment from Eric at ruby-talk, those scripts should be .bat instead, since PATHEXT takes preference for them instead of .cmd ones: D:\Users\Developer\code>set PATHEXT PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH So, I'm about to provide the final round of patches to this topic, with the following considerations: - All the stub scripts generated by setup.rb and installer.rb will be .bat files. - The stubs will evaluate WinNT/Win9x scenario and use the extension power available in the NT platform or stick to a prefixed path for win9x. - Add more comments to the stubs generated and the methods defined for them. Any suggestion? objections? Thanks again for the opportunity and the openness to accept those patches into RubyGems. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From djberg96 at gmail.com Fri Oct 19 07:23:57 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 19 Oct 2007 05:23:57 -0600 Subject: [Rubygems-developers] Gems - binaries vs building from source Message-ID: <471893CD.6000507@gmail.com> Hi all, Ok, I've lost track. What's the "proper" way to distribute separate gems for MS Windows (or any platform really) where one is for users who want to build from source vs those who just want a prebuilt binary? I'm curious because for the win32-api library I have two gems - one that's source only (win32-api-1.0.3.gem), the other is a prebundled binary (win32-api-1.0.3-mswin32.gem). With the latest beta when I do "gem install win32-api" it never gives me a choice - it just grabs the binary gem. Any ideas and/or suggestions? Thanks, Dan From han.holl at tietoenator.com Fri Oct 19 08:10:05 2007 From: han.holl at tietoenator.com (han.holl at tietoenator.com) Date: Fri, 19 Oct 2007 14:10:05 +0200 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <471893CD.6000507@gmail.com> References: <471893CD.6000507@gmail.com> Message-ID: <200710191410.05762.han.holl@tietoenator.com> On Friday 19 October 2007, Daniel Berger wrote: > Hi all, > > Ok, I've lost track. What's the "proper" way to distribute separate gems > for MS Windows (or any platform really) where one is for users who want > to build from source vs those who just want a prebuilt binary? > I guess you'll have to give each it's own name: gem install win32-api-bin or gem install win32-api-src Cheers Han Holl From Daniel.Berger at qwest.com Fri Oct 19 09:30:24 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 19 Oct 2007 08:30:24 -0500 Subject: [Rubygems-developers] RubyGems on Win32: .bat and.cmd dilemma. In-Reply-To: <71166b3b0710181512t1618c3ffk74160775de8b686e@mail.gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72EDA@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Luis Lavena > Sent: Thursday, October 18, 2007 4:13 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] RubyGems on Win32: .bat > and.cmd dilemma. > > > Hi guys, > > I'm trying to do the final round of patches, and be less > noisy about them. Please excuse if I added to you too much > work on this. > > As Curt, Nobu, Eric and Daniel stressed on ruby-forum, > ruby-talk and this list too, the use of .cmd files over .bat > ones is a bit problematic. > > We have two kind of scripts stubs (the bat/cmd files that > actually launch ruby with the script): > > - The ones set when rubygems is installed in your ruby > installation (setup.rb) > - The ones that rubygems create when installing/updating gems > (installer.rb) > > Also, there are two problems with setup.rb and installer.rb: > > - The path to the ruby installation (Gem.ruby) is fixed. > (That means you cannot relocate your ruby from c:/ruby to > d:/ruby without requiring manually update all those .bat/.cmd files). > > - The pathless calling of the script: > @"C:/Ruby/bin/ruby.exe" "gem" %* > > That is wrong... that only will work if current directory > (pwd) is C:/Ruby/bin/ > > The patches I provided in the RubyForge tracker provide a > solution for this, but I was using the .cmd extension for those file. > > Now, taking in consideration the comment from Eric at > ruby-talk, those scripts should be .bat instead, since > PATHEXT takes preference for them instead of .cmd ones: > > D:\Users\Developer\code>set PATHEXT > PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH > > So, I'm about to provide the final round of patches to this > topic, with the following considerations: > > - All the stub scripts generated by setup.rb and installer.rb > will be .bat files. > > - The stubs will evaluate WinNT/Win9x scenario and use the > extension power available in the NT platform or stick to a > prefixed path for win9x. > > - Add more comments to the stubs generated and the methods > defined for them. > > > Any suggestion? objections? > > Thanks again for the opportunity and the openness to accept > those patches into RubyGems. Patch #14725 has been applied, so we're now using .bat files. If a Win95/98/ME user comes out of the woodwork, and they have a problem with the hard coded path, they'll simply have to modify it by hand. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From transfire at gmail.com Fri Oct 19 13:12:27 2007 From: transfire at gmail.com (Trans) Date: Fri, 19 Oct 2007 13:12:27 -0400 Subject: [Rubygems-developers] Finding where gems are stored Message-ID: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> So when did /var/lib become the place to store gems? Whomever is organizing Debian/Ubuntu's filesystem is out of their minds. Does it really make sense to have three locations for Ruby libraries? We have /usr/lib/ruby, /usr/local/site_ruby and now /var/lib/gems. Craziness. Well, despite *their* schizophrenia, how does RubyGems know where the gems are stored? Thanks, T. From Daniel.Berger at qwest.com Fri Oct 19 13:57:48 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 19 Oct 2007 12:57:48 -0500 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72EE0@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf Of Trans > Sent: Friday, October 19, 2007 11:12 AM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] Finding where gems are stored > > > So when did /var/lib become the place to store gems? Whomever > is organizing Debian/Ubuntu's filesystem is out of their > minds. Does it really make sense to have three locations for > Ruby libraries? We have /usr/lib/ruby, /usr/local/site_ruby > and now /var/lib/gems. Craziness. > > Well, despite *their* schizophrenia, how does RubyGems know > where the gems are stored? gem env gemdir (?) I can't remember the direct API call, though. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From drbrain at segment7.net Fri Oct 19 14:05:59 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 19 Oct 2007 11:05:59 -0700 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <471893CD.6000507@gmail.com> References: <471893CD.6000507@gmail.com> Message-ID: On Oct 19, 2007, at 04:23 , Daniel Berger wrote: > Hi all, > > Ok, I've lost track. What's the "proper" way to distribute separate > gems > for MS Windows (or any platform really) where one is for users who > want > to build from source vs those who just want a prebuilt binary? > > I'm curious because for the win32-api library I have two gems - one > that's source only (win32-api-1.0.3.gem), the other is a prebundled > binary (win32-api-1.0.3-mswin32.gem). With the latest beta when I do > "gem install win32-api" it never gives me a choice - it just grabs the > binary gem. > > Any ideas and/or suggestions? gem install win32-api --platform ruby One gem should be built with Gem::Platform::CURRENT, the other with Gem::Platform::RUBY (the default). If you have it set to the old platforms (Gem::Platform::WIN32) and try to build, it should complain and refuse to build the gem. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Fri Oct 19 14:09:32 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 19 Oct 2007 11:09:32 -0700 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> Message-ID: On Oct 19, 2007, at 10:12 , Trans wrote: > So when did /var/lib become the place to store gems? Whomever is > organizing Debian/Ubuntu's filesystem is out of their minds. Does it > really make sense to have three locations for Ruby libraries? We have > /usr/lib/ruby, /usr/local/site_ruby and now /var/lib/gems. Craziness. > > Well, despite *their* schizophrenia, how does RubyGems know where the > gems are stored? Gem.path -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Fri Oct 19 14:44:16 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 19 Oct 2007 11:44:16 -0700 Subject: [Rubygems-developers] Beta 0.9.4.6 (Was: RubyGems on Win32: .bat and.cmd dilemma) In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72EDA@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72EDA@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <87DED31E-692C-4822-932B-705777F13B7B@segment7.net> On Oct 19, 2007, at 06:30 , Berger, Daniel wrote: > Patch #14725 has been applied, so we're now using .bat files. If a > Win95/98/ME user comes out of the woodwork, and they have a problem > with > the hard coded path, they'll simply have to modify it by hand. If there are no objections, I'm going to push a beta tonight. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Fri Oct 19 15:06:26 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 19 Oct 2007 16:06:26 -0300 Subject: [Rubygems-developers] Beta 0.9.4.6 (Was: RubyGems on Win32: .bat and.cmd dilemma) In-Reply-To: <87DED31E-692C-4822-932B-705777F13B7B@segment7.net> References: <7524A45A1A5B264FA4809E2156496CFBE72EDA@ITOMAE2KM01.AD.QINTRA.COM> <87DED31E-692C-4822-932B-705777F13B7B@segment7.net> Message-ID: <71166b3b0710191206u1e728dd0gaabce63d0550f4f3@mail.gmail.com> On 10/19/07, Eric Hodel wrote: > On Oct 19, 2007, at 06:30 , Berger, Daniel wrote: > > Patch #14725 has been applied, so we're now using .bat files. If a > > Win95/98/ME user comes out of the woodwork, and they have a problem > > with > > the hard coded path, they'll simply have to modify it by hand. > > If there are no objections, I'm going to push a beta tonight. > None from my side :-) I'll like to thank you Eric about the dependency issue you fixed last night. And also extend this to Daniel, who tested and commited the other patches. Thank you both and looking forward deploy the new test. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Fri Oct 19 15:14:58 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 19 Oct 2007 16:14:58 -0300 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <471893CD.6000507@gmail.com> References: <471893CD.6000507@gmail.com> Message-ID: <71166b3b0710191214h108388ffm9f265b345e25de1a@mail.gmail.com> On 10/19/07, Daniel Berger wrote: > Hi all, > > Ok, I've lost track. What's the "proper" way to distribute separate gems > for MS Windows (or any platform really) where one is for users who want > to build from source vs those who just want a prebuilt binary? > > I'm curious because for the win32-api library I have two gems - one > that's source only (win32-api-1.0.3.gem), the other is a prebundled > binary (win32-api-1.0.3-mswin32.gem). With the latest beta when I do > "gem install win32-api" it never gives me a choice - it just grabs the > binary gem. > > Any ideas and/or suggestions? > The idea is that binary gems for the #local or 'current' platform have higher priority over the ones with ::RUBY as platform. In case gem didn't find one for the specific local platform, will try to install the ruby one, which will trigger then the native extension build. To avoid the auto detection, eg, on windows: gem install mongrel --platform ruby Will fire the compile procedure. I'm currently testing a few gems that have native extensions and changing their gemspec/Rakefiles to the new platform (::CURRENT) to test them. So far, everything worked as expected (which is good) :-) The only thing that failed is using --source with a file:// URL ... URI cannot parse the drive letter and path correctly, but can live with that ;-) Regards everybody. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From transfire at gmail.com Fri Oct 19 16:07:42 2007 From: transfire at gmail.com (Trans) Date: Fri, 19 Oct 2007 16:07:42 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> Message-ID: <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> On 10/19/07, Eric Hodel wrote: > On Oct 19, 2007, at 10:12 , Trans wrote: > > > So when did /var/lib become the place to store gems? Whomever is > > organizing Debian/Ubuntu's filesystem is out of their minds. Does it > > really make sense to have three locations for Ruby libraries? We have > > /usr/lib/ruby, /usr/local/site_ruby and now /var/lib/gems. Craziness. > > > > Well, despite *their* schizophrenia, how does RubyGems know where the > > gems are stored? > > Gem.path I see. I was wondering how that was defined actually, but knowing the name of the method I was able to dig it up. I'm surprised to see that it is hard coded. The GoboLinux people would like to have a talk with you ;) Seriously, though, that's not a "nice" way to do it. rbconfig really needs to be used in setting this. Personally, I would expect the gems dir to be right next to the sitedir, where ever it may be -- just because RubyGems manages the installation rather than say setup.rb, doesn't make it somehow fundamentally different. At least that's my HO. Thanks & HTH, T. From luislavena at gmail.com Fri Oct 19 16:18:12 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 19 Oct 2007 17:18:12 -0300 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> Message-ID: <71166b3b0710191318wa120f44tfa6410ba6a710c8@mail.gmail.com> On 10/19/07, Trans wrote: > I see. I was wondering how that was defined actually, but knowing the > name of the method I was able to dig it up. > > I'm surprised to see that it is hard coded. The GoboLinux people would > like to have a talk with you ;) Seriously, though, that's not a "nice" > way to do it. rbconfig really needs to be used in setting this. > Personally, I would expect the gems dir to be right next to the > sitedir, where ever it may be -- just because RubyGems manages the > installation rather than say setup.rb, doesn't make it somehow > fundamentally different. At least that's my HO. > > Thanks & HTH, > T. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > Trans, I recall an old mail I sent to the Gobo devs about this. Whta I have done in that case is export PATH in the resources, but found that RubyGems allways install the binary/stub scripts into Ruby/bin folder, which will brake when you replace ruby version. Anyway, there are gems that cannot be installed in older version of Ruby... or on new ;-) If you want, we could talk about this, I'm a registered GoboLinux user, not as active as was, but still using it at home :-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Fri Oct 19 17:47:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 19 Oct 2007 14:47:23 -0700 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> Message-ID: On Oct 19, 2007, at 13:07 , Trans wrote: > On 10/19/07, Eric Hodel wrote: >> On Oct 19, 2007, at 10:12 , Trans wrote: >> >>> So when did /var/lib become the place to store gems? Whomever is >>> organizing Debian/Ubuntu's filesystem is out of their minds. Does it >>> really make sense to have three locations for Ruby libraries? We >>> have >>> /usr/lib/ruby, /usr/local/site_ruby and now /var/lib/gems. >>> Craziness. >>> >>> Well, despite *their* schizophrenia, how does RubyGems know where >>> the >>> gems are stored? >> >> Gem.path > > I see. I was wondering how that was defined actually, but knowing the > name of the method I was able to dig it up. > > I'm surprised to see that it is hard coded. What code are you looking at? Gem.path is not hard coded. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From transfire at gmail.com Fri Oct 19 19:54:36 2007 From: transfire at gmail.com (Trans) Date: Fri, 19 Oct 2007 19:54:36 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> Message-ID: <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> On 10/19/07, Eric Hodel wrote: > What code are you looking at? Gem.path is not hard coded. Ah!!!!!!! Now I realize... whoever did the .deb jerry'd it! # The directory path where Gems are to be installed. # # Debian patch: search order of this directory. # 1. GEM_HOME enviroment variable # (Using this, Gems are to be installed in any path as you like) # 2. /var/lib/gems (This is the default path in Debian system) # # return:: [String] The directory path # def dir ### Debian ### #@gem_home ||= nil set_home(ENV['GEM_HOME']) if ENV['GEM_HOME'] @gem_home ||= File.join("/var/lib/gems", Config::CONFIG['ruby_version']) #set_home(ENV['GEM_HOME'] || default_dir) unless @gem_home ############## @gem_home end T. From halostatue at gmail.com Fri Oct 19 22:09:25 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 19 Oct 2007 22:09:25 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> Message-ID: <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> On 10/19/07, Trans wrote: > On 10/19/07, Eric Hodel wrote: > > What code are you looking at? Gem.path is not hard coded. > Ah!!!!!!! Now I realize... whoever did the .deb jerry'd it! > > # The directory path where Gems are to be installed. > # > # Debian patch: search order of this directory. > # 1. GEM_HOME enviroment variable > # (Using this, Gems are to be installed in any path as you like) > # 2. /var/lib/gems (This is the default path in Debian system) > # > # return:: [String] The directory path > # > def dir > ### Debian ### > #@gem_home ||= nil > set_home(ENV['GEM_HOME']) if ENV['GEM_HOME'] > @gem_home ||= File.join("/var/lib/gems", Config::CONFIG['ruby_version']) > #set_home(ENV['GEM_HOME'] || default_dir) unless @gem_home > ############## > @gem_home > end I can't believe that they did that. There's better ways to do this than they did. -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From nakahiro at sarion.co.jp Fri Oct 19 22:10:47 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Sat, 20 Oct 2007 11:10:47 +0900 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <71166b3b0710191214h108388ffm9f265b345e25de1a@mail.gmail.com> References: <471893CD.6000507@gmail.com> <71166b3b0710191214h108388ffm9f265b345e25de1a@mail.gmail.com> Message-ID: <471963A7.8050509@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Luis Lavena wrote: > The only thing that failed is using --source with a file:// URL ... > URI cannot parse the drive letter and path correctly, but can live > with that ;-) Here's a code from soap4r that tries to fetch the resource pointed by a given URI object. (variable 'location') http://dev.ctor.org/soap4r/browser/trunk/lib/wsdl/xmlSchema/importer.rb#L52 Ugly workaround but it works for soap4r users. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRxljpR9L2jg5EEGlAQJ35Af/Vv4FWZ6qSIUCQbnDvWCjmYdMDb3sE+LO cJD/LnOY0T4aRTwpeRrZnH+ttHyncgMRyPUt9agkkG21lG3nTg9N/OC3L/VWsEOV 5fSslzScCG43KBjAC3+7RAopP6Ldw5Blox7m5yUnWXwJByTmTbP/JAsDN2lfzV7Y ci4t/bqkOvAQ7+ZbNK9EiXyP/V2WQHjw9SQv5JnY4iuB2lURCvGRILsDD58ogbwm Fp7znsPD8N8DwRo8ldKFl19gqIz/j0rCOIHrodQ3Gef0or6FOyeOFPfNbOhRjWvB I1mayJBH3L2BreCTlsKYllP7+aTTnHnL3563FD3AfDJ3mFjxLC/9yA== =dL7G -----END PGP SIGNATURE----- From djberg96 at gmail.com Fri Oct 19 23:11:50 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 19 Oct 2007 21:11:50 -0600 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <471963A7.8050509@sarion.co.jp> References: <471893CD.6000507@gmail.com> <71166b3b0710191214h108388ffm9f265b345e25de1a@mail.gmail.com> <471963A7.8050509@sarion.co.jp> Message-ID: <471971F6.6040403@gmail.com> NAKAMURA, Hiroshi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Luis Lavena wrote: >> The only thing that failed is using --source with a file:// URL ... >> URI cannot parse the drive letter and path correctly, but can live >> with that ;-) > > Here's a code from soap4r that tries to fetch the resource pointed by a > given URI object. (variable 'location') > http://dev.ctor.org/soap4r/browser/trunk/lib/wsdl/xmlSchema/importer.rb#L52 > Ugly workaround but it works for soap4r users. require 'windows/path' include Windows::Path buf = 0.chr * 260 len = [buf.length].pack('L') PathCreateFromUrl('file://c:/foo/bar', buf, len, nil) buf.strip => "c:\\foo\\bar" Regards, Dan From luislavena at gmail.com Sat Oct 20 08:39:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 20 Oct 2007 09:39:08 -0300 Subject: [Rubygems-developers] Gems - binaries vs building from source In-Reply-To: <471971F6.6040403@gmail.com> References: <471893CD.6000507@gmail.com> <71166b3b0710191214h108388ffm9f265b345e25de1a@mail.gmail.com> <471963A7.8050509@sarion.co.jp> <471971F6.6040403@gmail.com> Message-ID: <71166b3b0710200539i160fe85ch6add87faf7640834@mail.gmail.com> On 10/20/07, Daniel Berger wrote: > NAKAMURA, Hiroshi wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi, > > > > Luis Lavena wrote: > >> The only thing that failed is using --source with a file:// URL ... > >> URI cannot parse the drive letter and path correctly, but can live > >> with that ;-) > > > > Here's a code from soap4r that tries to fetch the resource pointed by a > > given URI object. (variable 'location') > > http://dev.ctor.org/soap4r/browser/trunk/lib/wsdl/xmlSchema/importer.rb#L52 > > Ugly workaround but it works for soap4r users. > > require 'windows/path' > include Windows::Path > > buf = 0.chr * 260 > len = [buf.length].pack('L') > PathCreateFromUrl('file://c:/foo/bar', buf, len, nil) > buf.strip > > => "c:\\foo\\bar" > The problem with that is that "windows" isn't part of standard ruby distro, so you must install it after rubygems... anyway, the problem was raised since one of the file:// test was looking for C:/nonexistant instead of D:/nonexistant (D: is the drive I checkout all the code). Thank you for your suggestion. Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From transfire at gmail.com Sat Oct 20 09:09:01 2007 From: transfire at gmail.com (Trans) Date: Sat, 20 Oct 2007 09:09:01 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> Message-ID: <4b6f054f0710200609o5fc4e9a7p1f6e92e833f53981@mail.gmail.com> On 10/19/07, Austin Ziegler wrote: > > I can't believe that they did that. There's better ways to do this > than they did. Someone should talk to those people. I vote Austin. Your talented in this sort of thing ;-) T. From luislavena at gmail.com Sat Oct 20 09:33:46 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 20 Oct 2007 10:33:46 -0300 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710200609o5fc4e9a7p1f6e92e833f53981@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <4b6f054f0710200609o5fc4e9a7p1f6e92e833f53981@mail.gmail.com> Message-ID: <71166b3b0710200633g21212c13xa920f269a665d8c6@mail.gmail.com> On 10/20/07, Trans wrote: > On 10/19/07, Austin Ziegler wrote: > > > > I can't believe that they did that. There's better ways to do this > > than they did. > > Someone should talk to those people. I vote Austin. Your talented in > this sort of thing ;-) > So was the debian guys who patched/hardcoded the path? or was the GoboLinux guys? -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From nakahiro at sarion.co.jp Sat Oct 20 12:00:42 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Sun, 21 Oct 2007 01:00:42 +0900 Subject: [Rubygems-developers] gemloader.rb Message-ID: <471A262A.5040407@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Let me introduce a library that overrides Kernel.require and requires files from gem repository like rubygems. http://dev.ctor.org/vtr * just loads feature from gem repository. you can use methods Kernel.require and Kernel.gem. should have a lighter footprint than rubygems but not benchmarked yet. * no gem command. use rubygems to maintain gem repository. * UNTESTED! Download: http://dev.ctor.org/vtr/browser/trunk/lib/gemloader.rb?format=raw I wrote gemloader.rb just for a proof of concept and tested only for my restricted usage. Let me know if it works or not for you if you are interested in it. Thanks in advance. At the last, I have some questions about rubygems. 1. can rubygems/requirement.rb and rubygems/version.rb be free from require 'rubygems'? 2. Kernel.require of rubygems tries to reload the original feature when the original require failed. not failed feature but the original, is this intended? 3. the dependency resolution of rubygems should be depth first search (the latest has a priority) with no backtrack I think. is this a specification? Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRxomKB9L2jg5EEGlAQL8HAgAlDpbWb9mFFdNHe6GQUKj2YGYZ6p0Ih9o F6RV0jpqMi13qj0GgKaci6PHGfWEP9ggswXTjtGbJV0dz9lbgWeHE4Gjhq9+345y YYX0klSEWVjinvAeI0Ujcb5PrCw/8fYTouL3GeRVDnA7t2fXHVM34pcZvU5RPlXr wgDQztGMZ7fkn6wbJsAOTiBAQVeK75yahJj6miy1fF9yokEFj5nmmK3MyFv2PuZX MkMT7lzXMkY0BCjZQRtVRBY5iAEW1qD5cgWehZEodgFop6/S0W6Ncvtf6JQjY5/z VBVo7ri3AG6B7UMCTlJtQnxGuiMliIiMMstYM2V3MNgrAyecvT4PsQ== =tyLN -----END PGP SIGNATURE----- From rubygems-list at brisammon.fastmail.fm Sat Oct 20 12:20:37 2007 From: rubygems-list at brisammon.fastmail.fm (Brian Sammon) Date: Sat, 20 Oct 2007 12:20:37 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> Message-ID: > > def dir > > ### Debian ### > > #@gem_home ||= nil > > set_home(ENV['GEM_HOME']) if ENV['GEM_HOME'] > > @gem_home ||= File.join("/var/lib/gems", Config::CONFIG['ruby_version']) > > #set_home(ENV['GEM_HOME'] || default_dir) unless @gem_home > > ############## > > @gem_home > > end > > I can't believe that they did that. There's better ways to do this > than they did. I'd be interested in hearing what the better ways are. A few weeks ago I was looking to set up ruby on a windows box, and I wanted to have gems install into a directory outside of the ruby install directory (so they'd stay around when I upgraded ruby), and I ended up using the Debian hack because I couldn't find anything better. From halostatue at gmail.com Sat Oct 20 12:41:25 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Sat, 20 Oct 2007 12:41:25 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> Message-ID: <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> On 10/20/07, Brian Sammon wrote: > > > def dir > > > ### Debian ### > > > #@gem_home ||= nil > > > set_home(ENV['GEM_HOME']) if ENV['GEM_HOME'] > > > @gem_home ||= File.join("/var/lib/gems", Config::CONFIG['ruby_version']) > > > #set_home(ENV['GEM_HOME'] || default_dir) unless @gem_home > > > ############## > > > @gem_home > > > end > > I can't believe that they did that. There's better ways to do this > > than they did. > I'd be interested in hearing what the better ways are. It's called "GEM_HOME". It's called submitting patches that allow setup to provide a different default_dir. Hardcoding your directory is bad news. (It should be /var/lib/ruby/gems if they're going to be doing something that odd, anyway.) > A few weeks ago I was looking to set up ruby on a windows box, and I wanted to > have gems install into a directory outside of the ruby install directory (so > they'd stay around when I upgraded ruby), and I ended up using the Debian hack > because I couldn't find anything better. That's not safe on Windows if you use any binary extensions. -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From rick.denatale at gmail.com Sat Oct 20 13:06:39 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sat, 20 Oct 2007 13:06:39 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: On 10/20/07, Austin Ziegler wrote: > On 10/20/07, Brian Sammon wrote: > > > > def dir > > > > ### Debian ### > > > > #@gem_home ||= nil > > > > set_home(ENV['GEM_HOME']) if ENV['GEM_HOME'] > > > > @gem_home ||= File.join("/var/lib/gems", Config::CONFIG['ruby_version']) > > > > #set_home(ENV['GEM_HOME'] || default_dir) unless @gem_home > > > > ############## > > > > @gem_home > > > > end > > > I can't believe that they did that. There's better ways to do this > > > than they did. > > I'd be interested in hearing what the better ways are. > > It's called "GEM_HOME". It's called submitting patches that allow > setup to provide a different default_dir. Hardcoding your directory is > bad news. (It should be /var/lib/ruby/gems if they're going to be > doing something that odd, anyway.) Somehow they think that that violates the FHS, or at least the debian policy interpretation of it. Look at the very end of: http://pkg-ruby-extras.alioth.debian.org/rubygems.html I can't say that I understand it, but that's what the Debian ruby maintainers think. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From thewoolleyman at gmail.com Sat Oct 20 13:29:14 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 20 Oct 2007 10:29:14 -0700 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: On 10/20/07, Rick DeNatale wrote: > Somehow they think that that violates the FHS, or at least the debian > policy interpretation of it. > > Look at the very end of: > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > I can't say that I understand it, but that's what the Debian ruby > maintainers think. That document really needs to quote the exact sections of FHS that are violated, and why they consider them to be violated by Rubygems. It's too vague to just say that RubyGems violates FHS because it "follows the "one directory per package and version" rule." I couldn't find anything that said that there cannot be "one directory per package and version" - at least not by grepping the FHS for version. Here's the description of /var/lib: "This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation." However, here's the description of /usr/local: "The /usr/local hierarchy is for use by the system administrator when installing software locally" ...and /usr/local/lib: "lib Local libraries" I'm no expert, but based on the few times I've read the FHS (this isn't the first) I don't understand why they just can't go with /usr/local/lib/ structure as it already exists. I'm sure they have good reasons, but that document doesn't go far enough to explain it. They should state the exact phrases of the FHS that they think are violated by the status quo, and why their decisions make it better. Also, just pointing to the document isn't enough. They should also explain, in detail, potential problems that would be caused by "violating" the FHS. If the only real problem would be that "it violates the FHS", then I'm not sure that's a good justification to change the status quo... My .02, -- Chad From transfire at gmail.com Sat Oct 20 13:51:30 2007 From: transfire at gmail.com (Trans) Date: Sat, 20 Oct 2007 13:51:30 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: <4b6f054f0710201051j58c2991v7ba053f0efbbef99@mail.gmail.com> On 10/20/07, Chad Woolley wrote: > On 10/20/07, Rick DeNatale wrote: > > Somehow they think that that violates the FHS, or at least the debian > > policy interpretation of it. > > > > Look at the very end of: > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > > I can't say that I understand it, but that's what the Debian ruby > > maintainers think. > > That document really needs to quote the exact sections of FHS that are > violated, and why they consider them to be violated by Rubygems. It's > too vague to just say that RubyGems violates FHS because it "follows > the "one directory per package and version" rule." I don't think that flies b/c, if I'm not mistaken, that's exactly how opt/ is used. > I couldn't find anything that said that there cannot be "one directory > per package and version" - at least not by grepping the FHS for > version. > > Here's the description of /var/lib: > > "This hierarchy holds state information pertaining to an application > or the system. State information is data that programs modify while > they run, and that pertains to one specific host. Users must never > need to modify files in /var/lib to configure a package's operation." That's sort of the thing with Gems, and maybe why the Debian guys stuck it in var/, the source cache should technically be in var/, while the rest in /usr/local/lib. T. From rick.denatale at gmail.com Sat Oct 20 14:24:02 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sat, 20 Oct 2007 14:24:02 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: On 10/20/07, Chad Woolley wrote: > I'm no expert, but based on the few times I've read the FHS (this > isn't the first) I don't understand why they just can't go with > /usr/local/lib/ structure as it already exists. I'm sure they have > good reasons, but that document doesn't go far enough to explain it. > They should state the exact phrases of the FHS that they think are > violated by the status quo, and why their decisions make it better. > > Also, just pointing to the document isn't enough. They should also > explain, in detail, potential problems that would be caused by > "violating" the FHS. If the only real problem would be that "it > violates the FHS", then I'm not sure that's a good justification to > change the status quo... Again, I'm just trying to understand the debian policy on gems myself, but I suspect that the problem comes from this section of the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 "9.1.2 Site-specific programs As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. " As I understand it, Debian policy requires package installation to keep its hands off the /usr/local tree. Stuff put in /usr/local by the system administrator is supposed to be safe from being changed by package installations/updates etc. I thnk that this makes sense, however what's being described is the package which installs rubygems. The maintainer seems to be interpreting this as forbidding gem when executed from placing things under /usr/local, but I think that this is being too strict. In fact just below the quoted passage the Debian Policy manual says: "However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files. These are not directories in /usr/local, but are children of directories in /usr/local. These directories (/usr/local/*/dir/) should be removed on package removal if they are empty. Note, that this applies only to directories below /usr/local, not in /usr/local. Packages must not create sub-directories in the directory /usr/local itself, except those listed in FHS, section 4.5. However, you may create directories below them as you wish. You must not remove any of the directories listed in 4.5, even if you created them. " So, the debian gem package could be configured to put the gems under /usr/local/lib/ruby... and to create empty directories as needed when installed. But I'm not a debian maintainer so I don't know if there are other restrictions. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From luislavena at gmail.com Sat Oct 20 14:31:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 20 Oct 2007 15:31:33 -0300 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: <71166b3b0710201131x3cbddcdbn40a0ead7b2a26a6d@mail.gmail.com> On 10/20/07, Rick DeNatale wrote: > > Again, I'm just trying to understand the debian policy on gems myself, > but I suspect that the problem comes from this section of the Debian > Policy Manual: > > http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 > > "9.1.2 Site-specific programs > > As mandated by the FHS, packages must not place any files in > /usr/local, either by putting them in the file system archive to be > unpacked by dpkg or by manipulating them in their maintainer scripts. > " > > As I understand it, Debian policy requires package installation to > keep its hands off the /usr/local tree. Stuff put in /usr/local by > the system administrator is supposed to be safe from being changed by > package installations/updates etc. > > I thnk that this makes sense, however what's being described is the > package which installs rubygems. The maintainer seems to be > interpreting this as forbidding gem when executed from placing things > under /usr/local, but I think that this is being too strict. In fact > just below the quoted passage the Debian Policy manual says: > > "However, the package may create empty directories below /usr/local so > that the system administrator knows where to place site-specific > files. These are not directories in /usr/local, but are children of > directories in /usr/local. These directories (/usr/local/*/dir/) > should be removed on package removal if they are empty. > > Note, that this applies only to directories below /usr/local, not in > /usr/local. Packages must not create sub-directories in the directory > /usr/local itself, except those listed in FHS, section 4.5. However, > you may create directories below them as you wish. You must not remove > any of the directories listed in 4.5, even if you created them. " > > So, the debian gem package could be configured to put the gems under > /usr/local/lib/ruby... and to create empty directories as needed when > installed. > > But I'm not a debian maintainer so I don't know if there are other restrictions. Me neither, but I just thank Gobo developers for the openness about where to put my gems. :-) Maybe I should boot that up and send the recipe back to the community. Gems are installed in /Files/RubyGems/gems (and the stubs are inside /Files/RubyGems/bin). Good weekend everybody. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From halostatue at gmail.com Sat Oct 20 14:39:20 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Sat, 20 Oct 2007 14:39:20 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> Message-ID: <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> On 10/20/07, Chad Woolley wrote: > On 10/20/07, Rick DeNatale wrote: > > Somehow they think that that violates the FHS, or at least the debian > > policy interpretation of it. > > Look at the very end of: > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > I can't say that I understand it, but that's what the Debian ruby > > maintainers think. Actually, I thought that Trans was pointing to GoboLinux, which has made this decision. They may reuse the .deb format which may be the source of the confusion. I'm not sure, as I haven't actually looked at what Debian or Ubuntu do (I always build from source on these platforms). > That document really needs to quote the exact sections of FHS that are > violated, and why they consider them to be violated by Rubygems. It's > too vague to just say that RubyGems violates FHS because it "follows > the "one directory per package and version" rule." The Debian view, as far as I can tell, is centred around the idea that you *shouldn't* have more than one version of a library installed at any one time. I'm not sure. There is a legitimate problem with RubyGems and normal Unix layout, if Ruby is installed in /usr/bin and /usr/lib instead of /usr/local/bin and /usr/local/lib, because there are native libraries that can be built into the target directory. /usr/bin is supposed to be able to be NFS mountable; /usr/local/bin is supposed to be specific to a particular machine. That's the ONLY legitimate argument, and it's something that RubyGems will have to deal with in the future. There have been suggestions to make it so that gems can be installed in more than one directory, but that also complicates loading. That way, if Ruby is installed in /usr the .rb files will go in /usr/lib/gems/1.8/... and the .so files would go in /usr/local/lib/gems/1.8/.... > "This hierarchy holds state information pertaining to an application > or the system. State information is data that programs modify while > they run, and that pertains to one specific host. Users must never > need to modify files in /var/lib to configure a package's operation." Yeah. Whoever chose /var/lib chose wrong. But GoboLinux doesn't follow FHS, if that's the item in question. (GoboLinux is approaching it from a Mac-like approach. Unfortunately it doesn't quite work as well as that, and even the Mac still uses /usr and /usr/local and /opt and /opt/local...) -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From knu at iDaemons.org Sat Oct 20 14:18:09 2007 From: knu at iDaemons.org (Akinori MUSHA) Date: Sun, 21 Oct 2007 03:18:09 +0900 Subject: [Rubygems-developers] Getting gem information from a configure script Message-ID: <86odetk5um.knu@iDaemons.org> Hi, This is my first post to this list. Is there a way to get the gem information from a configure script? For example, when a gem wants to install extra document files to $GEM_PATH/doc/$GEM_NAME, how does it know the exact path? It would be nice if environment variables like GEM_NAME, GEM_DIR, GEM_DOC_DIR, etc. are exported so extconf.rb/configure/Rakefile can refer to them. Regards, -- / /__ __ Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Different eyes see different things, Different hearts beat on different strings -- But there are times for you and me when all such things agree" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071021/5b7326e9/attachment.bin From luislavena at gmail.com Sat Oct 20 14:58:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 20 Oct 2007 15:58:36 -0300 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> Message-ID: <71166b3b0710201158s1f3e62f6kbad671b1aaeab546@mail.gmail.com> On 10/20/07, Austin Ziegler wrote: > On 10/20/07, Chad Woolley wrote: > > On 10/20/07, Rick DeNatale wrote: > > > Somehow they think that that violates the FHS, or at least the debian > > > policy interpretation of it. > > > Look at the very end of: > > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > I can't say that I understand it, but that's what the Debian ruby > > > maintainers think. > > Actually, I thought that Trans was pointing to GoboLinux, which has > made this decision. They may reuse the .deb format which may be the > source of the confusion. I'm not sure, as I haven't actually looked at > what Debian or Ubuntu do (I always build from source on these > platforms). > I don't know why that, since the package and latest recipe from GoboLinux to build / install rubygems don't use the .deb file at all. Even the contributed recipe is using a older version of rubygems (0.8.11) > > "This hierarchy holds state information pertaining to an application > > or the system. State information is data that programs modify while > > they run, and that pertains to one specific host. Users must never > > need to modify files in /var/lib to configure a package's operation." > > Yeah. Whoever chose /var/lib chose wrong. But GoboLinux doesn't follow > FHS, if that's the item in question. (GoboLinux is approaching it from > a Mac-like approach. Unfortunately it doesn't quite work as well as > that, and even the Mac still uses /usr and /usr/local and /opt and > /opt/local...) > GoboLinux actually create some hidding symlinks for those /usr /usr/local and /opt /bin /etc... they aren't the real ones. I found less intrusive the compile and packaging process of GoboLinux than any other packaging on linux... but that is too subjective and my POV... Trans: could you be clear if you're talking about GoboLinux or debian use of forced gem store location? -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From transfire at gmail.com Sat Oct 20 15:16:07 2007 From: transfire at gmail.com (Trans) Date: Sat, 20 Oct 2007 15:16:07 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <71166b3b0710201158s1f3e62f6kbad671b1aaeab546@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <71166b3b0710201158s1f3e62f6kbad671b1aaeab546@mail.gmail.com> Message-ID: <4b6f054f0710201216n2aad55cct8a0e752a04a7374c@mail.gmail.com> On 10/20/07, Luis Lavena wrote: > Even the contributed recipe is using a older version of rubygems (0.8.11) > > > > "This hierarchy holds state information pertaining to an application > > > or the system. State information is data that programs modify while > > > they run, and that pertains to one specific host. Users must never > > > need to modify files in /var/lib to configure a package's operation." > > > > Yeah. Whoever chose /var/lib chose wrong. But GoboLinux doesn't follow > > FHS, if that's the item in question. (GoboLinux is approaching it from > > a Mac-like approach. Unfortunately it doesn't quite work as well as > > that, and even the Mac still uses /usr and /usr/local and /opt and > > /opt/local...) > > > > GoboLinux actually create some hidding symlinks for those /usr > /usr/local and /opt /bin /etc... they aren't the real ones. > > I found less intrusive the compile and packaging process of GoboLinux > than any other packaging on linux... but that is too subjective and my > POV... No, I agree. I think GFHS has it all over FHS. It may not be perfect, and personally I think maybe they went a bit too far --if they were a bit more conservative they may have a large following, but in anycase it certainly is a vast improvement over the status quo (from my POV). > Trans: could you be clear if you're talking about GoboLinux or debian > use of forced gem store location? Debian. Sorry for any confusion. I just mentioned Gobo in light of my hard-code discovery (they would been very disappointed by such a sight ;-) I just finished installing the new Ubuntu release from scratch, and I decided apt-get RubyGems b/c the current .deb version is pretty up to date. But then I couldn't find where the gems were going, which is how this came up. T. From rick.denatale at gmail.com Sat Oct 20 15:30:13 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sat, 20 Oct 2007 15:30:13 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> Message-ID: On 10/20/07, Austin Ziegler wrote: > On 10/20/07, Chad Woolley wrote: > > On 10/20/07, Rick DeNatale wrote: > > > Somehow they think that that violates the FHS, or at least the debian > > > policy interpretation of it. > > > Look at the very end of: > > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > I can't say that I understand it, but that's what the Debian ruby > > > maintainers think. > > Actually, I thought that Trans was pointing to GoboLinux, which has > made this decision. They may reuse the .deb format which may be the > source of the confusion. I'm not sure, as I haven't actually looked at > what Debian or Ubuntu do (I always build from source on these > platforms). I'm not sure what he was quoting, but the debian discussion emerged after he posted some debian code, at least it was commented that way. > > That document really needs to quote the exact sections of FHS that are > > violated, and why they consider them to be violated by Rubygems. It's > > too vague to just say that RubyGems violates FHS because it "follows > > the "one directory per package and version" rule." > > The Debian view, as far as I can tell, is centred around the idea that > you *shouldn't* have more than one version of a library installed at > any one time. I'm not sure. There is a legitimate problem with > RubyGems and normal Unix layout, if Ruby is installed in /usr/bin and > /usr/lib instead of /usr/local/bin and /usr/local/lib, because there > are native libraries that can be built into the target directory. I think that that was their original objection to gems vs. debian packages including ruby code. But looking into it further, I believe that they also decided to package the rubygems code for those who wanted to install it via apt-get or the like, and perverted it to put the gems under /var/lib > /usr/bin is supposed to be able to be NFS mountable; /usr/local/bin is > supposed to be specific to a particular machine. Actually, reading the FHS, all of /usr is shareable and read-only, and "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr." So it's not really for a particular machine, but for local installation of stuff that OS maintenance (e.g. apt-get etc) should leave alone. I think, maybe wrong. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From luislavena at gmail.com Sat Oct 20 20:51:54 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 20 Oct 2007 21:51:54 -0300 Subject: [Rubygems-developers] Missed .cmd in RubyGems Message-ID: <71166b3b0710201751n59d23da3r30e0420290423d87@mail.gmail.com> Sorry guys. I just found that we -- well, actually I -- missed a few .cmd extensions when uninstalling some gems. Since there wasn't testing for uninstall process, that didn't popped :-P Again, sorry to just found it, I was too focused on getting everything working that never tried to uninstall a gem. Attached is a simple patch that correct the bad behavior. Regards and good weekend, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi -------------- next part -------------- A non-text attachment was scrubbed... Name: silly-missed-stubs.diff Type: text/x-diff Size: 994 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071020/82578004/attachment.bin From djberg96 at gmail.com Sat Oct 20 21:30:34 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 20 Oct 2007 19:30:34 -0600 Subject: [Rubygems-developers] Missed .cmd in RubyGems In-Reply-To: <71166b3b0710201751n59d23da3r30e0420290423d87@mail.gmail.com> References: <71166b3b0710201751n59d23da3r30e0420290423d87@mail.gmail.com> Message-ID: <471AABBA.8050503@gmail.com> Luis Lavena wrote: > Sorry guys. > > I just found that we -- well, actually I -- missed a few .cmd > extensions when uninstalling some gems. > > Since there wasn't testing for uninstall process, that didn't popped :-P > > Again, sorry to just found it, I was too focused on getting everything > working that never tried to uninstall a gem. > > Attached is a simple patch that correct the bad behavior. Thanks, applied in SVN. Regards, Dan From drbrain at segment7.net Sun Oct 21 01:55:25 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 20 Oct 2007 22:55:25 -0700 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191307l6bcf8b79h8136507b2e89e68f@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> Message-ID: <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> On Oct 20, 2007, at 11:39 , Austin Ziegler wrote: > That's the ONLY legitimate argument, and it's something that RubyGems > will have to deal with in the future. There have been suggestions to > make it so that gems can be installed in more than one directory, but > that also complicates loading. That way, if Ruby is installed in /usr > the .rb files will go in /usr/lib/gems/1.8/... and the .so files would > go in /usr/local/lib/gems/1.8/.... RubyGems handles gems in multiple directories with `gem install -i` and the GEM_PATH environment variable. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From avatar at spellboundnet.com Sun Oct 21 09:14:59 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Sun, 21 Oct 2007 09:14:59 -0400 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored Message-ID: <200710210914.59312.avatar@spellboundnet.com> On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > On 10/20/07, Rick DeNatale wrote: > > Somehow they think that that violates the FHS, or at least the debian > > policy interpretation of it. > > > > Look at the very end of: > > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > > I can't say that I understand it, but that's what the Debian ruby > > maintainers think. > > That document really needs to quote the exact sections of FHS that are > violated, and why they consider them to be violated by Rubygems. It's > too vague to just say that RubyGems violates FHS because it "follows > the "one directory per package and version" rule." > > I couldn't find anything that said that there cannot be "one directory > per package and version" - at least not by grepping the FHS for > version. > > Here's the description of /var/lib: > > "This hierarchy holds state information pertaining to an application > or the system. State information is data that programs modify while > they run, and that pertains to one specific host. Users must never > need to modify files in /var/lib to configure a package's operation." > > However, here's the description of /usr/local: > > "The /usr/local hierarchy is for use by the system administrator when > installing software locally" > > ...and /usr/local/lib: > > "lib Local libraries" > > > I'm no expert, but based on the few times I've read the FHS (this > isn't the first) I don't understand why they just can't go with > /usr/local/lib/ structure as it already exists. I'm sure they have > good reasons, but that document doesn't go far enough to explain it. > They should state the exact phrases of the FHS that they think are > violated by the status quo, and why their decisions make it better. I don't do Debian package maintenance, but I do understand the overall problem with using /usr/local/lib. The issue is that a system package manager should not install software into /usr/local, because that's supposed to be used for system local commands. What this means is that a system package manager can't install gems and have them in the same structure. And, it's not too fun to put the gems in /usr/lib, since I personally want to give non-root users the ability to install gems, if I so choose. Much harder to do with a /usr/lib structure, since RPM/DEB packages will possibly muck with my permissions structure. So, I mentioned in an earlier thread about the ability to have a second gem directory, (I called it VENDOR_HOME) to store gems installed by a system package manager. The gem command will treat this as read-only, and so won't install or delete gems from this directory. This means we should be able to have our cake and eat it too! I'm guessing that, in this structure, GEM_HOME will be in /usr/local/lib (with binaries linked to /usr/local/bin), and VENDOR_HOME will be in /usr/lib (and packages install the binary commands). In theory, the gem cache should be placed somewhere in /var (there are quite a few places this could be, either /var/lib/gems or /var/tmp/gems sounds appealing to me) I'm heading out of town next week, but when I get back I'll work on getting VENDOR_HOME and so forth into RubyGems, unless of course someone else wants to tackle this. :) Thanks! Donavan From darix at web.de Sun Oct 21 10:12:28 2007 From: darix at web.de (Marcus Rueckert) Date: Sun, 21 Oct 2007 16:12:28 +0200 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored In-Reply-To: <200710210914.59312.avatar@spellboundnet.com> References: <200710210914.59312.avatar@spellboundnet.com> Message-ID: <20071021141228.GG3589@pixel.global-banlist.de> On 2007-10-21 09:14:59 -0400, Donavan Pantke wrote: > I don't do Debian package maintenance, but I do understand the overall problem > with using /usr/local/lib. The issue is that a system package manager should > not install software into /usr/local, because that's supposed to be used for > system local commands. What this means is that a system package manager can't > install gems and have them in the same structure. And, it's not too fun to > put the gems in /usr/lib, since I personally want to give non-root users the > ability to install gems, if I so choose. Much harder to do with a /usr/lib > structure, since RPM/DEB packages will possibly muck with my permissions > structure. > > So, I mentioned in an earlier thread about the ability to have a second gem > directory, (I called it VENDOR_HOME) to store gems installed by a system > package manager. The gem command will treat this as read-only, and so won't > install or delete gems from this directory. This means we should be able to > have our cake and eat it too! I'm guessing that, in this structure, GEM_HOME > will be in /usr/local/lib (with binaries linked to /usr/local/bin), and > VENDOR_HOME will be in /usr/lib (and packages install the binary commands). > > In theory, the gem cache should be placed somewhere in /var (there are quite a > few places this could be, either /var/lib/gems or /var/tmp/gems sounds > appealing to me) > > I'm heading out of town next week, but when I get back I'll work on getting > VENDOR_HOME and so forth into RubyGems, unless of course someone else wants > to tackle this. :) +1 support for something like that would make my job easier aswell. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From rick.denatale at gmail.com Sun Oct 21 13:15:31 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sun, 21 Oct 2007 13:15:31 -0400 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored In-Reply-To: <200710210914.59312.avatar@spellboundnet.com> References: <200710210914.59312.avatar@spellboundnet.com> Message-ID: On 10/21/07, Donavan Pantke wrote: > > > On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > I don't do Debian package maintenance, but I do understand the overall problem > with using /usr/local/lib. The issue is that a system package manager should > not install software into /usr/local, because that's supposed to be used for > system local commands. What this means is that a system package manager can't > install gems and have them in the same structure. Yes, but as far as I know, the debian ruby packages don't install gems. Some of them repackage the contents of gems to be installed by dpkg, but this loses the ability to have multiple versions installed concurrently. I'm still not sure I understand why the gem command installed by a package can't put the gems under /usr/local the only glitch I can think of is that it might make it difficult or impossible to update gem itself as a gem. But I long ago dropped the idea of using debian packaged ruby, at the suggestion of /\ndy Hunt. And now most of my development platform focus has switched from Ubuntu to OSX anyway. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From darix at web.de Sun Oct 21 13:52:42 2007 From: darix at web.de (Marcus Rueckert) Date: Sun, 21 Oct 2007 19:52:42 +0200 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored In-Reply-To: References: <200710210914.59312.avatar@spellboundnet.com> Message-ID: <20071021175242.GH3589@pixel.global-banlist.de> On 2007-10-21 13:15:31 -0400, Rick DeNatale wrote: > On 10/21/07, Donavan Pantke wrote: > > > > > > On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > > > I don't do Debian package maintenance, but I do understand the overall problem > > with using /usr/local/lib. The issue is that a system package manager should > > not install software into /usr/local, because that's supposed to be used for > > system local commands. What this means is that a system package manager can't > > install gems and have them in the same structure. > > Yes, but as far as I know, the debian ruby packages don't install > gems. Some of them repackage the contents of gems to be installed by > dpkg, but this loses the ability to have multiple versions installed > concurrently. yeah. but i do on suse package gems as gems. [1] > I'm still not sure I understand why the gem command installed by a > package can't put the gems under /usr/local the only glitch I can > think of is that it might make it difficult or impossible to update > gem itself as a gem. because a distributor is supposed to leave /usr/local alone. dont ever touch it. if you get the possibility to install gems in a way that gem sees them but treats them as read only, you get a good cooperation of both packaging systems. atm "gem uninstall" would uninstall gems installed through rpms and leave the rpm DB in an inconsistent state. for now i had to live with that situation and hope the admin works responsible. for the future i would like to solve the problem. my first approach was to fix gem uninstall to query the rpm db if the gem is installed via rpm and refuse to uninstall it. a vendor gem dir would be a good option aswell. darix [1] http://download.opensuse.org/repositories/ruby/ -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From rick.denatale at gmail.com Sun Oct 21 14:18:25 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Sun, 21 Oct 2007 14:18:25 -0400 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored In-Reply-To: <20071021175242.GH3589@pixel.global-banlist.de> References: <200710210914.59312.avatar@spellboundnet.com> <20071021175242.GH3589@pixel.global-banlist.de> Message-ID: On 10/21/07, Marcus Rueckert wrote: > On 2007-10-21 13:15:31 -0400, Rick DeNatale wrote: > > On 10/21/07, Donavan Pantke wrote: > > > > > > > > > On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > > > > > I don't do Debian package maintenance, but I do understand the overall problem > > > with using /usr/local/lib. The issue is that a system package manager should > > > not install software into /usr/local, because that's supposed to be used for > > > system local commands. What this means is that a system package manager can't > > > install gems and have them in the same structure. > > > > Yes, but as far as I know, the debian ruby packages don't install > > gems. Some of them repackage the contents of gems to be installed by > > dpkg, but this loses the ability to have multiple versions installed > > concurrently. > > yeah. but i do on suse package gems as gems. [1] Fine for suse, but we're talking about debian based systems. > > > I'm still not sure I understand why the gem command installed by a > > package can't put the gems under /usr/local the only glitch I can > > think of is that it might make it difficult or impossible to update > > gem itself as a gem. > > because a distributor is supposed to leave /usr/local alone. dont ever > touch it. Right, but running things installed by distributor packages under the control of the user certainly CAN touch /usr/local. For example, I've installed emacs or vim, via a debian package, I can certainly edit and save files under the /usr tree. > if you get the possibility to install gems in a way that gem sees them > but treats them as read only, you get a good cooperation of both > packaging systems. atm "gem uninstall" would uninstall gems installed > through rpms and leave the rpm DB in an inconsistent state. Yes, but debian packages go out of their way NOT to install ruby packages in a way that gem sees them as gems. In fact the package maintainers have been known to do pretty major surgery on ruby gems to turn them in to debs, for example, I recall that when I first tried using deb packages I noticed that they had rewritten the rails script in the gem, so that it was no longer a ruby script but a bash script written by the package maintainer. I don't know if this is still the case, but it left an impression on me. -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From darix at web.de Sun Oct 21 14:22:18 2007 From: darix at web.de (Marcus Rueckert) Date: Sun, 21 Oct 2007 20:22:18 +0200 Subject: [Rubygems-developers] Fwd: Re: Finding where gems are stored In-Reply-To: References: <200710210914.59312.avatar@spellboundnet.com> <20071021175242.GH3589@pixel.global-banlist.de> Message-ID: <20071021182218.GI3589@pixel.global-banlist.de> On 2007-10-21 14:18:25 -0400, Rick DeNatale wrote: > On 10/21/07, Marcus Rueckert wrote: > > On 2007-10-21 13:15:31 -0400, Rick DeNatale wrote: > > > On 10/21/07, Donavan Pantke wrote: > > > > > > > > > > > > On Saturday 20 October 2007 01:29:14 pm Chad Woolley wrote: > > > > > > > I don't do Debian package maintenance, but I do understand the overall problem > > > > with using /usr/local/lib. The issue is that a system package manager should > > > > not install software into /usr/local, because that's supposed to be used for > > > > system local commands. What this means is that a system package manager can't > > > > install gems and have them in the same structure. > > > > > > Yes, but as far as I know, the debian ruby packages don't install > > > gems. Some of them repackage the contents of gems to be installed by > > > dpkg, but this loses the ability to have multiple versions installed > > > concurrently. > > > > yeah. but i do on suse package gems as gems. [1] > > Fine for suse, but we're talking about debian based systems. and of course the problems of rpms and debs are so totally different? > > > I'm still not sure I understand why the gem command installed by a > > > package can't put the gems under /usr/local the only glitch I can > > > think of is that it might make it difficult or impossible to update > > > gem itself as a gem. > > > > because a distributor is supposed to leave /usr/local alone. dont ever > > touch it. > > Right, but running things installed by distributor packages under the > control of the user certainly CAN touch /usr/local. > > For example, I've installed emacs or vim, via a debian package, I can > certainly edit and save files under the /usr tree. you can try to discuss about the rule about /usr/local. but the rule in the FHS/LSB remains as is. > > if you get the possibility to install gems in a way that gem sees them > > but treats them as read only, you get a good cooperation of both > > packaging systems. atm "gem uninstall" would uninstall gems installed > > through rpms and leave the rpm DB in an inconsistent state. > > Yes, but debian packages go out of their way NOT to install ruby > packages in a way that gem sees them as gems. In fact the package > maintainers have been known to do pretty major surgery on ruby gems to > turn them in to debs, for example, I recall that when I first tried > using deb packages I noticed that they had rewritten the rails script > in the gem, so that it was no longer a ruby script but a bash script > written by the package maintainer. > > I don't know if this is still the case, but it left an impression on me. and i would think the main reason for their current packaging is: gems is not very friendly to other packaging systems. it is the decision of the distro maintainer what way you go. i have choosen the different way as the debian team. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From halostatue at gmail.com Sun Oct 21 19:50:50 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Sun, 21 Oct 2007 19:50:50 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> Message-ID: <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> On 10/21/07, Eric Hodel wrote: > On Oct 20, 2007, at 11:39 , Austin Ziegler wrote: > > That's the ONLY legitimate argument, and it's something that RubyGems > > will have to deal with in the future. There have been suggestions to > > make it so that gems can be installed in more than one directory, but > > that also complicates loading. That way, if Ruby is installed in /usr > > the .rb files will go in /usr/lib/gems/1.8/... and the .so files would > > go in /usr/local/lib/gems/1.8/.... > RubyGems handles gems in multiple directories with `gem install -i` > and the GEM_PATH environment variable. Let me rephrase the question to be sure of the answer. Can a single gem be installed in more than one location such that the .rb files are in one location and that the .so files are in another location? -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From nakahiro at sarion.co.jp Sun Oct 21 21:06:06 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Mon, 22 Oct 2007 10:06:06 +0900 Subject: [Rubygems-developers] gemloader.rb In-Reply-To: <471A262A.5040407@sarion.co.jp> References: <471A262A.5040407@sarion.co.jp> Message-ID: <471BF77E.9020904@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, NAKAMURA, Hiroshi wrote: > At the last, I have some questions about rubygems. > > 1. can rubygems/requirement.rb and rubygems/version.rb be free from > require 'rubygems'? > > 2. Kernel.require of rubygems tries to reload the original feature when > the original require failed. not failed feature but the original, is > this intended? > > 3. the dependency resolution of rubygems should be depth first search > (the latest has a priority) with no backtrack I think. is this a > specification? 4. rubygems adds spec.bindir to $LOAD_PATH when a gem is activated. Can't it be a problem when 2 files in bindir and libdir have the same name? I know it's needed for gem wrapper for a bin script and the file in bindir won't be activated by require. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRxv3fR9L2jg5EEGlAQIPwAgAoAwSufh66i39Oggic/E+R3QSIz/NQIvQ YSlxQVqx90+guLD4Prp7clDr/ZyrynF1H4WmxwY3bIHJT+NMwwXaNPlbPVPUs0Sr FfnRrLBb/AVm0xOkGbD+UTgwsuXuy/O3wXMDy8LRYhvspo3Qv0icWGAiKzlztQms VnRd9b9NBMO9f41PvNUpBugp0RzFDHZeQNpvZMzioOGIRGdwu9pa3S88NuOw373P 23gbRCrGygm0/AoI1kQKwZ5tbG6WSZBRZ4LTvqbl0HlcQD4V9d2V4mKGIJkULcq6 PGY3KQTLUNtMwVS8ilmK16peGjYPDVlfTzKvtDzZg5Y2lFk/JYpzoA== =Zedb -----END PGP SIGNATURE----- From drbrain at segment7.net Sun Oct 21 23:39:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 21 Oct 2007 20:39:05 -0700 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <200710210914.59312.avatar@spellboundnet.com> References: <200710210914.59312.avatar@spellboundnet.com> Message-ID: <42F9C7A1-3FBD-4680-9093-BB67602FA09C@segment7.net> On Oct 21, 2007, at 06:14 , Donavan Pantke wrote: > So, I mentioned in an earlier thread about the ability to have a > second gem > directory, (I called it VENDOR_HOME) to store gems installed by a > system > package manager. The gem command will treat this as read-only, and > so won't > install or delete gems from this directory. This means we should be > able to > have our cake and eat it too! I'm guessing that, in this structure, > GEM_HOME > will be in /usr/local/lib (with binaries linked to /usr/local/bin), > and > VENDOR_HOME will be in /usr/lib (and packages install the binary > commands). > > In theory, the gem cache should be placed somewhere in /var (there > are quite a few places this could be, either /var/lib/gems or /var/ > tmp/gems sounds appealing to me) > > I'm heading out of town next week, but when I get back I'll work on > getting > VENDOR_HOME and so forth into RubyGems, unless of course someone > else wants > to tackle this. :) What you propose sounds no different than setting GEM_PATH appropriately. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Sun Oct 21 23:48:04 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 21 Oct 2007 20:48:04 -0700 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <4b6f054f0710191654ldf3f7d7wc90d9a96fddc7a30@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> Message-ID: <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> On Oct 21, 2007, at 16:50 , Austin Ziegler wrote: > On 10/21/07, Eric Hodel wrote: >> On Oct 20, 2007, at 11:39 , Austin Ziegler wrote: >>> That's the ONLY legitimate argument, and it's something that >>> RubyGems >>> will have to deal with in the future. There have been suggestions to >>> make it so that gems can be installed in more than one directory, >>> but >>> that also complicates loading. That way, if Ruby is installed in / >>> usr >>> the .rb files will go in /usr/lib/gems/1.8/... and the .so files >>> would >>> go in /usr/local/lib/gems/1.8/.... >> RubyGems handles gems in multiple directories with `gem install -i` >> and the GEM_PATH environment variable. > > Let me rephrase the question to be sure of the answer. Can a single > gem be installed in more than one location such that the .rb files are > in one location and that the .so files are in another location? No. If you install the same gem into the default dir and into a separate path (with install -i), the files (.rb and .so) will be installed twice, but only one version will be activated. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From transfire at gmail.com Mon Oct 22 00:27:18 2007 From: transfire at gmail.com (Trans) Date: Mon, 22 Oct 2007 00:27:18 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> Message-ID: <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> On 10/21/07, Eric Hodel wrote: > No. > > If you install the same gem into the default dir and into a separate > path (with install -i), the files (.rb and .so) will be installed > twice, but only one version will be activated. Why not use 'opt/' ? I was reading about it in the FHS and it seems to fit exactly with the gems way of doing things.[1] Gems fits the /opt// mold. All RubyGems would need do is register "gems" as a provider LANANA [2] and move the the cache to /vat/opt/gems/; then RubyGems would be in perfect compliance with FHS. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES [2] http://www.lanana.org/lsbreg/providers/index.html T. From halostatue at gmail.com Mon Oct 22 01:34:10 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 22 Oct 2007 01:34:10 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> Message-ID: <9e7db9110710212234q533ab7ccta147290b21f774d2@mail.gmail.com> On 10/22/07, Trans wrote: > On 10/21/07, Eric Hodel wrote: > > No. > > > > If you install the same gem into the default dir and into a separate > > path (with install -i), the files (.rb and .so) will be installed > > twice, but only one version will be activated. > Why not use 'opt/' ? I was reading about it in the FHS and it seems to > fit exactly with the gems way of doing things.[1] Gems fits the > /opt// mold. All RubyGems would need do is register > "gems" as a provider LANANA [2] and move the the cache to > /vat/opt/gems/; then RubyGems would be in perfect compliance with FHS. > > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES > [2] http://www.lanana.org/lsbreg/providers/index.html Because there are POSIX systems not as stupid as Linux FHS. -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From transfire at gmail.com Mon Oct 22 06:01:49 2007 From: transfire at gmail.com (Trans) Date: Mon, 22 Oct 2007 06:01:49 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <9e7db9110710212234q533ab7ccta147290b21f774d2@mail.gmail.com> References: <4b6f054f0710191012x6105f4b6y1911fc29e8556250@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> <9e7db9110710212234q533ab7ccta147290b21f774d2@mail.gmail.com> Message-ID: <4b6f054f0710220301h14d432d1i5fe9bc7abe05816@mail.gmail.com> On 10/22/07, Austin Ziegler wrote: > On 10/22/07, Trans wrote: > > On 10/21/07, Eric Hodel wrote: > > > No. > > > > > > If you install the same gem into the default dir and into a separate > > > path (with install -i), the files (.rb and .so) will be installed > > > twice, but only one version will be activated. > > Why not use 'opt/' ? I was reading about it in the FHS and it seems to > > fit exactly with the gems way of doing things.[1] Gems fits the > > /opt// mold. All RubyGems would need do is register > > "gems" as a provider LANANA [2] and move the the cache to > > /vat/opt/gems/; then RubyGems would be in perfect compliance with FHS. > > > > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES > > [2] http://www.lanana.org/lsbreg/providers/index.html > > Because there are POSIX systems not as stupid as Linux FHS. He he. I won't argue with you there! But maybe it's a good route for the Debian folk. Just a thought anyway. T. From darix at web.de Mon Oct 22 06:42:11 2007 From: darix at web.de (Marcus Rueckert) Date: Mon, 22 Oct 2007 12:42:11 +0200 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <42F9C7A1-3FBD-4680-9093-BB67602FA09C@segment7.net> References: <200710210914.59312.avatar@spellboundnet.com> <42F9C7A1-3FBD-4680-9093-BB67602FA09C@segment7.net> Message-ID: <20071022104211.GJ3589@pixel.global-banlist.de> On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: > On Oct 21, 2007, at 06:14 , Donavan Pantke wrote: > > So, I mentioned in an earlier thread about the ability to have a > > second gem > > directory, (I called it VENDOR_HOME) to store gems installed by a > > system > > package manager. The gem command will treat this as read-only, and > > so won't > > install or delete gems from this directory. This means we should be > > able to > > have our cake and eat it too! I'm guessing that, in this structure, > > GEM_HOME > > will be in /usr/local/lib (with binaries linked to /usr/local/bin), > > and > > VENDOR_HOME will be in /usr/lib (and packages install the binary > > commands). > > > > In theory, the gem cache should be placed somewhere in /var (there > > are quite a few places this could be, either /var/lib/gems or /var/ > > tmp/gems sounds appealing to me) > > > > I'm heading out of town next week, but when I get back I'll work on > > getting > > VENDOR_HOME and so forth into RubyGems, unless of course someone > > else wants > > to tackle this. :) > > What you propose sounds no different than setting GEM_PATH > appropriately. 1. could you give an example how it could look like? how would you install gems into the vendor dir so the user can find them? how can you get gem to treat the vendor dir as read only unless passed a --vendor option (just an example) with the GEM_PATH solution? 2. using the environment variable has the disadvantage that the user can break it. while an additional path hardcoded in the config of gem cant be lost that easily. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From darix at web.de Mon Oct 22 06:46:14 2007 From: darix at web.de (Marcus Rueckert) Date: Mon, 22 Oct 2007 12:46:14 +0200 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> References: <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> Message-ID: <20071022104614.GK3589@pixel.global-banlist.de> On 2007-10-22 00:27:18 -0400, Trans wrote: > On 10/21/07, Eric Hodel wrote: > > > No. > > > > If you install the same gem into the default dir and into a separate > > path (with install -i), the files (.rb and .so) will be installed > > twice, but only one version will be activated. > > Why not use 'opt/' ? I was reading about it in the FHS and it seems to > fit exactly with the gems way of doing things.[1] Gems fits the > /opt// mold. All RubyGems would need do is register > "gems" as a provider LANANA [2] and move the the cache to > /vat/opt/gems/; then RubyGems would be in perfect compliance with FHS. > > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICATIONSOFTWAREPACKAGES > [2] http://www.lanana.org/lsbreg/providers/index.html if debian ships those gems inside the debs, debian becomes the vendor. and debian as a vendor is not supposed to use /opt. the hierarchy is solely for 3rd party vendors. so you could use it for gems installed via the gem cmdline... but in that case /opt feels like the wrong solution. i would rather go for /usr/local/lib/ruby/gems/ in that case. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From transfire at gmail.com Mon Oct 22 07:17:08 2007 From: transfire at gmail.com (Trans) Date: Mon, 22 Oct 2007 07:17:08 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <20071022104614.GK3589@pixel.global-banlist.de> References: <9e7db9110710191909j58731950t5cb3783b78d9dbeb@mail.gmail.com> <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> <20071022104614.GK3589@pixel.global-banlist.de> Message-ID: <4b6f054f0710220417g65420c10t3907b675d5cab097@mail.gmail.com> On 10/22/07, Marcus Rueckert wrote: > > if debian ships those gems inside the debs, debian becomes the vendor. > and debian as a vendor is not supposed to use /opt. the hierarchy is > solely for 3rd party vendors. so you could use it for gems installed via > the gem cmdline... but in that case /opt feels like the wrong solution. Right. That's what I mean, for when using gem cmdline. > i would rather go for /usr/local/lib/ruby/gems/ in that case. Is that a good place considering someone might install ruby itself to /usr/local/lib/? T. From darix at web.de Mon Oct 22 07:58:17 2007 From: darix at web.de (Marcus Rueckert) Date: Mon, 22 Oct 2007 13:58:17 +0200 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710220417g65420c10t3907b675d5cab097@mail.gmail.com> References: <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> <20071022104614.GK3589@pixel.global-banlist.de> <4b6f054f0710220417g65420c10t3907b675d5cab097@mail.gmail.com> Message-ID: <20071022115817.GL3589@pixel.global-banlist.de> On 2007-10-22 07:17:08 -0400, Trans wrote: > On 10/22/07, Marcus Rueckert wrote: > > > > if debian ships those gems inside the debs, debian becomes the vendor. > > and debian as a vendor is not supposed to use /opt. the hierarchy is > > solely for 3rd party vendors. so you could use it for gems installed via > > the gem cmdline... but in that case /opt feels like the wrong solution. > > Right. That's what I mean, for when using gem cmdline. > > > i would rather go for /usr/local/lib/ruby/gems/ in that case. > > Is that a good place considering someone might install ruby itself to > /usr/local/lib/? there are always disadvantages. but maybe something you want to consider. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From transfire at gmail.com Mon Oct 22 08:31:08 2007 From: transfire at gmail.com (Trans) Date: Mon, 22 Oct 2007 08:31:08 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <20071022115817.GL3589@pixel.global-banlist.de> References: <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> <20071022104614.GK3589@pixel.global-banlist.de> <4b6f054f0710220417g65420c10t3907b675d5cab097@mail.gmail.com> <20071022115817.GL3589@pixel.global-banlist.de> Message-ID: <4b6f054f0710220531l5f4ac228v663dd9d2ee25a3c7@mail.gmail.com> On 10/22/07, Marcus Rueckert wrote: > On 2007-10-22 07:17:08 -0400, Trans wrote: > > On 10/22/07, Marcus Rueckert wrote: > > > > > > if debian ships those gems inside the debs, debian becomes the vendor. > > > and debian as a vendor is not supposed to use /opt. the hierarchy is > > > solely for 3rd party vendors. so you could use it for gems installed via > > > the gem cmdline... but in that case /opt feels like the wrong solution. > > > > Right. That's what I mean, for when using gem cmdline. > > > > > i would rather go for /usr/local/lib/ruby/gems/ in that case. > > > > Is that a good place considering someone might install ruby itself to > > /usr/local/lib/? > > there are always disadvantages. but maybe something you want to > consider. I think you misunderstand me. It is entirely reasonable for someone to install Ruby itself to /usr/local/lib/ruby, if it wasn't for Ruby using a version tier, ie. 1.8/, that would be a complete mess --the gem dir would be mixed in with all the other libs, ostruct.rb, io/, irb/, etc. But even with the tier, I don't think it's a good practice to mixing version tiers with not version tiers --"gems" is not a version of Ruby. Perhaps if the lib/ruby were divided like: T. From transfire at gmail.com Mon Oct 22 08:36:24 2007 From: transfire at gmail.com (Trans) Date: Mon, 22 Oct 2007 08:36:24 -0400 Subject: [Rubygems-developers] Finding where gems are stored In-Reply-To: <4b6f054f0710220531l5f4ac228v663dd9d2ee25a3c7@mail.gmail.com> References: <9e7db9110710200941m71ad7d5ay49c0b2fefa4b4de5@mail.gmail.com> <9e7db9110710201139q3ab890eam545c765e80f6f141@mail.gmail.com> <78BD5DAD-BBDF-4494-84E9-E038A1B392DF@segment7.net> <9e7db9110710211650wfdf032bkbf71b0ada6f4ae78@mail.gmail.com> <9AAD3E04-F4B6-42EB-ADFF-330E58F9891D@segment7.net> <4b6f054f0710212127v51a6d4dega3d5ea6b388745da@mail.gmail.com> <20071022104614.GK3589@pixel.global-banlist.de> <4b6f054f0710220417g65420c10t3907b675d5cab097@mail.gmail.com> <20071022115817.GL3589@pixel.global-banlist.de> <4b6f054f0710220531l5f4ac228v663dd9d2ee25a3c7@mail.gmail.com> Message-ID: <4b6f054f0710220536v7bb8fb7ah569516b5f3309a47@mail.gmail.com> On 10/22/07, Trans wrote: > I think you misunderstand me. It is entirely reasonable for someone to > install Ruby itself to /usr/local/lib/ruby, if it wasn't for Ruby > using a version tier, ie. 1.8/, that would be a complete mess --the > gem dir would be mixed in with all the other libs, ostruct.rb, io/, > irb/, etc. But even with the tier, I don't think it's a good practice > to mixing version tiers with not version tiers --"gems" is not a > version of Ruby. Perhaps if the lib/ruby were divided like: Oops. Scratch that last sentence. I was going to suggest: lib/ ruby/ 1.8/ core/ site/ gems/ or lib/ ruby/ core/ 1.8/ site/ 1.8/ gems/ 1.8/ But that doesn't seem quite right either. T. From drbrain at segment7.net Mon Oct 22 11:44:52 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 22 Oct 2007 08:44:52 -0700 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <20071022104211.GJ3589@pixel.global-banlist.de> References: <200710210914.59312.avatar@spellboundnet.com> <42F9C7A1-3FBD-4680-9093-BB67602FA09C@segment7.net> <20071022104211.GJ3589@pixel.global-banlist.de> Message-ID: <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> On Oct 22, 2007, at 03:42 , Marcus Rueckert wrote: > On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: >> What you propose sounds no different than setting GEM_PATH >> appropriately. > > 1. could you give an example how it could look like? > > how would you install gems into the vendor dir so the user can find > them? gem install -i /path/to/vendor/gems echo export GEM_PATH=/path/to/vendor/gems:/path/to/gem/home >> /etc/ profile > how can you get gem to treat the vendor dir as read only unless > passed a --vendor option (just an example) with the GEM_PATH > solution? The regular permissions system handles this just fine: sudo gem install -i /path/to/vendor/gems > 2. using the environment variable has the disadvantage that the > user can > break it. while an additional path hardcoded in the config of gem > cant be lost that easily. Is PATH immune from this problem? -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Mon Oct 22 15:00:18 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 22 Oct 2007 16:00:18 -0300 Subject: [Rubygems-developers] Funny or misleading? Message-ID: <71166b3b0710221200g65de6b68qe08560d39c8f09cb@mail.gmail.com> I started with this: D:\Users\Developer>gem list *** LOCAL GEMS *** rake (0.7.3) Now, I'll just install mini_magick (which depends on hoe, which depends on rubyforge): D:\Users\Developer>gem install mini_magick --no-rdoc --no-ri Successfully installed hoe-1.3.0 Successfully installed mini_magick-1.2.3 2 gems installed Two gems installed... but: D:\Users\Developer>gem list *** LOCAL GEMS *** hoe (1.3.0) mini_magick (1.2.3) rake (0.7.3) rubyforge (0.4.4) === Tried to reproduce the situation, removed everything (except for rake) and now: D:\Users\Developer>gem install mini_magick --no-rdoc --no-ri Successfully installed rubyforge-0.4.4 Successfully installed hoe-1.3.0 Successfully installed mini_magick-1.2.3 3 gems installed === Funny, just funny :-P -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From luislavena at gmail.com Mon Oct 22 15:26:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 22 Oct 2007 16:26:33 -0300 Subject: [Rubygems-developers] odd behavior of gem#name with obsolte MSWIN32 platform. Message-ID: <71166b3b0710221226u8c98fb8lc34cfb26aa158b0a@mail.gmail.com> Hello Guys, I'm checking some odd naming behavior with latest beta. I just installed a gem with platform mswin32, which installed just fine, but found that it's named wrong by RubyGems. as Example: mongrel-1.0.1-mswin32.gem, install just fine, it list just fine. Folder on which is installed: mongrel-1.0.1-mswin32, everything seems ok. Now, I want to check that using the following pastie: http://pastie.caboo.se/109809 require 'rubygems' require 'pp' sdir = File.join(Gem.dir, 'specifications') gems = Gem::SourceIndex.from_installed_gems(sdir) list = [] gems.each do |path, gem| list << {:path => path, :gem_name => gem.name} end pp list With the following output: ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32] [{:path=>"mini_magick-1.2.3", :gem_name=>"mini_magick"}, {:path=>"mongrel-1.0.2-x86-mswin32-60", :gem_name=>"mongrel"}, {:path=>"rake-0.7.3", :gem_name=>"rake"}, {:path=>"gem_plugin-0.2.3", :gem_name=>"gem_plugin"}, {:path=>"cgi_multipart_eof_fix-2.5.0", :gem_name=>"cgi_multipart_eof_fix"}, {:path=>"win32-service-0.5.2-x86-mswin32-60", :gem_name=>"win32-service"}, {:path=>"hoe-1.3.0", :gem_name=>"hoe"}, {:path=>"rubyforge-0.4.4", :gem_name=>"rubyforge"}, {:path=>"mongrel_service-0.3.3-x86-mswin32-60", :gem_name=>"mongrel_service"}] please note that the platform for mongrel isn't mswin32, but x86-mswin32-60 ... and don't match with the folder it installed... gem#name is returning that, disregarding the current folder where the gem was installed... -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Mon Oct 22 15:53:26 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 22 Oct 2007 12:53:26 -0700 Subject: [Rubygems-developers] odd behavior of gem#name with obsolte MSWIN32 platform. In-Reply-To: <71166b3b0710221226u8c98fb8lc34cfb26aa158b0a@mail.gmail.com> References: <71166b3b0710221226u8c98fb8lc34cfb26aa158b0a@mail.gmail.com> Message-ID: On Oct 22, 2007, at 12:26 , Luis Lavena wrote: > I'm checking some odd naming behavior with latest beta. > > I just installed a gem with platform mswin32, which installed just > fine, but found that it's named wrong by RubyGems. > > as Example: > > mongrel-1.0.1-mswin32.gem, install just fine, it list just fine. > > Folder on which is installed: > > mongrel-1.0.1-mswin32, everything seems ok. > > [...] > {:path=>"mongrel-1.0.2-x86-mswin32-60", :gem_name=>"mongrel"}, > [...] > > please note that the platform for mongrel isn't mswin32, but > x86-mswin32-60 ... and don't match with the folder it installed... > > gem#name is returning that, disregarding the current folder where the > gem was installed... I tried to force converting all legacy platforms, but found it was too difficult due to the way that platforms are loaded. RubyGems is smart enough to correctly uninstall a legacy platform gem. You can access the legacy gem via Gem::Specification#original_platform. I think this is ok, since Gem::Installer and Gem::Uninstaller take care of the details for you. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From luislavena at gmail.com Mon Oct 22 15:55:48 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 22 Oct 2007 16:55:48 -0300 Subject: [Rubygems-developers] odd behavior of gem#name with obsolte MSWIN32 platform. In-Reply-To: References: <71166b3b0710221226u8c98fb8lc34cfb26aa158b0a@mail.gmail.com> Message-ID: <71166b3b0710221255o7516fd41gc632647cd7b8f970@mail.gmail.com> On 10/22/07, Eric Hodel wrote: > On Oct 22, 2007, at 12:26 , Luis Lavena wrote: > > I'm checking some odd naming behavior with latest beta. > > > > I just installed a gem with platform mswin32, which installed just > > fine, but found that it's named wrong by RubyGems. > > > > as Example: > > > > mongrel-1.0.1-mswin32.gem, install just fine, it list just fine. > > > > Folder on which is installed: > > > > mongrel-1.0.1-mswin32, everything seems ok. > > > > [...] > > {:path=>"mongrel-1.0.2-x86-mswin32-60", :gem_name=>"mongrel"}, > > [...] > > > > please note that the platform for mongrel isn't mswin32, but > > x86-mswin32-60 ... and don't match with the folder it installed... > > > > gem#name is returning that, disregarding the current folder where the > > gem was installed... > > I tried to force converting all legacy platforms, but found it was > too difficult due to the way that platforms are loaded. RubyGems is > smart enough to correctly uninstall a legacy platform gem. You can > access the legacy gem via Gem::Specification#original_platform. > > I think this is ok, since Gem::Installer and Gem::Uninstaller take > care of the details for you. > Since GemPlugin (the one used by Mongrel) rely on RubyGems to find and load the additional gems, we should fix this (I mean, gem_plugin, not rubygems). I'll check what can we do so avoid conflict when updated rubygems get released. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From laurent.sansonetti at gmail.com Tue Oct 23 09:43:59 2007 From: laurent.sansonetti at gmail.com (Laurent Sansonetti) Date: Tue, 23 Oct 2007 15:43:59 +0200 Subject: [Rubygems-developers] OSX 10.5 patch Message-ID: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> Hi RubyGems developers, # I work for Apple, in the OS team. As you may perhaps know, in the next version of Mac OS X, RubyGems is bundled in the default install. So, let me first thank you for your great work! Attached is a patch that we created to make RubyGems 0.9.4 work with our new Ruby environment. The patch is rather simple, but let me describe it. In Leopard, Ruby is delivered as a framework. The entire Ruby distribution is there, and we have symbolic links in the previous directory layout that point to files inside the framework. The first change-set is to leave the bin path as /usr/bin, because Ruby's bindir is actually a directory inside the framework. We want RubyGems to generate its binary wrappers in /usr/bin, so that they will be accessible from the PATH. In Leopard, we didn't want to use a unique gem repository, because we wanted to separate the pre-installed gems that ship with Leopard from the gems that the user will install after. So Leopard comes with 2 gem repositories, one inside the Ruby framework that contains all the pre-installed gems, and another one in /Library which is empty by default, but which is also the default repository. The second change-set adds the APPLE_GEM_HOME constant value to the gems paths if it's defined. We in fact define this constant in rbconfig.rb. The third change-set simply adds the ruby version to the default gem directory, which was probably an omission. These changes should only be effective when Ruby is available as a framework (where the RUBY_FRAMEWORK_VERSION or APPLE_GEM_HOME constants are defined), so other environments should not be affected. It would be really great if you could consider merging this patch upstream. We would also be happy to discuss the changes, and provide another patch if necessary. Laurent -------------- next part -------------- A non-text attachment was scrubbed... Name: lib_rubygems.rb.diff Type: application/octet-stream Size: 1265 bytes Desc: not available Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20071023/71613d74/attachment.obj From matt-lists at reprocessed.org Tue Oct 23 10:41:19 2007 From: matt-lists at reprocessed.org (Matt Patterson) Date: Tue, 23 Oct 2007 15:41:19 +0100 Subject: [Rubygems-developers] Problems with setup.rb in the rubygems package Message-ID: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> Hello, I'm working on building a rubygems .deb package which isn't as invasively patched as the standard Debian/Ubuntu one for automated deployment stuff I'm working on. My issue is that to avoid some of the hacking of post_install.rb that needed to be done to get the sources gem built I want to pass another option in to setup.rb and pull that value out later. The setup.rb docs say to use metaconfig and a call to add_path_config within that. This I've done: add_path_config 'gem_install_root', '', 'Path to root of build "filesystem"' However, when setup.rb gets run by the packaging makefile I get this error: /usr/bin/ruby1.8 setup.rb config --siterubyver=/usr/lib/ruby/1.8 setup.rb:100:in `push': can't modify frozen array (TypeError) from setup.rb:100:in `add' from setup.rb:508:in `add_path_config' from /home/matt/sandbox/packages/libgems-ruby-0.9.4/ metaconfig:1:in `load_script' from setup.rb:831:in `run_metaconfigs' from setup.rb:807:in `invoke' from setup.rb:773:in `invoke' from setup.rb:1578 I know it's not a rubygems problem per se, but I was hoping someone would have some insight here, since it's rubygem's setup.rb... I'm utterly baffled how metaconfig could EVER work, since the call to freeze the array in question happens before metaconfig is even read in... My working hypothesis is that I'm being stupid... Thanks, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From halostatue at gmail.com Tue Oct 23 11:50:09 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 23 Oct 2007 11:50:09 -0400 Subject: [Rubygems-developers] OSX 10.5 patch In-Reply-To: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> References: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> Message-ID: <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> On 10/23/07, Laurent Sansonetti wrote: > The first change-set is to leave the bin path as /usr/bin, because > Ruby's bindir is actually a directory inside the framework. We want > RubyGems to generate its binary wrappers in /usr/bin, so that they > will be accessible from the PATH. Would it not be better to set that value in Config the way you did with APPLE_GEM_HOME? > In Leopard, we didn't want to use a unique gem repository, because we > wanted to separate the pre-installed gems that ship with Leopard from > the gems that the user will install after. So Leopard comes with 2 gem > repositories, one inside the Ruby framework that contains all the > pre-installed gems, and another one in /Library which is empty by > default, but which is also the default repository. What happens if I upgrade a gem? This seems relevant to the discussion that's been happening here with respect to Linux distros wanting more from both Ruby and RubyGems. Is there something that can be generalized here for either and/or both? -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From laurent.sansonetti at gmail.com Tue Oct 23 12:10:39 2007 From: laurent.sansonetti at gmail.com (Laurent Sansonetti) Date: Tue, 23 Oct 2007 18:10:39 +0200 Subject: [Rubygems-developers] OSX 10.5 patch In-Reply-To: <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> References: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> Message-ID: <1be7247c0710230910ia43deccub39d4dfb8d6c9a87@mail.gmail.com> On 10/23/07, Austin Ziegler wrote: > On 10/23/07, Laurent Sansonetti wrote: > > The first change-set is to leave the bin path as /usr/bin, because > > Ruby's bindir is actually a directory inside the framework. We want > > RubyGems to generate its binary wrappers in /usr/bin, so that they > > will be accessible from the PATH. > > Would it not be better to set that value in Config the way you did > with APPLE_GEM_HOME? We could do that indeed, but this would be in a software update. It's also probably safe for now to assume that Leopard will be the only environment with a framework'ized ruby. > > In Leopard, we didn't want to use a unique gem repository, because we > > wanted to separate the pre-installed gems that ship with Leopard from > > the gems that the user will install after. So Leopard comes with 2 gem > > repositories, one inside the Ruby framework that contains all the > > pre-installed gems, and another one in /Library which is empty by > > default, but which is also the default repository. > > What happens if I upgrade a gem? This seems relevant to the discussion > that's been happening here with respect to Linux distros wanting more > from both Ruby and RubyGems. Is there something that can be > generalized here for either and/or both? If you upgrade a pre-installed gem, the new version of the gem will go in the /Library repository, while the old one will stay in the system repository. I am currently preparing an article that will explain this (as well as the other Ruby-related changes in Leopard), and we want to make it available the soonest possible, so stay tuned :-) Laurent From drbrain at segment7.net Tue Oct 23 13:34:37 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 23 Oct 2007 10:34:37 -0700 Subject: [Rubygems-developers] Problems with setup.rb in the rubygems package In-Reply-To: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> References: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> Message-ID: <76A05D57-E870-4A9E-AC8D-8A8B2877601A@segment7.net> On Oct 23, 2007, at 07:41 , Matt Patterson wrote: > I'm working on building a rubygems .deb package which isn't as > invasively patched as the standard Debian/Ubuntu one for automated > deployment stuff I'm working on. > > My issue is that to avoid some of the hacking of post_install.rb that > needed to be done to get the sources gem built I want to pass another > option in to setup.rb and pull that value out later. > > The setup.rb docs say to use metaconfig and a call to add_path_config > within that. This I've done: The giant setup.rb/post-install.rb is gone. Now there's a nice, small, readable setup.rb. Oh, and no more sources.gem by default. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From matt-lists at reprocessed.org Tue Oct 23 14:08:23 2007 From: matt-lists at reprocessed.org (Matt Patterson) Date: Tue, 23 Oct 2007 19:08:23 +0100 Subject: [Rubygems-developers] Problems with setup.rb in the rubygems package In-Reply-To: <76A05D57-E870-4A9E-AC8D-8A8B2877601A@segment7.net> References: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> <76A05D57-E870-4A9E-AC8D-8A8B2877601A@segment7.net> Message-ID: <435787C7-2B2D-44F8-8DE6-DD8B4ED2D1BB@reprocessed.org> On 23 Oct 2007, at 18:34, Eric Hodel wrote: > On Oct 23, 2007, at 07:41 , Matt Patterson wrote: >> The setup.rb docs say to use metaconfig and a call to add_path_config >> within that. This I've done: > > The giant setup.rb/post-install.rb is gone. Now there's a nice, > small, readable setup.rb. Oh, and no more sources.gem by default. That's very good news for me :-) Now, where can I get this small slice of nirvana? Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From luislavena at gmail.com Tue Oct 23 14:11:50 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 23 Oct 2007 15:11:50 -0300 Subject: [Rubygems-developers] Problems with setup.rb in the rubygems package In-Reply-To: <435787C7-2B2D-44F8-8DE6-DD8B4ED2D1BB@reprocessed.org> References: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> <76A05D57-E870-4A9E-AC8D-8A8B2877601A@segment7.net> <435787C7-2B2D-44F8-8DE6-DD8B4ED2D1BB@reprocessed.org> Message-ID: <71166b3b0710231111t42915c1fjbd34e318acb68dd5@mail.gmail.com> On 10/23/07, Matt Patterson wrote: > On 23 Oct 2007, at 18:34, Eric Hodel wrote: > > > On Oct 23, 2007, at 07:41 , Matt Patterson wrote: > >> The setup.rb docs say to use metaconfig and a call to add_path_config > >> within that. This I've done: > > > > The giant setup.rb/post-install.rb is gone. Now there's a nice, > > small, readable setup.rb. Oh, and no more sources.gem by default. > > That's very good news for me :-) > > Now, where can I get this small slice of nirvana? There is no official "package" released for the upcoming version (0.9.5) but you could checkout from repository: svn checkout http://rubygems.rubyforge.org/svn/trunk/ rubygems-trunk Regards, -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From matt-lists at reprocessed.org Tue Oct 23 14:20:42 2007 From: matt-lists at reprocessed.org (Matt Patterson) Date: Tue, 23 Oct 2007 19:20:42 +0100 Subject: [Rubygems-developers] OSX 10.5 patch In-Reply-To: <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> References: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> Message-ID: On 23 Oct 2007, at 16:50, Austin Ziegler wrote: > On 10/23/07, Laurent Sansonetti wrote: >> In Leopard, we didn't want to use a unique gem repository, because we >> wanted to separate the pre-installed gems that ship with Leopard from >> the gems that the user will install after. So Leopard comes with 2 >> gem >> repositories, one inside the Ruby framework that contains all the >> pre-installed gems, and another one in /Library which is empty by >> default, but which is also the default repository. > > What happens if I upgrade a gem? This seems relevant to the discussion > that's been happening here with respect to Linux distros wanting more > from both Ruby and RubyGems. Is there something that can be > generalized here for either and/or both? I'm looking at this same sort of thing for Debian / Ubuntu. In my case, I want to do app server deployments (i.e. deployments of app servers, rather than deployments to app servers...) so I want everything nailed down and deployed using OS packages I reckoned I'd get something that worked for me and then see what people thought, but since there seems to be discussion around here.... I'm using Gem::Installer and some of the Gem::RemoteInstaller internals to fetch, snaffle information from a gem in order to build the dpkg standard directory structures, and then 'install' the gem into the tmp dir that acts as a sort-of fake /. It's not pretty (yet), and if people liked some of the approach then we'd need to tighten up the interactions between my code and Rubygem's internals... My main pain points so far have been building a tarball containing the .gem, and persuading Gem::Installer that it should put binary wrapper scripts in tmp/usr/bin rather than symlinks somewhere else... I was also wondering about a two-level split between gems, much like / usr/lib /usr/local/lib, much like the /System/Frameworks /Library/ split you have with MacPython and with what Laurent seems to have done with Ruby in Leopard. I shall follow this discussion with interest and make my stuff available when it's not quite so embarassingly quickly-sketched- prototype Best, Matt -- Matt Patterson | Design & Code | http://www.reprocessed.org/ From rick.denatale at gmail.com Tue Oct 23 14:43:02 2007 From: rick.denatale at gmail.com (Rick DeNatale) Date: Tue, 23 Oct 2007 14:43:02 -0400 Subject: [Rubygems-developers] OSX 10.5 patch In-Reply-To: <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> References: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> <9e7db9110710230850o44844471q31de9608a6222ee2@mail.gmail.com> Message-ID: On 10/23/07, Austin Ziegler wrote: > On 10/23/07, Laurent Sansonetti wrote: > > The first change-set is to leave the bin path as /usr/bin, because > > Ruby's bindir is actually a directory inside the framework. We want > > RubyGems to generate its binary wrappers in /usr/bin, so that they > > will be accessible from the PATH. > > Would it not be better to set that value in Config the way you did > with APPLE_GEM_HOME? But he's only got THREE DAYS before leopard ships! -- Rick DeNatale My blog on Ruby http://talklikeaduck.denhaven2.com/ From Daniel.Berger at qwest.com Tue Oct 23 15:32:52 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 23 Oct 2007 14:32:52 -0500 Subject: [Rubygems-developers] Asking me for prerequisites Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72EF8@ITOMAE2KM01.AD.QINTRA.COM> Sorry if I've missed this. Is the latest rubygems not going to ask me if I want to install prerequisites? Because with the current svn version it just installs them without asking. On Windows, anyway. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jim.weirich at gmail.com Tue Oct 23 15:46:04 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 23 Oct 2007 15:46:04 -0400 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72EF8@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72EF8@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <31A9B83F-7EEC-4BAC-8DD2-723E0F54097C@gmail.com> On Oct 23, 2007, at 3:32 PM, Berger, Daniel wrote: > Sorry if I've missed this. > > Is the latest rubygems not going to ask me if I want to install > prerequisites? Because with the current svn version it just installs > them without asking. On Windows, anyway. That is correct, the default behavior was changed. -- -- Jim Weirich -- jim.weirich at gmail.com From luislavena at gmail.com Tue Oct 23 16:20:47 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 23 Oct 2007 17:20:47 -0300 Subject: [Rubygems-developers] RubyGems don't like binaries for executables Message-ID: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> This behaviour is old: Scenario: Add an executable (binary compiled for the platform) to /bin and later include this in the default_executable / executabels option of the specficication. What happens: when you install the gem, RubyGems systematically add the shebang to all the files marked as executables (and create the windows stubs also). To workaround this, I needed to exclude mongrel_service.exe from executables and manually copy the file, which is sub optimum (actually my gem does it). The problem with this is that you can't have 2 versions of the same executable laying in your ruby/bin folder, and also is sub optimum create batch scripts that load ruby, rubygems, get the correct version and #system to the executable with the ARGV list... Also, for this case, mongrel_service register a service in the windows registry, so: lib/1.8/gems/mongrel_service-0.3.3-mswin32/bin/mongrel_service.exe is part of the action command line, which will brake with later updates of the gem. What other developers suggest about this? Or I should stay away the patching nightmare and keep doing what I currently do? -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From Daniel.Berger at qwest.com Tue Oct 23 17:10:08 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 23 Oct 2007 16:10:08 -0500 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72EFB@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Luis Lavena > Sent: Tuesday, October 23, 2007 2:21 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] RubyGems don't like binaries > for executables > > > This behaviour is old: > > Scenario: > Add an executable (binary compiled for the platform) to > /bin and later include this in the default_executable / > executabels option of the specficication. > > What happens: when you install the gem, RubyGems > systematically add the shebang to all the files marked as > executables (and create the windows stubs also). > > To workaround this, I needed to exclude mongrel_service.exe > from executables and manually copy the file, which is sub > optimum (actually my gem does it). > > The problem with this is that you can't have 2 versions of > the same executable laying in your ruby/bin folder, and also > is sub optimum create batch scripts that load ruby, rubygems, > get the correct version and #system to the executable with > the ARGV list... > > Also, for this case, mongrel_service register a service in > the windows registry, so: > > lib/1.8/gems/mongrel_service-0.3.3-mswin32/bin/mongrel_service.exe > > is part of the action command line, which will brake with > later updates of the gem. > > What other developers suggest about this? Or I should stay > away the patching nightmare and keep doing what I currently do? If I understand correctly, executables are not put in c:\ruby\bin, correct? Is there an option to copy or move executables to the ruby/bin directory automatically (or wherever the user wants to put executables)? If not, perhaps an option to add that would be nice. If it already does that, then I'm afraid I don't understand the issue. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From luislavena at gmail.com Tue Oct 23 17:16:58 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 23 Oct 2007 18:16:58 -0300 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72EFB@ITOMAE2KM01.AD.QINTRA.COM> References: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72EFB@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0710231416t5521e3c3if44b0c8f7706d3ee@mail.gmail.com> On 10/23/07, Berger, Daniel wrote: > > If I understand correctly, executables are not put in c:\ruby\bin, > correct? Is there an option to copy or move executables to the ruby/bin > directory automatically (or wherever the user wants to put executables)? > Excuse my english is so poor :-P If I add executables using spec.executables array or set it by #default_executable, RubyGems do garbage with the binary (for binary I mean windows PE executable). > If not, perhaps an option to add that would be nice. If it already does > that, then I'm afraid I don't understand the issue. Currently RubyGems grabs everything you have in bin (that is listed in #executables) and put shebang line to it... which render the file useless. Also creates the windows stub scripts, that call ruby to run the useless garbage that was created in first step. One solution will be if .exe files (binary PE files) found in #executables, treat them 'as-is' and do a binary copy to ruby/bin. That could be a security issue, if you install gems from untrusted sources (and have ruby/bin in the path). Also, this will require you install previous versions of the gem when you want to "switch" to a specific version... thus, breaking the joy of automatic version use of RubyGems. -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From avatar at spellboundnet.com Tue Oct 23 17:21:01 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Tue, 23 Oct 2007 17:21:01 -0400 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> References: <200710210914.59312.avatar@spellboundnet.com> <20071022104211.GJ3589@pixel.global-banlist.de> <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> Message-ID: <200710231721.01708.avatar@spellboundnet.com> On Monday 22 October 2007 11:44:52 am Eric Hodel wrote: > On Oct 22, 2007, at 03:42 , Marcus Rueckert wrote: > > On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: > >> What you propose sounds no different than setting GEM_PATH > >> appropriately. > > > > 1. could you give an example how it could look like? > > > > how would you install gems into the vendor dir so the user can find > > them? > > gem install -i /path/to/vendor/gems > > echo export GEM_PATH=/path/to/vendor/gems:/path/to/gem/home >> /etc/ > profile Perhaps. I don't have a full workstation up, does a gem list -l list all gems in GEM_PATH? The idea here is to make the vendor are as seemless to the end user as possible. > > > how can you get gem to treat the vendor dir as read only unless > > passed a --vendor option (just an example) with the GEM_PATH > > solution? > > The regular permissions system handles this just fine: > > sudo gem install -i /path/to/vendor/gems I'm not keen on letting the permission system handle this, since there are definitely cases I can think of where a user might sudo a gem command and still mess up the vendor area. However, the GEM_PATH solution may still work. Is it possible for us to say that any modifications to gems MUST be done inside GEM_HOME? That is, no deletes or additions could be made to other directories in GEM_PATH, only in GEM_HOME. Pardon me if the code works this way already, as I said I'm not where I could test it myself right now. :) > > > 2. using the environment variable has the disadvantage that the > > user can > > break it. while an additional path hardcoded in the config of gem > > cant be lost that easily. > > Is PATH immune from this problem? No, but a better analogy would be setting LD_LIBRARY_PATH. And on most systems, we try to avoid doing that as best as possible. Same should be with Gems. So, I'm thinking that judicious use of GEM_PATH may be a good solution here, we just want to try and get that behavior the way we would like it. Thanks! Donavan > > -- > Poor workers blame their tools. Good workers build better tools. The > best workers get their tools to do the work for them. -- Syndicate Wars > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drnicwilliams at gmail.com Tue Oct 23 18:49:07 2007 From: drnicwilliams at gmail.com (Nic Williams) Date: Wed, 24 Oct 2007 08:49:07 +1000 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: <71166b3b0710231416t5521e3c3if44b0c8f7706d3ee@mail.gmail.com> References: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72EFB@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0710231416t5521e3c3if44b0c8f7706d3ee@mail.gmail.com> Message-ID: <44b555bb0710231549r44523121n95a48fe99f4762b4@mail.gmail.com> Is there a doc/blog post anywhere about including non-Ruby executables in a gem? Nic On 10/24/07, Luis Lavena wrote: > > On 10/23/07, Berger, Daniel wrote: > > > > If I understand correctly, executables are not put in c:\ruby\bin, > > correct? Is there an option to copy or move executables to the ruby/bin > > directory automatically (or wherever the user wants to put executables)? > > > > Excuse my english is so poor :-P > > If I add executables using spec.executables array or set it by > #default_executable, RubyGems do garbage with the binary (for binary I > mean windows PE executable). > > > If not, perhaps an option to add that would be nice. If it already does > > that, then I'm afraid I don't understand the issue. > > Currently RubyGems grabs everything you have in bin (that is listed in > #executables) and put shebang line to it... which render the file > useless. > > Also creates the windows stub scripts, that call ruby to run the > useless garbage that was created in first step. > > One solution will be if .exe files (binary PE files) found in > #executables, treat them 'as-is' and do a binary copy to ruby/bin. > > That could be a security issue, if you install gems from untrusted > sources (and have ruby/bin in the path). > > Also, this will require you install previous versions of the gem when > you want to "switch" to a specific version... thus, breaking the joy > of automatic version use of RubyGems. > > -- > Luis Lavena > Multimedia systems > - > Leaders are made, they are not born. They are made by hard effort, > which is the price which all of us must pay to achieve any goal that > is worthwhile. > Vince Lombardi > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Dr Nic Williams http://drnicacademy.com - Ruby/Rails training around the world http://drnicwilliams.com - Ruby/Rails/Javascript/Web2.0 skype: nicwilliams (p) +61 412 002 126 (mail) PO Box 583, Ashgrove 4060, Queensland, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071024/4c71a09d/attachment.html From luislavena at gmail.com Tue Oct 23 20:59:08 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 23 Oct 2007 21:59:08 -0300 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: <44b555bb0710231549r44523121n95a48fe99f4762b4@mail.gmail.com> References: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72EFB@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0710231416t5521e3c3if44b0c8f7706d3ee@mail.gmail.com> <44b555bb0710231549r44523121n95a48fe99f4762b4@mail.gmail.com> Message-ID: <71166b3b0710231759o4c159e1bg1350efe0c1345227@mail.gmail.com> On 10/23/07, Nic Williams wrote: > Is there a doc/blog post anywhere about including non-Ruby executables in a > gem? > AFAIK there isn't. Is a bit complicated, as I exmplained in this thread (also, you can check the code of mongrel_service in mongrel repository [1] on what I'm currently doing). [1] http://mongrel.rubyforge.org/svn/trunk/projects/mongrel_service/ Hope this helps you ;-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From drbrain at segment7.net Wed Oct 24 12:17:13 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 24 Oct 2007 09:17:13 -0700 Subject: [Rubygems-developers] Problems with setup.rb in the rubygems package In-Reply-To: <435787C7-2B2D-44F8-8DE6-DD8B4ED2D1BB@reprocessed.org> References: <666DFFB9-1E94-456E-890C-8A2F1B2D6DC5@reprocessed.org> <76A05D57-E870-4A9E-AC8D-8A8B2877601A@segment7.net> <435787C7-2B2D-44F8-8DE6-DD8B4ED2D1BB@reprocessed.org> Message-ID: <25625008-0D3C-40C1-B326-1A93CE921A2C@segment7.net> On Oct 23, 2007, at 11:08 , Matt Patterson wrote: > On 23 Oct 2007, at 18:34, Eric Hodel wrote: >> On Oct 23, 2007, at 07:41 , Matt Patterson wrote: >>> The setup.rb docs say to use metaconfig and a call to >>> add_path_config >>> within that. This I've done: >> >> The giant setup.rb/post-install.rb is gone. Now there's a nice, >> small, readable setup.rb. Oh, and no more sources.gem by default. > > That's very good news for me :-) > > Now, where can I get this small slice of nirvana? There is a beta: http://blog.segment7.net/articles/2007/10/20/rubygems-beta-0-9-4-6 -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From drbrain at segment7.net Wed Oct 24 12:18:34 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 24 Oct 2007 09:18:34 -0700 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <31A9B83F-7EEC-4BAC-8DD2-723E0F54097C@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFBE72EF8@ITOMAE2KM01.AD.QINTRA.COM> <31A9B83F-7EEC-4BAC-8DD2-723E0F54097C@gmail.com> Message-ID: <871350CB-F82F-46B8-8611-EAFA0DC52071@segment7.net> On Oct 23, 2007, at 12:46 , Jim Weirich wrote: > On Oct 23, 2007, at 3:32 PM, Berger, Daniel wrote: >> Sorry if I've missed this. >> >> Is the latest rubygems not going to ask me if I want to install >> prerequisites? Because with the current svn version it just installs >> them without asking. On Windows, anyway. > > That is correct, the default behavior was changed. It now behaves more like macports or FreeBSD's ports which seems more sensible. If you want the old behavior, use --ignore-dependencies. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From Daniel.Berger at qwest.com Wed Oct 24 14:59:29 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 24 Oct 2007 13:59:29 -0500 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <871350CB-F82F-46B8-8611-EAFA0DC52071@segment7.net> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Eric Hodel > Sent: Wednesday, October 24, 2007 10:19 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] Asking me for prerequisites > > > On Oct 23, 2007, at 12:46 , Jim Weirich wrote: > > On Oct 23, 2007, at 3:32 PM, Berger, Daniel wrote: > >> Sorry if I've missed this. > >> > >> Is the latest rubygems not going to ask me if I want to install > >> prerequisites? Because with the current svn version it > just installs > >> them without asking. On Windows, anyway. > > > > That is correct, the default behavior was changed. > > It now behaves more like macports or FreeBSD's ports which > seems more > sensible. If you want the old behavior, use --ignore-dependencies. Warning: bikeshed alert. :) Using '--ignore-dependencies' means it will ask me before installing dependencies? That seems like an odd switch name then. I vote for '--ask-dependencies' instead. I would tuit '--ignore-dependencies' to mean 'just install the damn thing, don't try to grab the dependencies at all'. Just a thought. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From drbrain at segment7.net Wed Oct 24 22:35:08 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 24 Oct 2007 19:35:08 -0700 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> On Oct 24, 2007, at 11:59 , Berger, Daniel wrote: >> -----Original Message----- >> From: rubygems-developers-bounces at rubyforge.org >> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf >> Of Eric Hodel >> Sent: Wednesday, October 24, 2007 10:19 AM >> To: rubygems-developers at rubyforge.org >> Subject: Re: [Rubygems-developers] Asking me for prerequisites >> >> >> On Oct 23, 2007, at 12:46 , Jim Weirich wrote: >>> On Oct 23, 2007, at 3:32 PM, Berger, Daniel wrote: >>>> Sorry if I've missed this. >>>> >>>> Is the latest rubygems not going to ask me if I want to install >>>> prerequisites? Because with the current svn version it >> just installs >>>> them without asking. On Windows, anyway. >>> >>> That is correct, the default behavior was changed. >> >> It now behaves more like macports or FreeBSD's ports which >> seems more >> sensible. If you want the old behavior, use --ignore-dependencies. > > Warning: bikeshed alert. :) > > Using '--ignore-dependencies' means it will ask me before installing > dependencies? > > That seems like an odd switch name then. I vote for '--ask- > dependencies' > instead. I would tuit '--ignore-dependencies' to mean 'just install > the > damn thing, don't try to grab the dependencies at all'. It means the latter. It will never ask before installing dependencies anymore. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From rubygems-list at brisammon.fastmail.fm Wed Oct 24 23:08:10 2007 From: rubygems-list at brisammon.fastmail.fm (Brian Sammon) Date: Wed, 24 Oct 2007 23:08:10 -0400 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> References: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> Message-ID: > > That seems like an odd switch name then. I vote for '--ask- > > dependencies' > > instead. I would tuit '--ignore-dependencies' to mean 'just install > > the > > damn thing, don't try to grab the dependencies at all'. > > It means the latter. It will never ask before installing > dependencies anymore. Will the --ignore-dependencies option at least tell you what dependencies you have just ignored? I would like to see the old behavior kept around as an option, or as an alternative/additional, a mode for it to behave like rpm/dpkg, and just fail verbosely if you don't have the dependencies already. Would patches for any of this kind of stuff be accepted? (as non-defaulted options, of course) From drbrain at segment7.net Wed Oct 24 23:15:24 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 24 Oct 2007 20:15:24 -0700 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> Message-ID: <13A21272-E2AB-4334-97EA-4A6290E68049@segment7.net> On Oct 24, 2007, at 20:08 , Brian Sammon wrote: >>> That seems like an odd switch name then. I vote for '--ask- >>> dependencies' >>> instead. I would tuit '--ignore-dependencies' to mean 'just install >>> the >>> damn thing, don't try to grab the dependencies at all'. >> >> It means the latter. It will never ask before installing >> dependencies anymore. > > Will the --ignore-dependencies option at least tell you what > dependencies you > have just ignored? `gem dep` will tell you that. > I would like to see the old behavior kept around as an option, or > as an > alternative/additional, a mode for it to behave like rpm/dpkg, and > just fail > verbosely if you don't have the dependencies already. It will fail upon require. > Would patches for any of this kind of stuff be accepted? (as non- > defaulted > options, of course) Yes. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From darix at web.de Thu Oct 25 07:29:10 2007 From: darix at web.de (Marcus Rueckert) Date: Thu, 25 Oct 2007 13:29:10 +0200 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <13A21272-E2AB-4334-97EA-4A6290E68049@segment7.net> References: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> <13A21272-E2AB-4334-97EA-4A6290E68049@segment7.net> Message-ID: <20071025112910.GE12137@pixel.global-banlist.de> On 2007-10-24 20:15:24 -0700, Eric Hodel wrote: > On Oct 24, 2007, at 20:08 , Brian Sammon wrote: > >>> That seems like an odd switch name then. I vote for '--ask- > >>> dependencies' > >>> instead. I would tuit '--ignore-dependencies' to mean 'just install > >>> the > >>> damn thing, don't try to grab the dependencies at all'. > >> > >> It means the latter. It will never ask before installing > >> dependencies anymore. > > > > Will the --ignore-dependencies option at least tell you what > > dependencies you > > have just ignored? > > `gem dep` will tell you that. > > > I would like to see the old behavior kept around as an option, or > > as an > > alternative/additional, a mode for it to behave like rpm/dpkg, and > > just fail > > verbosely if you don't have the dependencies already. > > It will fail upon require. > > > Would patches for any of this kind of stuff be accepted? (as non- > > defaulted > > options, of course) a package managing tool should never produce an inconsistent state. and missing dependencies are an inconsistent state. other package managers require a --force to break the system. i would call the flag --dependencies=[ask|ignore]. the --ignore-dependencies could be dropped. another improvement in that area would that it should list all dependencies at once and ask "do you want to install those 10 other gems to satisfy the dependencies?" that way you wouldnt have to say "y" 10 times as it was in the past. maybe if you move to a single question for all dependencies, it would be ok to revert to the old behavior of asking if a gem needs more gems. just my 2 cents darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From djberg96 at gmail.com Thu Oct 25 08:26:35 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 25 Oct 2007 06:26:35 -0600 Subject: [Rubygems-developers] Asking me for prerequisites In-Reply-To: <20071025112910.GE12137@pixel.global-banlist.de> References: <7524A45A1A5B264FA4809E2156496CFBE72F0C@ITOMAE2KM01.AD.QINTRA.COM> <6ECE5853-E2A5-4185-B67B-7421C93935C3@segment7.net> <13A21272-E2AB-4334-97EA-4A6290E68049@segment7.net> <20071025112910.GE12137@pixel.global-banlist.de> Message-ID: <47208B7B.6020203@gmail.com> Marcus Rueckert wrote: > On 2007-10-24 20:15:24 -0700, Eric Hodel wrote: >> On Oct 24, 2007, at 20:08 , Brian Sammon wrote: >>>>> That seems like an odd switch name then. I vote for '--ask- >>>>> dependencies' >>>>> instead. I would tuit '--ignore-dependencies' to mean 'just install >>>>> the >>>>> damn thing, don't try to grab the dependencies at all'. >>>> It means the latter. It will never ask before installing >>>> dependencies anymore. >>> Will the --ignore-dependencies option at least tell you what >>> dependencies you >>> have just ignored? >> `gem dep` will tell you that. >> >>> I would like to see the old behavior kept around as an option, or >>> as an >>> alternative/additional, a mode for it to behave like rpm/dpkg, and >>> just fail >>> verbosely if you don't have the dependencies already. >> It will fail upon require. >> >>> Would patches for any of this kind of stuff be accepted? (as non- >>> defaulted >>> options, of course) > > a package managing tool should never produce an inconsistent state. and > missing dependencies are an inconsistent state. other package managers > require a --force to break the system. > > i would call the flag --dependencies=[ask|ignore]. the --ignore-dependencies > could be dropped. The CPAN shell (Perl) does ask|ignore|follow. > another improvement in that area would that it should list all > dependencies at once and ask "do you want to install those 10 other gems > to satisfy the dependencies?" that way you wouldnt have to say "y" 10 > times as it was in the past. maybe if you move to a single question for > all dependencies, it would be ok to revert to the old behavior of asking > if a gem needs more gems. That would be the 'follow' option above. If such a thing doesn't already exist, I'll hack on it this weekend and see what I can come up with. Regards, Dan From djberg96 at gmail.com Fri Oct 26 23:56:11 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 26 Oct 2007 21:56:11 -0600 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet Message-ID: <4722B6DB.8000507@gmail.com> All, I uploaded a gem (for win32-api) using the current beta. Do NOT do that!!! Now people are seeing this error: $ gem list --remote rails *** REMOTE GEMS *** Bulk updating Gem source index for: http://gems.rubyforge.org ERROR: While executing gem ... (TypeError) can't instantiate uninitialized class I've deleted the gems and Tom is recreating the index as I write this. Just shoot me. Dan From tom at infoether.com Sat Oct 27 00:01:31 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 27 Oct 2007 00:01:31 -0400 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet In-Reply-To: <4722B6DB.8000507@gmail.com> References: <4722B6DB.8000507@gmail.com> Message-ID: <1193457691.8756.23.camel@bugs.hal> On Fri, 2007-10-26 at 21:56 -0600, Daniel Berger wrote: > All, > > I uploaded a gem (for win32-api) using the current beta. > > Do NOT do that!!! > > Now people are seeing this error: > > $ gem list --remote rails > *** REMOTE GEMS *** > Bulk updating Gem source index for: http://gems.rubyforge.org > ERROR: While executing gem ... (TypeError) can't instantiate > uninitialized class > > I've deleted the gems and Tom is recreating the index as I write this. > > Just shoot me. Actually, maybe it's my fault - Eric, I'm using the indexer from a RubyGems trunk checkout from a few weeks ago; if I do an "svn up" will that help? Yours, Tom From tom at infoether.com Sat Oct 27 00:07:32 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 27 Oct 2007 00:07:32 -0400 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet In-Reply-To: <1193457691.8756.23.camel@bugs.hal> References: <4722B6DB.8000507@gmail.com> <1193457691.8756.23.camel@bugs.hal> Message-ID: <1193458052.8756.26.camel@bugs.hal> On Sat, 2007-10-27 at 00:01 -0400, Tom Copeland wrote: > On Fri, 2007-10-26 at 21:56 -0600, Daniel Berger wrote: > > All, > > > > I uploaded a gem (for win32-api) using the current beta. > > > > Do NOT do that!!! > > > > Now people are seeing this error: > > > > $ gem list --remote rails > > *** REMOTE GEMS *** > > Bulk updating Gem source index for: http://gems.rubyforge.org > > ERROR: While executing gem ... (TypeError) can't instantiate > > uninitialized class > > > > I've deleted the gems and Tom is recreating the index as I write this. > > > > Just shoot me. > > Actually, maybe it's my fault - Eric, I'm using the indexer from a > RubyGems trunk checkout from a few weeks ago; if I do an "svn up" will > that help? > In the meantime, I've disabled gem index rebuilds on RubyForge, so no new gems will be deployed there until we sort this out. That way at least the current index will stay up... Yours, tom From luislavena at gmail.com Sat Oct 27 00:08:22 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 27 Oct 2007 01:08:22 -0300 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet In-Reply-To: <4722B6DB.8000507@gmail.com> References: <4722B6DB.8000507@gmail.com> Message-ID: <71166b3b0710262108g2fe027afva02d827321d8db78@mail.gmail.com> On 10/27/07, Daniel Berger wrote: > All, > > I uploaded a gem (for win32-api) using the current beta. > > Do NOT do that!!! > I forgot to mention that! :P I was testing it locally against a gem server when the light go off at the office... power issues in the whole city... the heat we had today was the cause. Anyway, found that problem but forgot to log about it when returned home. The change between 0.9.4 and 0.9.5 is too radical to be a point-point release... should be 0.10 :D > Just shoot me. > No Dan, some laws forbid that... Besides, I almost did that last week... :P -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From djberg96 at gmail.com Sat Oct 27 11:24:04 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 27 Oct 2007 09:24:04 -0600 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 Message-ID: <47235814.4040609@gmail.com> Hi all, I was thinking about the gem compatibility issue some more. I guess the first question is whether or not we can ensure that 0.9.4 can handle gems built with 0.9.5 or later. Can we do that? If not, what about the possibility of catching this error? ERROR: While executing gem ... (TypeError) can't instantiate uninitialized class If we can catch that error, we could then: 1) Skip that gem and emit a warning indicating that the user should upgrade or they won't be able to install certain gems. 2) Automatically upgrade the user's version of rubygems (with a warning). 3) Provide the option to upgrade to the latest rubygems. If they say yes, upgrade rubygems and start again. If no, skip any troublesome gems and emit a warning. Thoughts? Dan From transfire at gmail.com Sun Oct 28 13:29:36 2007 From: transfire at gmail.com (Trans) Date: Sun, 28 Oct 2007 13:29:36 -0400 Subject: [Rubygems-developers] autoload Message-ID: <4b6f054f0710281029y36bd5884kdd315058f77c3131@mail.gmail.com> I just discovered an interesting problem with overriding Kernel#require. Because RUbyGems does this it is likewise effected. Make sure you 'redcloth' installed via the gem and then try this: require 'rubygems' require 'redcloth' p RedCloth Works fine. Now this: require 'rubygems' autoload(:RedCloth, 'redcloth') p RedCloth And I get: no such file to load -- redcloth (LoadError) It fails to find redcloth; apparently b/c the autoload trigger is using it's own require code and not any of the overridable methods (I've tried Kernel.require, Kernel#require and the load methods for that matter). Hopefully I've missed something, and there is a simple remedy to this. T. 7rans BE HELP: http://manumission.info From nakahiro at sarion.co.jp Sun Oct 28 21:40:16 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Mon, 29 Oct 2007 10:40:16 +0900 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet In-Reply-To: <1193458052.8756.26.camel@bugs.hal> References: <4722B6DB.8000507@gmail.com> <1193457691.8756.23.camel@bugs.hal> <1193458052.8756.26.camel@bugs.hal> Message-ID: <47253A00.8020802@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm not the person who should ask it. I was just curious... Tom Copeland wrote: >>> $ gem list --remote rails >>> *** REMOTE GEMS *** >>> Bulk updating Gem source index for: http://gems.rubyforge.org >>> ERROR: While executing gem ... (TypeError) can't instantiate >>> uninitialized class >>> >>> I've deleted the gems and Tom is recreating the index as I write this. >>> >>> Just shoot me. >> Actually, maybe it's my fault - Eric, I'm using the indexer from a >> RubyGems trunk checkout from a few weeks ago; if I do an "svn up" will >> that help? > > In the meantime, I've disabled gem index rebuilds on RubyForge, so no > new gems will be deployed there until we sort this out. That way at > least the current index will stay up... Still have the problem? Can you show me an actual gem of win32-api and the gems index that caused the problem? I created a soap4r gem and gems index with svn trunk (0.9.4.6?) but I can install it with 0.9.4. On the machine that uses 0.9.4, loading the Marshal index 'Marshal.4.8' caused an error but I think source_index.rb in 0.9.4 doesn't try to fetch the Marshal gem index. And the error I got is different from the one Dan got. How I can get the TypeError above? I've just gave a quick look on source so I may be wrong. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRyU5/x9L2jg5EEGlAQKWpgf/cteKve3B8gQIt8SK3Qn5f7cGT705/UOC nfWbxT/ji8AafG648tkB3p6vc4f6Je/ib+eVBb3BqXOhfg45BgnhdPNqYThJbh7a ahOvWdR884hMf96ew1WpblNX9uZ9D37LW40UumKOjfBmndjNFpidwCMXdRZJdOQS Bt8W9YWUY2FgfAYUkj5Vlp7oKn/Gq1pNtG8Fyx0WZhL6Q7UFwhLli9p4TKrmTy/H 2E3N/Ud34x13JxBd+qH7Xlf7mmo/wnpInbHbHQMlHLd+reo56H0ynaoOvzx3XSP9 Y0v9MMYs3qKlleIEkyf9cJ4e0ObOKGyn8fm48sxdsJBF3ibCYqQ5Bw== =07Bz -----END PGP SIGNATURE----- From nakahiro at sarion.co.jp Sun Oct 28 22:55:56 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Mon, 29 Oct 2007 11:55:56 +0900 Subject: [Rubygems-developers] autoload In-Reply-To: <4b6f054f0710281029y36bd5884kdd315058f77c3131@mail.gmail.com> References: <4b6f054f0710281029y36bd5884kdd315058f77c3131@mail.gmail.com> Message-ID: <47254BBC.9030301@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Trans wrote: > I just discovered an interesting problem with overriding > Kernel#require. Because RUbyGems does this it is likewise effected. > > Make sure you 'redcloth' installed via the gem and then try this: > > require 'rubygems' > require 'redcloth' > p RedCloth > > Works fine. Now this: > > require 'rubygems' gem 'redcloth' > autoload(:RedCloth, 'redcloth') > p RedCloth > It fails to find redcloth; apparently b/c the autoload trigger is > using it's own require code and not any of the overridable methods > (I've tried Kernel.require, Kernel#require and the load methods for > that matter). Sure. Why don't you ask this on ruby-core? Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRyVLux9L2jg5EEGlAQImmQf/Y5M4pOz74+0jwNqt6o6B8LabtoeUirlr qsHCCfMnstvy0XHS6NHZi8kA0ZlgtglQerFkD1TN7m2u6h87vLTew8HEaYJxTTSL pMg6+SkG+hlrpDSDGKe1fen9yfNQDRTtr9QliLXpBE24Bwwl/wnxI33hqerA5oHm je0UiCN4zqm33nDaDqMneZfwd+WdIawGLf4dgnuRJZiBVb3+1HsEd41HZxOW7RPi 6ZBnXSsdsRWxEXzs5grHsjYRSTsU45N6qUUHgNQqL705edKrul4AtUh+XrnB75U7 YKGcnr2rI+Yscea064WIthNhzTZT4RSEmUCH8iLCtgAcULjERp2cvw== =KLBx -----END PGP SIGNATURE----- From transfire at gmail.com Sun Oct 28 23:11:56 2007 From: transfire at gmail.com (Trans) Date: Sun, 28 Oct 2007 23:11:56 -0400 Subject: [Rubygems-developers] autoload In-Reply-To: <47254BBC.9030301@sarion.co.jp> References: <4b6f054f0710281029y36bd5884kdd315058f77c3131@mail.gmail.com> <47254BBC.9030301@sarion.co.jp> Message-ID: <4b6f054f0710282011r47655e66la2ef1841460605ec@mail.gmail.com> On 10/28/07, NAKAMURA, Hiroshi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > Trans wrote: > > I just discovered an interesting problem with overriding > > Kernel#require. Because RUbyGems does this it is likewise effected. > > > > Make sure you 'redcloth' installed via the gem and then try this: > > > > require 'rubygems' > > require 'redcloth' > > p RedCloth > > > > Works fine. Now this: > > > > require 'rubygems' > > gem 'redcloth' > > > autoload(:RedCloth, 'redcloth') > > p RedCloth > > > It fails to find redcloth; apparently b/c the autoload trigger is > > using it's own require code and not any of the overridable methods > > (I've tried Kernel.require, Kernel#require and the load methods for > > that matter). > > Sure. Why don't you ask this on ruby-core? Yes, I would, except I no longer subscribe to that list -- I got tired of being berated for not discussing "appropriate" ruby-core topic every time I clicked send. I'll mention on ruby-talk though. T. From nakahiro at sarion.co.jp Mon Oct 29 10:37:20 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Mon, 29 Oct 2007 23:37:20 +0900 Subject: [Rubygems-developers] Warning: Don't upload gems made with the beta yet In-Reply-To: <47253A00.8020802@sarion.co.jp> References: <4722B6DB.8000507@gmail.com> <1193457691.8756.23.camel@bugs.hal> <1193458052.8756.26.camel@bugs.hal> <47253A00.8020802@sarion.co.jp> Message-ID: <4725F020.9040602@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, NAKAMURA, Hiroshi wrote: > Still have the problem? Can you show me an actual gem of win32-api and > the gems index that caused the problem? > > I created a soap4r gem and gems index with svn trunk (0.9.4.6?) but I > can install it with 0.9.4. On the machine that uses 0.9.4, loading the > Marshal index 'Marshal.4.8' caused an error but I think source_index.rb > in 0.9.4 doesn't try to fetch the Marshal gem index. And the error I > got is different from the one Dan got. How I can get the TypeError above? Reply to myself with a quicky patch. Request for review. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRyXwHx9L2jg5EEGlAQLFagf+PaLKFSKgjXl86mNbCcCcBtboXOrmth/d kT1s+zg4eMj6fV7gos028WfTgZDYvzTh3UQ6WVWb6reX76StZlINEIlI6oMEuUlB 82j5uy1+Y9P0jcM5bxAyOfb/i6O55ppD3D3VbJkCtHJUp8MU0VAdTN2WZvM27vyX Tn8K3IqeJ5aDrNcjNf/qQT7Khf4eOtsFofX6UTRETMLAqij+TRueYAi03dTnw01q iJWlO54Dbtwq5W+b2tI0GBX9RQQ3Lxa2eZcYb/uIauHHcjM6T4sexg20ry0vF87o AT7gt8kU0tz2lZ+nX/bnuhAfRjpUQ+0kFTLpckcNOId5G12SN2WjxQ== =YiER -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: platform.diff Url: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071029/4f405479/attachment.pl From drbrain at segment7.net Mon Oct 29 13:55:21 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 29 Oct 2007 10:55:21 -0700 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <47235814.4040609@gmail.com> References: <47235814.4040609@gmail.com> Message-ID: <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> On Oct 27, 2007, at 08:24 , Daniel Berger wrote: > I was thinking about the gem compatibility issue some more. I > guess the > first question is whether or not we can ensure that 0.9.4 can handle > gems built with 0.9.5 or later. Can we do that? > > If not, what about the possibility of catching this error? > > ERROR: While executing gem ... (TypeError) > can't instantiate uninitialized class This is because Gem::Platform is a class now, right? I can patch up Gem::Specification to make it backwards compatible. It looks like the release of 0.9.5 will be delayed until post- RubyConf. I have to work on my presentation. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From tom at infoether.com Mon Oct 29 20:46:31 2007 From: tom at infoether.com (Tom Copeland) Date: Mon, 29 Oct 2007 20:46:31 -0400 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> Message-ID: <1193705191.3933.2.camel@bugs.hal> On Mon, 2007-10-29 at 10:55 -0700, Eric Hodel wrote: > On Oct 27, 2007, at 08:24 , Daniel Berger wrote: > > I was thinking about the gem compatibility issue some more. I > > guess the > > first question is whether or not we can ensure that 0.9.4 can handle > > gems built with 0.9.5 or later. Can we do that? > > > > If not, what about the possibility of catching this error? > > > > ERROR: While executing gem ... (TypeError) > > can't instantiate uninitialized class > > This is because Gem::Platform is a class now, right? I can patch up > Gem::Specification to make it backwards compatible. > > It looks like the release of 0.9.5 will be delayed until post- > RubyConf. I have to work on my presentation. Hm, is there some way we can tweak the gem index to skip these or something? Right now I've disabled gem index rebuilds to prevent someone from releasing a gem and accidentally breaking the index for everyone... Thanks, Tom From luislavena at gmail.com Mon Oct 29 20:53:27 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 29 Oct 2007 21:53:27 -0300 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <1193705191.3933.2.camel@bugs.hal> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> Message-ID: <71166b3b0710291753t5886b91bqe7bead0089e912ef@mail.gmail.com> On 10/29/07, Tom Copeland wrote: > On Mon, 2007-10-29 at 10:55 -0700, Eric Hodel wrote: > > On Oct 27, 2007, at 08:24 , Daniel Berger wrote: > > > I was thinking about the gem compatibility issue some more. I > > > guess the > > > first question is whether or not we can ensure that 0.9.4 can handle > > > gems built with 0.9.5 or later. Can we do that? > > > > > > If not, what about the possibility of catching this error? > > > > > > ERROR: While executing gem ... (TypeError) > > > can't instantiate uninitialized class > > > > This is because Gem::Platform is a class now, right? I can patch up > > Gem::Specification to make it backwards compatible. > > > > It looks like the release of 0.9.5 will be delayed until post- > > RubyConf. I have to work on my presentation. > > Hm, is there some way we can tweak the gem index to skip these or > something? Right now I've disabled gem index rebuilds to prevent > someone from releasing a gem and accidentally breaking the index for > everyone... > Tom, it seems only happens when trying to install gems build for Gem::Platform::CURRENT, since Platform is now a Class instead of String with previous version. To summarize, this only affects gems with platform like x86-mswin32-60 or x86-mswin32-80, since all the ::RUBY platforms remains the same (Evan Weaver confirmed this on #irc today when talking about it). If you put a gem with 0.9.4.6 specification, it brake the indexing process? I guess not. Also, Hiroshi proposed a patch [1] to workaround this issue from the 'gem' side. Since I really don't know the exact setup where you create the index, could provide more info? [1] http://rubyforge.org/pipermail/rubygems-developers/2007-October/003146.html -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi From avatar at spellboundnet.com Mon Oct 29 21:11:32 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Mon, 29 Oct 2007 21:11:32 -0400 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <200710231721.01708.avatar@spellboundnet.com> References: <200710210914.59312.avatar@spellboundnet.com> <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> <200710231721.01708.avatar@spellboundnet.com> Message-ID: <200710292111.32989.avatar@spellboundnet.com> On Tuesday 23 October 2007 05:21:01 pm Donavan Pantke wrote: > On Monday 22 October 2007 11:44:52 am Eric Hodel wrote: > > On Oct 22, 2007, at 03:42 , Marcus Rueckert wrote: > > > On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: > > >> What you propose sounds no different than setting GEM_PATH > > >> appropriately. > > > > > > 1. could you give an example how it could look like? > > > > > > how would you install gems into the vendor dir so the user can find > > > them? > > > > gem install -i /path/to/vendor/gems > > > > echo export GEM_PATH=/path/to/vendor/gems:/path/to/gem/home >> /etc/ > > profile > > Perhaps. I don't have a full workstation up, does a gem list -l list all > gems in GEM_PATH? The idea here is to make the vendor are as seemless to > the end user as possible. > > > > how can you get gem to treat the vendor dir as read only unless > > > passed a --vendor option (just an example) with the GEM_PATH > > > solution? > > > > The regular permissions system handles this just fine: > > > > sudo gem install -i /path/to/vendor/gems > > I'm not keen on letting the permission system handle this, since there are > definitely cases I can think of where a user might sudo a gem command and > still mess up the vendor area. However, the GEM_PATH solution may still > work. Is it possible for us to say that any modifications to gems MUST be > done inside GEM_HOME? That is, no deletes or additions could be made to > other directories in GEM_PATH, only in GEM_HOME. Pardon me if the code > works this way already, as I said I'm not where I could test it myself > right now. :) > > > > 2. using the environment variable has the disadvantage that the > > > user can > > > break it. while an additional path hardcoded in the config of gem > > > cant be lost that easily. > > > > Is PATH immune from this problem? > > No, but a better analogy would be setting LD_LIBRARY_PATH. And on most > systems, we try to avoid doing that as best as possible. Same should be > with Gems. > > So, I'm thinking that judicious use of GEM_PATH may be a good solution > here, we just want to try and get that behavior the way we would like it. Okay, I think I figured it out. There are 2 patches in the tracker for these: 15150 and 15151. One patch makes it easier for repackagers to specify the hard defaults for paths. It's possible that setup.rb could be extended to produce the defaults, but having a separate defaults.rb will help with either case. The second patch will require a user prompt or --force if the gem resides in somewhere in GEM_PATH but not in GEM_HOME. This should help people to not accidentally remove things that aren't in GEM_HOME. File permissions are the ultimate decider on if someone can uninstall or not, which true with both GEM_HOME and GEM_PATH, and is as it should be. Marcus, do you think that this would work well for the opensuse builds of gems? Thanks! Donavan From tom at infoether.com Mon Oct 29 21:58:31 2007 From: tom at infoether.com (Tom Copeland) Date: Mon, 29 Oct 2007 21:58:31 -0400 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <71166b3b0710291753t5886b91bqe7bead0089e912ef@mail.gmail.com> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> <71166b3b0710291753t5886b91bqe7bead0089e912ef@mail.gmail.com> Message-ID: <1193709511.3933.7.camel@bugs.hal> On Mon, 2007-10-29 at 21:53 -0300, Luis Lavena wrote: > > Hm, is there some way we can tweak the gem index to skip these or > > something? Right now I've disabled gem index rebuilds to prevent > > someone from releasing a gem and accidentally breaking the index for > > everyone... > > > > Tom, it seems only happens when trying to install gems build for > Gem::Platform::CURRENT, since Platform is now a Class instead of > String with previous version. > > To summarize, this only affects gems with platform like x86-mswin32-60 > or x86-mswin32-80, since all the ::RUBY platforms remains the same > > (Evan Weaver confirmed this on #irc today when talking about it). Hi Luis - Ah, OK, cool, thanks for the info. > If you put a gem with 0.9.4.6 specification, it brake the indexing > process? I guess not. Hm, that sounds right, although I haven't tried it. > Also, Hiroshi proposed a patch [1] to workaround this issue from the 'gem' side. > > Since I really don't know the exact setup where you create the index, > could provide more info? I just call GemIndexer::new.generate_index: http://rubygems.rubyforge.org/svn/trunk/lib/rubygems/indexer.rb Yours, Tom From darix at web.de Mon Oct 29 22:22:51 2007 From: darix at web.de (Marcus Rueckert) Date: Tue, 30 Oct 2007 03:22:51 +0100 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <200710292111.32989.avatar@spellboundnet.com> References: <200710210914.59312.avatar@spellboundnet.com> <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> <200710231721.01708.avatar@spellboundnet.com> <200710292111.32989.avatar@spellboundnet.com> Message-ID: <20071030022251.GB4383@pixel.global-banlist.de> On 2007-10-29 21:11:32 -0400, Donavan Pantke wrote: > Date: Mon, 29 Oct 2007 21:11:32 -0400 > On Tuesday 23 October 2007 05:21:01 pm Donavan Pantke wrote: > > On Monday 22 October 2007 11:44:52 am Eric Hodel wrote: > > > On Oct 22, 2007, at 03:42 , Marcus Rueckert wrote: > > > > On 2007-10-21 20:39:05 -0700, Eric Hodel wrote: > > > >> What you propose sounds no different than setting GEM_PATH > > > >> appropriately. > > > > > > > > 1. could you give an example how it could look like? > > > > > > > > how would you install gems into the vendor dir so the user can find > > > > them? > > > > > > gem install -i /path/to/vendor/gems > > > > > > echo export GEM_PATH=/path/to/vendor/gems:/path/to/gem/home >> /etc/ > > > profile > > > > Perhaps. I don't have a full workstation up, does a gem list -l list all > > gems in GEM_PATH? The idea here is to make the vendor are as seemless to > > the end user as possible. > > > > > > how can you get gem to treat the vendor dir as read only unless > > > > passed a --vendor option (just an example) with the GEM_PATH > > > > solution? > > > > > > The regular permissions system handles this just fine: > > > > > > sudo gem install -i /path/to/vendor/gems > > > > I'm not keen on letting the permission system handle this, since there are > > definitely cases I can think of where a user might sudo a gem command and > > still mess up the vendor area. However, the GEM_PATH solution may still > > work. Is it possible for us to say that any modifications to gems MUST be > > done inside GEM_HOME? That is, no deletes or additions could be made to > > other directories in GEM_PATH, only in GEM_HOME. Pardon me if the code > > works this way already, as I said I'm not where I could test it myself > > right now. :) > > > > > > 2. using the environment variable has the disadvantage that the > > > > user can > > > > break it. while an additional path hardcoded in the config of gem > > > > cant be lost that easily. > > > > > > Is PATH immune from this problem? > > > > No, but a better analogy would be setting LD_LIBRARY_PATH. And on most > > systems, we try to avoid doing that as best as possible. Same should be > > with Gems. > > > > So, I'm thinking that judicious use of GEM_PATH may be a good solution > > here, we just want to try and get that behavior the way we would like it. > > Okay, I think I figured it out. There are 2 patches in the tracker for these: > 15150 and 15151. One patch makes it easier for repackagers to specify the > hard defaults for paths. It's possible that setup.rb could be extended to > produce the defaults, but having a separate defaults.rb will help with either > case. The second patch will require a user prompt or --force if the gem > resides in somewhere in GEM_PATH but not in GEM_HOME. This should help people > to not accidentally remove things that aren't in GEM_HOME. File permissions > are the ultimate decider on if someone can uninstall or not, which true with > both GEM_HOME and GEM_PATH, and is as it should be. > > Marcus, do you think that this would work well for the opensuse builds of > gems? sounds good!:) darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From drbrain at segment7.net Tue Oct 30 05:13:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 30 Oct 2007 02:13:50 -0700 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <1193705191.3933.2.camel@bugs.hal> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> Message-ID: On Oct 29, 2007, at 17:46 , Tom Copeland wrote: > On Mon, 2007-10-29 at 10:55 -0700, Eric Hodel wrote: >> On Oct 27, 2007, at 08:24 , Daniel Berger wrote: >>> I was thinking about the gem compatibility issue some more. I >>> guess the >>> first question is whether or not we can ensure that 0.9.4 can handle >>> gems built with 0.9.5 or later. Can we do that? >>> >>> If not, what about the possibility of catching this error? >>> >>> ERROR: While executing gem ... (TypeError) >>> can't instantiate uninitialized class >> >> This is because Gem::Platform is a class now, right? I can patch up >> Gem::Specification to make it backwards compatible. >> >> It looks like the release of 0.9.5 will be delayed until post- >> RubyConf. I have to work on my presentation. > > Hm, is there some way we can tweak the gem index to skip these or > something? Right now I've disabled gem index rebuilds to prevent > someone from releasing a gem and accidentally breaking the index for > everyone... My proposed change should fix the indexer too. I'll test and commit tomorrow. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars From tom at infoether.com Tue Oct 30 09:35:14 2007 From: tom at infoether.com (Tom Copeland) Date: Tue, 30 Oct 2007 09:35:14 -0400 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> Message-ID: <1193751314.3933.26.camel@bugs.hal> On Tue, 2007-10-30 at 02:13 -0700, Eric Hodel wrote: > My proposed change should fix the indexer too. I'll test and commit > tomorrow. Sounds great! Yours, Tom From drbrain at segment7.net Wed Oct 31 03:23:59 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 31 Oct 2007 00:23:59 -0700 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <1193751314.3933.26.camel@bugs.hal> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> <1193751314.3933.26.camel@bugs.hal> Message-ID: <0C64E96D-4CD1-45E8-9434-F9854073E683@segment7.net> On Oct 30, 2007, at 06:35 , Tom Copeland wrote: > On Tue, 2007-10-30 at 02:13 -0700, Eric Hodel wrote: >> My proposed change should fix the indexer too. I'll test and commit >> tomorrow. > > Sounds great! I've got a patch in similar in spirit to Hiroshi's, but haven't tested indexing w/ 0.9.4 yet. Depending upon how much I get done on my presentation, I'll have this tested either tomorrow evening, or Thursday traveling to RubyConf. -- Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them. -- Syndicate Wars