From drbrain at segment7.net Thu Nov 1 01:19:33 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 31 Oct 2007 22:19:33 -0700 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> <20071022104211.GJ3589@pixel.global-banlist.de> <83415B96-46F9-415B-8C1D-936A3ACD34BB@segment7.net> <200710231721.01708.avatar@spellboundnet.com> Message-ID: <4531727E-81E6-4B9F-9193-67D939E883D3@segment7.net> On Oct 23, 2007, at 14:21 , 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. If it doesn't that's a bug. >>> 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. :) Is this something they couldn't do with rm? GEM_HOME is the default directory. If they specify some other path specifically, they can shoot themselves in the foot, just like with rm. >>> 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. I can't read your mind to know what you want. Test it out and see if it is suitable. -- 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 Thu Nov 1 18:21:23 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Thu, 1 Nov 2007 18:21:23 -0400 Subject: [Rubygems-developers] VENDOR_HOME (Was: Finding where gems are stored) In-Reply-To: <4531727E-81E6-4B9F-9193-67D939E883D3@segment7.net> References: <200710210914.59312.avatar@spellboundnet.com> <200710231721.01708.avatar@spellboundnet.com> <4531727E-81E6-4B9F-9193-67D939E883D3@segment7.net> Message-ID: <200711011821.23369.avatar@spellboundnet.com> On Thursday 01 November 2007 01:19:33 am Eric Hodel wrote: > On Oct 23, 2007, at 14:21 , 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. > > If it doesn't that's a bug. > > >>> 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. :) > > Is this something they couldn't do with rm? > > GEM_HOME is the default directory. If they specify some other path > specifically, they can shoot themselves in the foot, just like with rm. > > >>> 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. > > I can't read your mind to know what you want. Test it out and see if > it is suitable. > The gem path solution works well. I've added a couple of patches to the tracker that will warn users about uninstalling stuff outside of GEM_HOME and help repackagers redefine the stock locations if they need to and consider using the environment overrides to not be reliable enough. Thanks! Donavan From drbrain at segment7.net Thu Nov 1 23:55:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 1 Nov 2007 20:55:50 -0700 Subject: [Rubygems-developers] OSX 10.5 patch In-Reply-To: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> References: <1be7247c0710230643yb948704q86d2e3e62d8ee050@mail.gmail.com> Message-ID: <9F0DC2E1-FE3D-4227-8F46-0D8A2C81BBA7@segment7.net> On Oct 23, 2007, at 06:43 , 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. > > 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. I am not fond of this part of the patch, since GEM_PATH avoids special casing per ruby/rubygems packager. > The third change-set simply adds the ruby version to the default gem > directory, which was probably an omission. Is this backwards compatible with 10.4 and earlier? I don't know much about frameworkized ruby on OS X. > 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. -- 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 Nov 1 23:55:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 1 Nov 2007 20:55:50 -0700 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> References: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> Message-ID: On Oct 23, 2007, at 13:20 , Luis Lavena wrote: > 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). I think this is a bug. RubyGems should check to see if the file has a #! before turning it into garbage. If it doesn't have a #! (is binary) then it should be installed via copying instead. -- 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 Nov 1 23:55:52 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 1 Nov 2007 20:55:52 -0700 Subject: [Rubygems-developers] gemloader.rb In-Reply-To: <471BF77E.9020904@sarion.co.jp> References: <471A262A.5040407@sarion.co.jp> <471BF77E.9020904@sarion.co.jp> Message-ID: On Oct 21, 2007, at 18:06 , NAKAMURA, Hiroshi wrote: > 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'? They are needed for 3. >> 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? This is fixed in latest RubyGems. If the LoadError file does not match the original feature, the exception is re-raised immediately. >> 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? Yes. > 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. require will always try 'foo.rb' or similar, bin path files are loaded with #load, instead. It is a cheap trick. $ echo 'puts "foo"' > foo $ echo 'puts "foo.rb"' > foo.rb $ ruby -rfoo -e0 foo.rb $ ruby -e 'load "foo"' foo -- 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 nakahiro at sarion.co.jp Fri Nov 2 08:00:59 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Fri, 02 Nov 2007 21:00:59 +0900 Subject: [Rubygems-developers] gemloader.rb In-Reply-To: References: <471A262A.5040407@sarion.co.jp> <471BF77E.9020904@sarion.co.jp> Message-ID: <472B117B.5040408@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eric Hodel wrote: > On Oct 21, 2007, at 18:06 , NAKAMURA, Hiroshi wrote: >> 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'? > > They are needed for 3. Sure. But they (requirement.rb and version.rb) does not need other features, right? I just mean version.rb.diff can be applied. Third party product may want to use Gem::Requirement and Gem::Version. >>> 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? > > This is fixed in latest RubyGems. If the LoadError file does not > match the original feature, the exception is re-raised immediately. Sorry, I was not aware the change. Hmm. Isn't that a bit too strict? Gem A depends to Gem B, but the author of Gem A accidently removed a dependency to Gem B from its gemspec. Now users get a LoadError even though they actually have a Gem B. Right? >>> 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? > > Yes. Thanks. >> 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. > > require will always try 'foo.rb' or similar, bin path files are > loaded with #load, instead. It is a cheap trick. > > $ echo 'puts "foo"' > foo > $ echo 'puts "foo.rb"' > foo.rb > $ ruby -rfoo -e0 > foo.rb > $ ruby -e 'load "foo"' > foo But if there're bin/foo.rb in bindir and lib/foo.rb in require_path? Gem wrapper surely loads foo.rb in bindir because spec.bindir is unshifted to $LOAD_PATH. But 'require "foo"' in a program loads 'foo.rb' in bindir I think. Correct me if I misunderstand something. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRysReR9L2jg5EEGlAQKj/AgAgI+HQmz3dDn6yVaE8Bu+Z1UQNXk5VYpr 8WtvdXlFshvfnFW8B2YHjP5/ZyoCvbEN9qMIpewwwRWZmMMqOFEX4oiLQ7K6BbEu p5DICA9rb7eYxtK/x7W7L6Dwp15kc6sq7t0e0mrerF4GUSDwPoU+wHszpMPkaJ3a GLuhrcxT+0nR+eyY9jcF5536srBy6wLbCABqfbd5gjOcZGF5z2nbzlHvb/D76Ah3 +hhZ+mKK5v52fl0fpNunplrLRCrEYHXEHmwoIsiHulxymdgZXfsj0ErI/S2oBylA oGnXGwCm6GXkVB+8Q7WrljCRDbajNVvTQ6hjER5GxfE5izanZSaL/A== =sgUb -----END PGP SIGNATURE----- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: version.rb.diff Url: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071102/cb648a17/attachment.pl From luislavena at gmail.com Fri Nov 2 11:00:45 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 2 Nov 2007 12:00:45 -0300 Subject: [Rubygems-developers] RubyGems don't like binaries for executables In-Reply-To: References: <71166b3b0710231320o5b2c0a68ifb850c74b4d66350@mail.gmail.com> Message-ID: <71166b3b0711020800l33c72d3g8442dea811f66e1b@mail.gmail.com> On 11/2/07, Eric Hodel wrote: > On Oct 23, 2007, at 13:20 , Luis Lavena wrote: > > 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). > > I think this is a bug. RubyGems should check to see if the file has > a #! before turning it into garbage. If it doesn't have a #! (is > binary) then it should be installed via copying instead. > Ok then, when I return to home will patch it. 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 nakahiro at sarion.co.jp Sat Nov 3 05:43:08 2007 From: nakahiro at sarion.co.jp (NAKAMURA, Hiroshi) Date: Sat, 03 Nov 2007 18:43:08 +0900 Subject: [Rubygems-developers] gemloader.rb In-Reply-To: <472B117B.5040408@sarion.co.jp> References: <471A262A.5040407@sarion.co.jp> <471BF77E.9020904@sarion.co.jp> <472B117B.5040408@sarion.co.jp> Message-ID: <472C42AC.1030207@sarion.co.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again, NAKAMURA, Hiroshi wrote: >> This is fixed in latest RubyGems. If the LoadError file does not >> match the original feature, the exception is re-raised immediately. > > Sorry, I was not aware the change. > > Hmm. Isn't that a bit too strict? Gem A depends to Gem B, but the > author of Gem A accidently removed a dependency to Gem B from its > gemspec. Now users get a LoadError even though they actually have a Gem > B. Right? Never mind. I was wrong. Subsequent require should handle this situation as we expected. Regards, // NaHi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iQEVAwUBRyxBsh9L2jg5EEGlAQLJIgf+K/5BdaVDt9L8n1yr9wA8U9kefPZ7nF5d gFnGEwaTxlcnk6MzN+axyS0pJ644Iqg9c1JOMECMy7p1LSp4yqEk17Ptk9Gy9ta/ I6eGhz76gL7AQAwfmhAryUbknxo+FXasdezHYUTxgxzjptgD8ZhDQYB5QFR1EzxX xgINhUs55Sm+OrgcXmwitXkz+bH/ZiEarSQ7rd4GuwGXSxuvXxxyYhFudgeANREj zAi5dXJZeeqX7GXJW+n7zm20LnHQeLPh0ndeLqolqu+4U4WEKmoR6lQKOZ+o0xJ6 XH9OXj/O+uqi8upRgy7p4dw4NkCA+eFLK3hyoks5zqE5ya4ZLyS2qg== =TUVU -----END PGP SIGNATURE----- From drbrain at segment7.net Sat Nov 3 11:18:15 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 3 Nov 2007 08:18:15 -0700 Subject: [Rubygems-developers] gemloader.rb In-Reply-To: <472B117B.5040408@sarion.co.jp> References: <471A262A.5040407@sarion.co.jp> <471BF77E.9020904@sarion.co.jp> <472B117B.5040408@sarion.co.jp> Message-ID: On Nov 2, 2007, at 05:00 , NAKAMURA, Hiroshi wrote: > Eric Hodel wrote: >> On Oct 21, 2007, at 18:06 , NAKAMURA, Hiroshi wrote: >>> 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'? >> >> They are needed for 3. > > Sure. But they (requirement.rb and version.rb) does not need other > features, right? I just mean version.rb.diff can be applied. Third > party product may want to use Gem::Requirement and Gem::Version. Other than module Gem, correct. >>> 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. >> >> require will always try 'foo.rb' or similar, bin path files are >> loaded with #load, instead. It is a cheap trick. >> >> $ echo 'puts "foo"' > foo >> $ echo 'puts "foo.rb"' > foo.rb >> $ ruby -rfoo -e0 >> foo.rb >> $ ruby -e 'load "foo"' >> foo > > But if there're bin/foo.rb in bindir and lib/foo.rb in require_path? > Gem wrapper surely loads foo.rb in bindir because spec.bindir is > unshifted to $LOAD_PATH. But 'require "foo"' in a program loads > 'foo.rb' in bindir I think. Correct me if I misunderstand something. Yes, it would, but this has not been a problem in practice. I think it is an acceptable restriction on gem executables. -- 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 Sat Nov 3 17:24:27 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 03 Nov 2007 17:24:27 -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: <1194125067.30625.20.camel@bugs.hal> On Tue, 2007-10-30 at 02:13 -0700, Eric Hodel 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... > > My proposed change should fix the indexer too. I'll test and commit > tomorrow. Is this checked in? If so, I can get the latest code and start doing index rebuilds again... Thanks, Tom From rubygems-list at brisammon.fastmail.fm Sat Nov 3 17:27:40 2007 From: rubygems-list at brisammon.fastmail.fm (Brian Sammon) Date: Sat, 03 Nov 2007 17:27:40 -0400 Subject: [Rubygems-developers] rubygems over dialup Message-ID: Does anyone out there use rubygems over dialup? Am I correct in my understanding that it wants to download a 12MB index file before installing anything? I tried to install a package, and killed rubygems after 15 minutes because I was tired of waiting for it. Does anyone have any practical suggestions for using rubygems 0.9.4 with a dialup connection? Also, what about a progressbar feature? Is anyone working on that? From rubygems-list at brisammon.fastmail.fm Sat Nov 3 17:43:23 2007 From: rubygems-list at brisammon.fastmail.fm (Brian Sammon) Date: Sat, 03 Nov 2007 17:43:23 -0400 Subject: [Rubygems-developers] rubygems over dialup In-Reply-To: References: Message-ID: > Does anyone out there use rubygems over dialup? > Am I correct in my understanding that it wants to download a 12MB index file > before installing anything? > I tried to install a package, and killed rubygems after 15 minutes because I > was tired of waiting for it. > Does anyone have any practical suggestions for using rubygems 0.9.4 with a > dialup connection? Okay... "gem install -l ./package.gem" is pretty fast. > Also, what about a progressbar feature? Is anyone working on that? Currently gem (0.9.4) provides no feedback about what it's doing (or if it's doing anything) during the 12MB download. On a dialup connection, it looks like gem is hung. Perhaps this is the answer to the (currently unanswered) FAQ #3.2 (http://docs.rubygems.org/read/chapter/19#page96) From todd.fisher at gmail.com Sat Nov 3 21:19:27 2007 From: todd.fisher at gmail.com (Todd Fisher) Date: Sat, 3 Nov 2007 21:19:27 -0400 Subject: [Rubygems-developers] rubygems over dialup In-Reply-To: References: Message-ID: Also, all the gems have real URLs... if you know the path you can wget or curl the file directly and then install locally... -Todd On 11/3/07, Brian Sammon wrote: > > > Does anyone out there use rubygems over dialup? > > Am I correct in my understanding that it wants to download a 12MB index > file > > before installing anything? > > I tried to install a package, and killed rubygems after 15 minutes > because I > > was tired of waiting for it. > > Does anyone have any practical suggestions for using rubygems 0.9.4 with > a > > dialup connection? > > Okay... "gem install -l ./package.gem" is pretty fast. > > > Also, what about a progressbar feature? Is anyone working on that? > > Currently gem (0.9.4) provides no feedback about what it's doing (or if > it's > doing anything) during the 12MB download. On a dialup connection, it > looks > like gem is hung. > Perhaps this is the answer to the (currently unanswered) FAQ #3.2 > (http://docs.rubygems.org/read/chapter/19#page96) > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071103/29670683/attachment.html From drbrain at segment7.net Sat Nov 3 23:02:03 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 3 Nov 2007 20:02:03 -0700 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <1194125067.30625.20.camel@bugs.hal> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> <1194125067.30625.20.camel@bugs.hal> Message-ID: <4B9FB9D6-D85E-471A-BC6E-C0F0CE626674@segment7.net> On Nov 3, 2007, at 14:24 , Tom Copeland wrote: > On Tue, 2007-10-30 at 02:13 -0700, Eric Hodel 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... >> >> My proposed change should fix the indexer too. I'll test and commit >> tomorrow. > > Is this checked in? If so, I can get the latest code and start doing > index rebuilds again... It is. I don't know if it works, but I guess you could just test it for me :) -- 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 Sun Nov 4 21:18:04 2007 From: tom at infoether.com (Tom Copeland) Date: Sun, 04 Nov 2007 21:18:04 -0500 Subject: [Rubygems-developers] Transitioning from 0.9.4 to 0.9.5 In-Reply-To: <4B9FB9D6-D85E-471A-BC6E-C0F0CE626674@segment7.net> References: <47235814.4040609@gmail.com> <86053AB7-C03E-4C4B-AF69-B3451B0A6099@segment7.net> <1193705191.3933.2.camel@bugs.hal> <1194125067.30625.20.camel@bugs.hal> <4B9FB9D6-D85E-471A-BC6E-C0F0CE626674@segment7.net> Message-ID: <1194229084.30625.52.camel@bugs.hal> On Sat, 2007-11-03 at 20:02 -0700, Eric Hodel wrote: > On Nov 3, 2007, at 14:24 , Tom Copeland wrote: > > On Tue, 2007-10-30 at 02:13 -0700, Eric Hodel 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... > >> > >> My proposed change should fix the indexer too. I'll test and commit > >> tomorrow. > > > > Is this checked in? If so, I can get the latest code and start doing > > index rebuilds again... > > It is. I don't know if it works, but I guess you could just test it > for me :) I've rerun the gem index with this new code and all seems well. Thanks Eric! Yours, Tom From raasdnil at gmail.com Sun Nov 4 22:35:17 2007 From: raasdnil at gmail.com (Mikel Lindsaar) Date: Mon, 5 Nov 2007 14:35:17 +1100 Subject: [Rubygems-developers] How to bundle up MS Windows version separately Message-ID: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> Hello all, Please forgive the newbie question. I am wondering if anyone has a good link / resource / howto, whatever on how you make a windows gem or a different version so that you get this sort of output on gem install: Select which gem to install for your platform (i386-openbsd4.1) 1. hpricot 0.6 (mswin32) 2. hpricot 0.6 (jruby) 3. hpricot 0.6 (ruby) 4. ... I thought it might be as easy as naming the file with -mswin32 on the end.. but alas, I think I am incorrect. I looked through the rubygems docs on the website, and either one of two things happened. (1) I missed it due to lack of sleep (highly probably) (2) The answer is not there (less likely) If anyone could shine some light in this direction, that would be great! Thanks Mikel From assaph at gmail.com Sun Nov 4 22:41:49 2007 From: assaph at gmail.com (Assaph Mehr) Date: Mon, 5 Nov 2007 14:41:49 +1100 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> Message-ID: <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> Hi Mikel, > I am wondering if anyone has a good link / resource / howto, whatever > on how you make a windows gem or a different version so that you get > this sort of output on gem install: > > Select which gem to install for your platform (i386-openbsd4.1) > 1. hpricot 0.6 (mswin32) > 2. hpricot 0.6 (jruby) > 3. hpricot 0.6 (ruby) > 4. ... Look at: http://rubygems.org/read/chapter/20#platform Use the #platform directive of the gem specification to note the target platform. The default is Ruby. Cheers, Assaph From transfire at gmail.com Sun Nov 4 22:46:01 2007 From: transfire at gmail.com (Trans) Date: Sun, 4 Nov 2007 22:46:01 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> Message-ID: <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> On Nov 4, 2007 10:41 PM, Assaph Mehr wrote: > Hi Mikel, > > > > I am wondering if anyone has a good link / resource / howto, whatever > > on how you make a windows gem or a different version so that you get > > this sort of output on gem install: > > > > Select which gem to install for your platform (i386-openbsd4.1) > > 1. hpricot 0.6 (mswin32) > > 2. hpricot 0.6 (jruby) > > 3. hpricot 0.6 (ruby) > > 4. ... > > Look at: http://rubygems.org/read/chapter/20#platform > Use the #platform directive of the gem specification to note the > target platform. The default is Ruby. So essentially the best course of action is to pre-compile and create multiple gems for each platform? T. From transfire at gmail.com Mon Nov 5 06:03:58 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 06:03:58 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> Message-ID: <4b6f054f0711050303q75b9303fjd43e05957e26128d@mail.gmail.com> On Nov 4, 2007 10:41 PM, Assaph Mehr wrote: > Hi Mikel, > > > > I am wondering if anyone has a good link / resource / howto, whatever > > on how you make a windows gem or a different version so that you get > > this sort of output on gem install: > > > > Select which gem to install for your platform (i386-openbsd4.1) > > 1. hpricot 0.6 (mswin32) > > 2. hpricot 0.6 (jruby) > > 3. hpricot 0.6 (ruby) > > 4. ... > > Look at: http://rubygems.org/read/chapter/20#platform > Use the #platform directive of the gem specification to note the > target platform. The default is Ruby. I'm still confused by one thing. When I use setup.rb, it will compile extensions and I'll end with .so files located down in ext/ somewhere. For instacen with TMail: ext/tmail/base64/base64.so ext/tmail/scanner_c/scanner_c.so But when I create a gem how does gems know where to find the .so ? From luislavena at gmail.com Mon Nov 5 09:32:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 11:32:33 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711050303q75b9303fjd43e05957e26128d@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711050303q75b9303fjd43e05957e26128d@mail.gmail.com> Message-ID: <71166b3b0711050632y1f8ccdc6p4f31e37618c22668@mail.gmail.com> On 11/5/07, Trans wrote: > > I'm still confused by one thing. When I use setup.rb, it will compile > extensions and I'll end with .so files located down in ext/ somewhere. > For instacen with TMail: > > ext/tmail/base64/base64.so > ext/tmail/scanner_c/scanner_c.so > > But when I create a gem how does gems know where to find the .so ? On Mongrel we move the pre-compiled .so file to #{gem_name}/lib/ For the mswin32 platform, we use a conditional to pre-build the extension and bundle it in the gem (adding it to files) and removing from extensions to be compiled. This avoids RubyGems firing the build process for them and instead use the one we just compiled. As Assaph commented, using #platform allow your create gems tailored for each platform, but you require be on that platform unless you do some cross-platform sandboxing (which on my experience didn't work quite right). Take a look to the Mongrel Rakefile: http://mongrel.rubyforge.org/svn/trunk/Rakefile It uses Echoe, but you can go back in time and check how Zed was doing it previously. 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 luislavena at gmail.com Mon Nov 5 09:35:33 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 11:35:33 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> Message-ID: <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> On 11/5/07, Trans wrote: > On Nov 4, 2007 10:41 PM, Assaph Mehr wrote: > > Hi Mikel, > > > > > > > I am wondering if anyone has a good link / resource / howto, whatever > > > on how you make a windows gem or a different version so that you get > > > this sort of output on gem install: > > > > > > Select which gem to install for your platform (i386-openbsd4.1) > > > 1. hpricot 0.6 (mswin32) > > > 2. hpricot 0.6 (jruby) > > > 3. hpricot 0.6 (ruby) > > > 4. ... > > > > Look at: http://rubygems.org/read/chapter/20#platform > > Use the #platform directive of the gem specification to note the > > target platform. The default is Ruby. > > So essentially the best course of action is to pre-compile and create > multiple gems for each platform? > Yes, the upcoming 0.9.5 will provide auto-platform matching, so if the pre-built gem for the matching platform is available, will use it instead of the RUBY (source version) one. -- 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 Mon Nov 5 09:50:49 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 09:50:49 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> Message-ID: <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> On Nov 5, 2007 9:35 AM, Luis Lavena wrote: > On 11/5/07, Trans wrote: > > > On Nov 4, 2007 10:41 PM, Assaph Mehr wrote: > > > Hi Mikel, > > > > > > > > > > I am wondering if anyone has a good link / resource / howto, whatever > > > > on how you make a windows gem or a different version so that you get > > > > this sort of output on gem install: > > > > > > > > Select which gem to install for your platform (i386-openbsd4.1) > > > > 1. hpricot 0.6 (mswin32) > > > > 2. hpricot 0.6 (jruby) > > > > 3. hpricot 0.6 (ruby) > > > > 4. ... > > > > > > Look at: http://rubygems.org/read/chapter/20#platform > > > Use the #platform directive of the gem specification to note the > > > target platform. The default is Ruby. > > > > So essentially the best course of action is to pre-compile and create > > multiple gems for each platform? > > > > Yes, the upcoming 0.9.5 will provide auto-platform matching, so if the > pre-built gem for the matching platform is available, will use it > instead of the RUBY (source version) one. That's good. I wish we had unified packages, though, rather then having to create separate packages for each platform. T. From transfire at gmail.com Mon Nov 5 09:51:27 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 09:51:27 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711050632y1f8ccdc6p4f31e37618c22668@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711050303q75b9303fjd43e05957e26128d@mail.gmail.com> <71166b3b0711050632y1f8ccdc6p4f31e37618c22668@mail.gmail.com> Message-ID: <4b6f054f0711050651i6928134aj4bda6f761820c1e2@mail.gmail.com> On Nov 5, 2007 9:32 AM, Luis Lavena wrote: > > Hope this helps, A lot. Thank You. T. From luislavena at gmail.com Mon Nov 5 10:02:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 12:02:36 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> Message-ID: <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> On 11/5/07, Trans wrote: > > > > Yes, the upcoming 0.9.5 will provide auto-platform matching, so if the > > pre-built gem for the matching platform is available, will use it > > instead of the RUBY (source version) one. > > That's good. > > I wish we had unified packages, though, rather then having to create > separate packages for each platform. > The problem will that will be how identify extensions compiled for windows, linux or darwin, all in the same package. Kernel#require is not clever as rubygems require version to find the matching -mswin32 or -darwin or -bsd version of the specific extension. having something like: http11-x86-mswin32-60.so http11-x86-linux.so http11-x86-darwin-8.so Will not help either, instead will create huge packages. So far, this solution is quite similar to Python distutils way of packaging for specific platforms. Is not the most beautiful one, but works :-) -- 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 Nov 5 10:02:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 12:02:36 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> Message-ID: <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> On 11/5/07, Trans wrote: > > > > Yes, the upcoming 0.9.5 will provide auto-platform matching, so if the > > pre-built gem for the matching platform is available, will use it > > instead of the RUBY (source version) one. > > That's good. > > I wish we had unified packages, though, rather then having to create > separate packages for each platform. > The problem will that will be how identify extensions compiled for windows, linux or darwin, all in the same package. Kernel#require is not clever as rubygems require version to find the matching -mswin32 or -darwin or -bsd version of the specific extension. having something like: http11-x86-mswin32-60.so http11-x86-linux.so http11-x86-darwin-8.so Will not help either, instead will create huge packages. So far, this solution is quite similar to Python distutils way of packaging for specific platforms. Is not the most beautiful one, but works :-) -- 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 Nov 5 10:07:45 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 5 Nov 2007 10:07:45 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> Message-ID: <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> On 11/5/07, Luis Lavena wrote: > The problem will that will be how identify extensions compiled for > windows, linux or darwin, all in the same package. > Kernel#require is not clever as rubygems require version to find the > matching -mswin32 or -darwin or -bsd version of the specific > extension. Hmmm. It'd be nice if we did put the platform-arch stuff in the built files in RubyGems, though. It'd solve some problems with LSB/FHS compliance for those who care about that (e.g., i386-mswin32/http11.so). You could install the same gem for multiple platforms without collision and have the ruby for that platform Do The Right Thing. > having something like: > > http11-x86-mswin32-60.so > http11-x86-linux.so > http11-x86-darwin-8.so > > Will not help either, instead will create huge packages. > > So far, this solution is quite similar to Python distutils way of > packaging for specific platforms. > > Is not the most beautiful one, but works :-) Be nice if creating platform-specific gems could be automated, too ;) -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From luislavena at gmail.com Mon Nov 5 10:15:55 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 12:15:55 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> Message-ID: <71166b3b0711050715v5a5d1f4bx80956f92f8a1a48e@mail.gmail.com> On 11/5/07, Austin Ziegler wrote: > On 11/5/07, Luis Lavena wrote: > > So far, this solution is quite similar to Python distutils way of > > packaging for specific platforms. > > > > Is not the most beautiful one, but works :-) > > Be nice if creating platform-specific gems could be automated, too ;) > That will be really nice, automatic re-packaging for something like CruiseControl or CI... a RubyForge farm maybe? :-D I can donate some Windows licenses :-) -- 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 Mon Nov 5 12:05:22 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 12:05:22 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> Message-ID: <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> On Nov 5, 2007 10:07 AM, Austin Ziegler wrote: > On 11/5/07, Luis Lavena wrote: > > The problem will that will be how identify extensions compiled for > > windows, linux or darwin, all in the same package. > > > Kernel#require is not clever as rubygems require version to find the > > matching -mswin32 or -darwin or -bsd version of the specific > > extension. > > Hmmm. It'd be nice if we did put the platform-arch stuff in the built > files in RubyGems, though. It'd solve some problems with LSB/FHS > compliance for those who care about that (e.g., > i386-mswin32/http11.so). You could install the same gem for multiple > platforms without collision and have the ruby for that platform Do The > Right Thing. Do you mean what I was basically thinking? lib/ whatever.rb i386-mswin32/ http11.so i386-linux/ http11.so ... RubyGems could figure the proper load path for the platform, it could also remove the unneccessary paths in install since they are just wasting space. But we'd only need a single gem. Yes, it would bigger file, but I would think it worth the convenience. BTW why is the Windows an .so and not a .dll? Cygwin? T. From transfire at gmail.com Mon Nov 5 12:08:32 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 12:08:32 -0500 Subject: [Rubygems-developers] Gem install not working? Message-ID: <4b6f054f0711050908m76e00adak49e5f5f74f4000d6@mail.gmail.com> Something isn't right... trans at transhuttlex:~/Ruby/tmail/trunk$ sudo gem install rake [sudo] password for trans: Need to update 3 gems from http://gems.rubyforge.org ... complete Successfully installed rake-0.7.3 Installing ri documentation for rake-0.7.3... Installing RDoc documentation for rake-0.7.3... trans at transhuttlex:~/Ruby/tmail/trunk$ less /usr/local/lib/site_ruby/1.8/ i486-linux/ oll.rb pony/ ratch/ roll/ trans at transhuttlex:~/Ruby/tmail/trunk$ rake -T The program 'rake' is currently not installed. You can install it by typing: sudo apt-get install rake bash: rake: command not found trans at transhuttlex:~/Ruby/tmail/trunk$ less /usr/bin/ra ranlib ratch trans at transhuttlex:~/Ruby/tmail/trunk$ sudo gem install rake [sudo] password for trans: Successfully installed rake-0.7.3 Installing ri documentation for rake-0.7.3... Installing RDoc documentation for rake-0.7.3... trans at transhuttlex:~/Ruby/tmail/trunk$ rake -T The program 'rake' is currently not installed. You can install it by typing: sudo apt-get install rake bash: rake: command not found trans at transhuttlex:~/Ruby/tmail/trunk$ -- 7rans BE HELP: http://manumission.info From luislavena at gmail.com Mon Nov 5 12:19:11 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 14:19:11 -0300 Subject: [Rubygems-developers] Gem install not working? In-Reply-To: <4b6f054f0711050908m76e00adak49e5f5f74f4000d6@mail.gmail.com> References: <4b6f054f0711050908m76e00adak49e5f5f74f4000d6@mail.gmail.com> Message-ID: <71166b3b0711050919r152e14e4h173b9c0b332f11f9@mail.gmail.com> On 11/5/07, Trans wrote: > Something isn't right... > > trans at transhuttlex:~/Ruby/tmail/trunk$ sudo gem install rake > [sudo] password for trans: > Need to update 3 gems from http://gems.rubyforge.org > ... > complete > Successfully installed rake-0.7.3 > Installing ri documentation for rake-0.7.3... > Installing RDoc documentation for rake-0.7.3... > trans at transhuttlex:~/Ruby/tmail/trunk$ less /usr/local/lib/site_ruby/1.8/ > i486-linux/ oll.rb pony/ ratch/ roll/ > trans at transhuttlex:~/Ruby/tmail/trunk$ rake -T > The program 'rake' is currently not installed. You can install it by typing: > sudo apt-get install rake 1a) what is your gem env result? 1b) did oyu manually install gem? 1c) what options did you use to install it? 2) is there a debian package for rake? -- 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 darix at web.de Mon Nov 5 12:21:54 2007 From: darix at web.de (Marcus Rueckert) Date: Mon, 5 Nov 2007 18:21:54 +0100 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> Message-ID: <20071105172154.GK4383@pixel.global-banlist.de> On 2007-11-05 12:05:22 -0500, Trans wrote: > On Nov 5, 2007 10:07 AM, Austin Ziegler wrote: > > On 11/5/07, Luis Lavena wrote: > > > The problem will that will be how identify extensions compiled for > > > windows, linux or darwin, all in the same package. > > > > > Kernel#require is not clever as rubygems require version to find the > > > matching -mswin32 or -darwin or -bsd version of the specific > > > extension. > > > > Hmmm. It'd be nice if we did put the platform-arch stuff in the built > > files in RubyGems, though. It'd solve some problems with LSB/FHS > > compliance for those who care about that (e.g., > > i386-mswin32/http11.so). You could install the same gem for multiple > > platforms without collision and have the ruby for that platform Do The > > Right Thing. > > Do you mean what I was basically thinking? > > lib/ > whatever.rb > i386-mswin32/ > http11.so > i386-linux/ > http11.so > ... > > RubyGems could figure the proper load path for the platform, it could > also remove the unneccessary paths in install since they are just > wasting space. But we'd only need a single gem. Yes, it would bigger > file, but I would think it worth the convenience. > > BTW why is the Windows an .so and not a .dll? Cygwin? there is already a bug open for that. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From luislavena at gmail.com Mon Nov 5 13:13:23 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 15:13:23 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <20071105172154.GK4383@pixel.global-banlist.de> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> <20071105172154.GK4383@pixel.global-banlist.de> Message-ID: <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> On 11/5/07, Marcus Rueckert wrote: > On 2007-11-05 12:05:22 -0500, Trans wrote: > > > > BTW why is the Windows an .so and not a .dll? Cygwin? > > there is already a bug open for that. > I don't see .so as "bug". Python uses .pyd to differentiate binaries from system libraries. .dll should remain to direct you to system libraries, even that .so for extensions clash with libraries under *nix. -- 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 Mon Nov 5 13:39:11 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 13:39:11 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> <20071105172154.GK4383@pixel.global-banlist.de> <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> Message-ID: <4b6f054f0711051039k58ffa8b2ubc9ab0934e13ee70@mail.gmail.com> On Nov 5, 2007 1:13 PM, Luis Lavena wrote: > On 11/5/07, Marcus Rueckert wrote: > > On 2007-11-05 12:05:22 -0500, Trans wrote: > > > > > > BTW why is the Windows an .so and not a .dll? Cygwin? > > > > there is already a bug open for that. > > > > I don't see .so as "bug". Python uses .pyd to differentiate binaries > from system libraries. > > .dll should remain to direct you to system libraries, even that .so > for extensions clash with libraries under *nix. But doesn't Windows produce: Config::CONFIG['DLEXT'] => 'dll' I thought Ruby used that when attempting to require files given without their extension. T. From darix at web.de Mon Nov 5 13:52:08 2007 From: darix at web.de (Marcus Rueckert) Date: Mon, 5 Nov 2007 19:52:08 +0100 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> <20071105172154.GK4383@pixel.global-banlist.de> <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> Message-ID: <20071105185208.GL4383@pixel.global-banlist.de> On 2007-11-05 15:13:23 -0300, Luis Lavena wrote: > On 11/5/07, Marcus Rueckert wrote: > > On 2007-11-05 12:05:22 -0500, Trans wrote: > > > > > > BTW why is the Windows an .so and not a .dll? Cygwin? > > > > there is already a bug open for that. > > > > I don't see .so as "bug". Python uses .pyd to differentiate binaries > from system libraries. i referred to the arch subdirs below somegem-1.0/lib/ http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From transfire at gmail.com Mon Nov 5 14:06:16 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 14:06:16 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <20071105185208.GL4383@pixel.global-banlist.de> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> <20071105172154.GK4383@pixel.global-banlist.de> <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> <20071105185208.GL4383@pixel.global-banlist.de> Message-ID: <4b6f054f0711051106l3c51ec70veb2c61200f693847@mail.gmail.com> On Nov 5, 2007 1:52 PM, Marcus Rueckert wrote: > On 2007-11-05 15:13:23 -0300, Luis Lavena wrote: > > On 11/5/07, Marcus Rueckert wrote: > > > On 2007-11-05 12:05:22 -0500, Trans wrote: > > > > > > > > BTW why is the Windows an .so and not a .dll? Cygwin? > > > > > > there is already a bug open for that. > > > > > > > I don't see .so as "bug". Python uses .pyd to differentiate binaries > > from system libraries. > > i referred to the arch subdirs below somegem-1.0/lib/ > http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 How is that to work for binary gems? If I compile i486-linux and yours is i586-linux, would it find it? There would need to be some LCD heuristics I suppose. I'm still trying to wrap my head around all this. T. From transfire at gmail.com Mon Nov 5 14:09:32 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 14:09:32 -0500 Subject: [Rubygems-developers] Gem install not working? In-Reply-To: <71166b3b0711050919r152e14e4h173b9c0b332f11f9@mail.gmail.com> References: <4b6f054f0711050908m76e00adak49e5f5f74f4000d6@mail.gmail.com> <71166b3b0711050919r152e14e4h173b9c0b332f11f9@mail.gmail.com> Message-ID: <4b6f054f0711051109tfb02ffdhfaae601cf3ea925e@mail.gmail.com> On Nov 5, 2007 12:19 PM, Luis Lavena wrote: > On 11/5/07, Trans wrote: > > Something isn't right... > > > > trans at transhuttlex:~/Ruby/tmail/trunk$ sudo gem install rake > > [sudo] password for trans: > > Need to update 3 gems from http://gems.rubyforge.org > > ... > > complete > > Successfully installed rake-0.7.3 > > Installing ri documentation for rake-0.7.3... > > Installing RDoc documentation for rake-0.7.3... > > trans at transhuttlex:~/Ruby/tmail/trunk$ less /usr/local/lib/site_ruby/1.8/ > > i486-linux/ oll.rb pony/ ratch/ roll/ > > trans at transhuttlex:~/Ruby/tmail/trunk$ rake -T > > The program 'rake' is currently not installed. You can install it by typing: > > sudo apt-get install rake > > 1a) what is your gem env result? > 1b) did oyu manually install gem? > 1c) what options did you use to install it? It was a debian install of gems. I just tossed it and installed form source. All better now :-) > 2) is there a debian package for rake? Yes, but I wanted to install via gems. T. From halostatue at gmail.com Mon Nov 5 14:23:10 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Mon, 5 Nov 2007 14:23:10 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> Message-ID: <9e7db9110711051123y4a17d042sf77cf885e6a0eadb@mail.gmail.com> On 11/5/07, Trans wrote: > Do you mean what I was basically thinking? > > lib/ > whatever.rb > i386-mswin32/ > http11.so > i386-linux/ > http11.so > ... Yes. But on install, not on packaging. > RubyGems could figure the proper load path for the platform, it could > also remove the unneccessary paths in install since they are just > wasting space. But we'd only need a single gem. Yes, it would bigger > file, but I would think it worth the convenience. Not to remove on install; to allow for multiple platforms. Like I said, FHS/LSB stuff. > BTW why is the Windows an .so and not a .dll? Cygwin? Because Windows doesn't actually care ;) -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From luislavena at gmail.com Mon Nov 5 14:28:59 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 5 Nov 2007 16:28:59 -0300 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711051039k58ffa8b2ubc9ab0934e13ee70@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <9e7db9110711050707i1c0dc194xf7bb083507e35dc2@mail.gmail.com> <4b6f054f0711050905v36f64182x1611237de209afac@mail.gmail.com> <20071105172154.GK4383@pixel.global-banlist.de> <71166b3b0711051013t28250e55gc8ed4310fa381f33@mail.gmail.com> <4b6f054f0711051039k58ffa8b2ubc9ab0934e13ee70@mail.gmail.com> Message-ID: <71166b3b0711051128t5e58b2c4gc5db9b4ff8232902@mail.gmail.com> On 11/5/07, Trans wrote: > On Nov 5, 2007 1:13 PM, Luis Lavena wrote: > > > > .dll should remain to direct you to system libraries, even that .so > > for extensions clash with libraries under *nix. > > But doesn't Windows produce: > > Config::CONFIG['DLEXT'] => 'dll' > Actually no, DLEXT2 will produce that. > I thought Ruby used that when attempting to require files given > without their extension. I don't remember right now the exact order on which are loaded (.rb, .so, etc.) maybe .rbe will feel better (ruby extension) -- 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 Mon Nov 5 19:38:58 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 19:38:58 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall Message-ID: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> I'm a bit confused. If I have a pure-ruby version of my lib, but also have some extensions that can speed things up, should the pure-ruby gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is the compile-on-install gem? Am I going about this wrong? I'm starting to think it would be easier to create two packages, one for the pure-ruby gem and another for the optional extensions. Thanks, T. -- 7rans BE HELP: http://manumission.info From transfire at gmail.com Mon Nov 5 22:55:15 2007 From: transfire at gmail.com (Trans) Date: Mon, 5 Nov 2007 22:55:15 -0500 Subject: [Rubygems-developers] gemspec extensions attribute Message-ID: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> One last question (hopefully). In the gemspec it says: extensions Type: Array; Optional Description The paths to extconf.rb-style files used to compile extensions. Usage spec.extensions << 'ext/rmagic/extconf.rb' Notes These files will be run when the gem is installed, causing the C (or whatever) code to be compiled on the user's machine. But does this have to be extconf.rb scripts? Or can it be any script in the package? And does gems run 'make' on its own, or does the extconf.rb (or other) scripts need to do that? Thanks, T. From luislavena at gmail.com Tue Nov 6 00:33:39 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 02:33:39 -0300 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> Message-ID: <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> On 11/5/07, Trans wrote: > I'm a bit confused. If I have a pure-ruby version of my lib, but also > have some extensions that can speed things up, should the pure-ruby > gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is > the compile-on-install gem? Am I going about this wrong? I'm starting > to think it would be easier to create two packages, one for the > pure-ruby gem and another for the optional extensions. > The confusion is based on your design. The general understanding is that RUBY platform (the pure-ruby you mention) is aimed to gems that provide functionality and optionally can include native extensions (as source code) that will trigger the build-on-install procedure of RubyGems. So: the pure ruby is a pure-ruby, no extensions source code inside. On he contrary, the pre build gems ships the extension binaries for the platforms I commented on previous post. If your gem can "optionally" get enhancements based on C extensions, you should package those as other gems, and make your gem do not depend on them, but that take advantage of it if present. So is a bit flexible and depends on your strategy. -- 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 Tue Nov 6 00:36:53 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 02:36:53 -0300 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> Message-ID: <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> On 11/6/07, Trans wrote: > One last question (hopefully). In the gemspec it says: > > extensions > > Type: Array; Optional > Description > > The paths to extconf.rb-style files used to compile extensions. > Usage > > spec.extensions << 'ext/rmagic/extconf.rb' > > Notes > > These files will be run when the gem is installed, causing the C (or > whatever) code to be compiled on the user's machine. > > > But does this have to be extconf.rb scripts? Or can it be any script > in the package? And does gems run 'make' on its own, or does the > extconf.rb (or other) scripts need to do that? > The files will be run... with ruby. So it's expecting a ruby script. Also after the call to ruby extconf.rb will follow a call to make and copy the resulting .so file to lib folder of the gem. If extensions is empty, no build process will be launched. You should create a test gem and check the whole scenario for your own understanding of the workflow. I did and make my life more easy :-) -- 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 Tue Nov 6 00:41:48 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 00:41:48 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> Message-ID: <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> On Nov 6, 2007 12:33 AM, Luis Lavena wrote: > On 11/5/07, Trans wrote: > > I'm a bit confused. If I have a pure-ruby version of my lib, but also > > have some extensions that can speed things up, should the pure-ruby > > gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is > > the compile-on-install gem? Am I going about this wrong? I'm starting > > to think it would be easier to create two packages, one for the > > pure-ruby gem and another for the optional extensions. > > > > The confusion is based on your design. My design was based on my confusion ;-p > The general understanding is > that RUBY platform (the pure-ruby you mention) is aimed to gems that > provide functionality and optionally can include native extensions (as > source code) that will trigger the build-on-install procedure of > RubyGems. > > So: the pure ruby is a pure-ruby, no extensions source code inside. > > On he contrary, the pre build gems ships the extension binaries for > the platforms I commented on previous post. > > If your gem can "optionally" get enhancements based on C extensions, > you should package those as other gems, and make your gem do not > depend on them, but that take advantage of it if present. > > So is a bit flexible and depends on your strategy. Ok. I think I understand now. Thanks. T. From transfire at gmail.com Tue Nov 6 00:51:49 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 00:51:49 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> Message-ID: <4b6f054f0711052151h245af54awd76433a3e27992d@mail.gmail.com> On Nov 6, 2007 12:36 AM, Luis Lavena wrote: > The files will be run... with ruby. So it's expecting a ruby script. > Also after the call to ruby extconf.rb will follow a call to make and > copy the resulting .so file to lib folder of the gem. Hmm... doesn't that assume a too much? What if one's not using make? And what about copying the files to a subdir of lib/ ? T. From transfire at gmail.com Tue Nov 6 01:19:04 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 01:19:04 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> Message-ID: <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> On Nov 6, 2007 12:36 AM, Luis Lavena wrote: > You should create a test gem and check the whole scenario for your own > understanding of the workflow. > > I did and make my life more easy :-) Ok. I did it. And it did exactly what you said it would. I can live with the running of make, but the files do not belong in lib/. They at least belong in the project subdir, (eg. lib/foo/), but I would expect there would be some way to specify where to put them. Is there? T. From transfire at gmail.com Tue Nov 6 12:34:37 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 12:34:37 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> Message-ID: <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> On Nov 6, 2007 1:19 AM, Trans wrote: > On Nov 6, 2007 12:36 AM, Luis Lavena wrote: > > > You should create a test gem and check the whole scenario for your own > > understanding of the workflow. > > > > I did and make my life more easy :-) > > Ok. I did it. And it did exactly what you said it would. I can live > with the running of make, but the files do not belong in lib/. They at > least belong in the project subdir, (eg. lib/foo/), but I would expect > there would be some way to specify where to put them. Is there? No one can tell me, if there's a way to get the comoiled libs copied to the right place? I ran setup.rb and it puts them in the right place, so I'm surprised gems does not. Should I submit a bug report? T. From luislavena at gmail.com Tue Nov 6 12:42:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 14:42:02 -0300 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> Message-ID: <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> On 11/6/07, Trans wrote: > > No one can tell me, if there's a way to get the comoiled libs copied > to the right place? I ran setup.rb and it puts them in the right > place, so I'm surprised gems does not. > > Should I submit a bug report? > I don't quite understand your question: you're expecting that rubygems (gem install) copy your lib/folder to some place? That trash the purpose of rubygems, since updated gems will overwrite previous ones... and left over files from older versions... What you're trying to accomplish? -- 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 Tue Nov 6 13:30:32 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 13:30:32 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> Message-ID: <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> On Nov 6, 2007 12:42 PM, Luis Lavena wrote: > On 11/6/07, Trans wrote: > > > > No one can tell me, if there's a way to get the comoiled libs copied > > to the right place? I ran setup.rb and it puts them in the right > > place, so I'm surprised gems does not. > > > > Should I submit a bug report? > > > > I don't quite understand your question: you're expecting that rubygems > (gem install) copy your lib/folder to some place? No. I'm still talking about compiling extensions. When gem install foo and foo's gemspec has extensions defined, it does the compilation, right? The resulting .so files get copied to lib/, but that's the wrong place. If you use setup.rb instead they get copied to right place in 'lib/foo/'. How do I tell gems to copy them to lib/foo/ and not lib/? T. From Daniel.Berger at qwest.com Tue Nov 6 13:36:52 2007 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 6 Nov 2007 12:36:52 -0600 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com><71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com><4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com><4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com><71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFBE72F85@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: Tuesday, November 06, 2007 11:31 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] gemspec extensions attribute > > On Nov 6, 2007 12:42 PM, Luis Lavena wrote: > > On 11/6/07, Trans wrote: > > > > > > No one can tell me, if there's a way to get the comoiled > libs copied > > > to the right place? I ran setup.rb and it puts them in the right > > > place, so I'm surprised gems does not. > > > > > > Should I submit a bug report? > > > > > > > I don't quite understand your question: you're expecting > that rubygems > > (gem install) copy your lib/folder to some place? > > No. I'm still talking about compiling extensions. > > When > > gem install foo > > and foo's gemspec has extensions defined, it does the > compilation, right? The resulting .so files get copied to > lib/, but that's the wrong place. If you use setup.rb instead > they get copied to right place in 'lib/foo/'. How do I tell > gems to copy them to lib/foo/ and not lib/? I think you have to do create_makefile('your_lib', 'foo') in the extconf.rb file. 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 Tue Nov 6 19:04:56 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 19:04:56 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <7524A45A1A5B264FA4809E2156496CFBE72F85@ITOMAE2KM01.AD.QINTRA.COM> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72F85@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <4b6f054f0711061604k28d51febi26ca985b9b9ff0b0@mail.gmail.com> On Nov 6, 2007 1:36 PM, Berger, Daniel wrote: > I think you have to do create_makefile('your_lib', 'foo') in the > extconf.rb file. Thank you. Sorry I'm so dense about this stuff. I've never worked with Makefiles before (beyond compiling someone else's code). I thought gems was responsible for moving the file, not the makefile. Anyway, I looked up mkmf.rb and got a better idea of what's going on. I manged to create a multi-platform gem, so that's cool. Thanks for the help all, T. From luislavena at gmail.com Tue Nov 6 19:13:53 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 21:13:53 -0300 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711061604k28d51febi26ca985b9b9ff0b0@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72F85@ITOMAE2KM01.AD.QINTRA.COM> <4b6f054f0711061604k28d51febi26ca985b9b9ff0b0@mail.gmail.com> Message-ID: <71166b3b0711061613h6d95f663p55035b9f2ae3e5e1@mail.gmail.com> On 11/6/07, Trans wrote: > On Nov 6, 2007 1:36 PM, Berger, Daniel wrote: > > > I think you have to do create_makefile('your_lib', 'foo') in the > > extconf.rb file. > > Thank you. > > Sorry I'm so dense about this stuff. I've never worked with Makefiles > before (beyond compiling someone else's code). I thought gems was > responsible for moving the file, not the makefile. Anyway, I looked up > mkmf.rb and got a better idea of what's going on. I manged to create a > multi-platform gem, so that's cool. > If you have a blog, I'll really enjoy reading about this, since mkmf.rb is a real pain to understand! ;-) I don't know what happened to mkrf (which was supposed to replace mkmf.rb with Rakefiles)... I wish there was some improvements on this area :-) Also, I'll love to know how did you managed the cross-compile thing, since lot of developers could learn from it. 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 luislavena at gmail.com Tue Nov 6 21:44:46 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 23:44:46 -0300 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? Message-ID: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> Hello folks, Been updating some gems locally (crafted by myself) and found a curious situation: Eric told me on #ruby-lang that Hoe include itself as dependency since it's needed to perform gem 'check' operations. Also, on FireBrigade, 'as gem developer' there is listed that Rake and RSpec are included if Rakefile or spec/* folder is found in the gem, just to ease the task if you forgot to include. This raise me the question: this is right? I mean, sometimes when I download some gems, I trust they work as expected by the release notes. If not, I checkout the source code (if some repo is available) and perform my tests locally. For some gems it's overkill to depend on rspec when you're working with trunk to perform some test -- since there is no official release of latest changes -- and include vendor/rspec distract from the task. What is the best approach for this? Include everything as dependency? -- 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 Tue Nov 6 21:47:09 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 23:47:09 -0300 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> Message-ID: <71166b3b0711061847w69d105c3m86498c4b1e6be4a8@mail.gmail.com> On 11/6/07, Luis Lavena wrote: > What is the best approach for this? Include everything as dependency? > Also forgot to mention: Sometimes rake spec works and sometimes you need to call rspec from outside (spec spec) since RSpec do some weird things with Ruby VM... and couldn't reproduce to be certain. -- 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 Tue Nov 6 21:52:14 2007 From: transfire at gmail.com (Trans) Date: Tue, 6 Nov 2007 21:52:14 -0500 Subject: [Rubygems-developers] Rubyforge gem sync frequency Message-ID: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> How long does it take to refresh the rubyforge gem index? I put a gem up 20mins ago and gem is still telling me it's not there: trans at transhuttlex:/usr/lib/ruby/gems$ sudo gem install box -v =0.2.3 ERROR: While executing gem ... (Gem::GemNotFoundException) Could not find box (= 0.2.3) in any repository But it is there: http://rubyforge.org/frs/download.php/27615/box-0.2.3.gem T. From luislavena at gmail.com Tue Nov 6 21:58:03 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 6 Nov 2007 23:58:03 -0300 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> Message-ID: <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> On 11/6/07, Trans wrote: > How long does it take to refresh the rubyforge gem index? I put a gem > up 20mins ago and gem is still telling me it's not there: > You should as RubyForge staff about that (Tom?). Indexing all the gems rubyforge has is a expensive task. If you want to test, you can create your local gem repository with index_gem_repository and a webserver. just add --source http://localhost:port and you're ready. -- 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 thewoolleyman at gmail.com Tue Nov 6 22:58:45 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 6 Nov 2007 20:58:45 -0700 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> Message-ID: On 11/6/07, Luis Lavena wrote: > What is the best approach for this? Include everything as dependency? I think you should only include actual runtime dependencies in the gem spec, not test- or build-time dependencies. For these, you can throw an exception at the beginning of your rake task or spec helper, specifying which ones are needed but missing. As for Hoe, I hacked myself an "IndependentHoe" for my gem, because I had no other dependencies, and I KNOW i didn't need Hoe at runtime. If you are REALLY cool, I'd recommend my GemInstaller tool to centrally and _automatically_ manage test- and build-time dependencies (both installation AND loading) separately from your runtime dependencies. I've been delaying to promote GemInstaller heavily until I update it to take advantage of all the latest cool platform-related stuff in the beta RubyGems release. But it works fine, and is in production use on several apps now, and your original topic is a perfect use for it. -- Chad From halostatue at gmail.com Tue Nov 6 23:12:12 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 6 Nov 2007 23:12:12 -0500 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> Message-ID: <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> On 11/6/07, Luis Lavena wrote: > Been updating some gems locally (crafted by myself) and found a > curious situation: > > Eric told me on #ruby-lang that Hoe include itself as dependency since > it's needed to perform gem 'check' operations. This and the other issues would be solved if someone added a "development dependencies" list (or a "gem dependencies", as in dependencies for working with the gem itself, not with the package contained within the gem... sort of). -austin -- Austin Ziegler * halostatue at gmail.com * http://www.halostatue.ca/ * austin at halostatue.ca * http://www.halostatue.ca/feed/ * austin at zieglers.ca From luislavena at gmail.com Tue Nov 6 23:58:25 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 01:58:25 -0300 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> Message-ID: <71166b3b0711062058h678a7cfbi333492593976bce0@mail.gmail.com> On 11/7/07, Austin Ziegler wrote: > On 11/6/07, Luis Lavena wrote: > > Been updating some gems locally (crafted by myself) and found a > > curious situation: > > > > Eric told me on #ruby-lang that Hoe include itself as dependency since > > it's needed to perform gem 'check' operations. > > This and the other issues would be solved if someone added a > "development dependencies" list (or a "gem dependencies", as in > dependencies for working with the gem itself, not with the package > contained within the gem... sort of). > In "The Real World"(tm) users read the documentation from the source package to fulfill the required dependencies to compile build and pack the application/library. Another example is a when you depend during testing of a Mocking framework like mocha or FlexMock... why that should be added as runtime dependency? +1 for #dependencies and #development_dependencies :-) -- 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 Wed Nov 7 02:24:10 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 02:24:10 -0500 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> Message-ID: <4b6f054f0711062324j680217f3l611b0befae98082d@mail.gmail.com> On Nov 6, 2007 9:58 PM, Luis Lavena wrote: > On 11/6/07, Trans wrote: > > How long does it take to refresh the rubyforge gem index? I put a gem > > up 20mins ago and gem is still telling me it's not there: > > > > You should as RubyForge staff about that (Tom?). That's Tom Copeland. Not me. But Tom Copeland is a great guy :-) > Indexing all the gems rubyforge has is a expensive task. > > If you want to test, you can create your local gem repository with > index_gem_repository and a webserver. > > just add --source http://localhost:port and you're ready. That's cool, though I don't think it will tell me much about Rubyforge's time. There are a lot more gems over there. It's working now though, so at least I know it finishes by 5 hrs. :-) [We'll at least I assume that's the reason] Thanks, T. From luislavena at gmail.com Wed Nov 7 02:30:59 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 04:30:59 -0300 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <4b6f054f0711062324j680217f3l611b0befae98082d@mail.gmail.com> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> <4b6f054f0711062324j680217f3l611b0befae98082d@mail.gmail.com> Message-ID: <71166b3b0711062330w55e75ed7o86ef981ddedc2bda@mail.gmail.com> On 11/7/07, Trans wrote: > On Nov 6, 2007 9:58 PM, Luis Lavena wrote: > > On 11/6/07, Trans wrote: > > > How long does it take to refresh the rubyforge gem index? I put a gem > > > up 20mins ago and gem is still telling me it's not there: > > > > > > > You should as RubyForge staff about that (Tom?). > > That's Tom Copeland. Not me. But Tom Copeland is a great guy :-) > I missed the 'k' ... you should ask :-) > > Indexing all the gems rubyforge has is a expensive task. > > > > If you want to test, you can create your local gem repository with > > index_gem_repository and a webserver. > > > > just add --source http://localhost:port and you're ready. > > That's cool, though I don't think it will tell me much about > Rubyforge's time. There are a lot more gems over there. > I was suggesting that to do some local testing since every gem you upload at rubyforge remain published (and cannot be removed). -- 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 Wed Nov 7 02:36:29 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 02:36:29 -0500 Subject: [Rubygems-developers] On Windows Zlib::BufError Message-ID: <4b6f054f0711062336s7a155727y759d4890b8f76272@mail.gmail.com> No end of oddities for me.... Using Windows one click installer. Just finished doing a gem update --system (twice): C:\Documents and Settings\trans>gem install facets ERROR: While executing gem ... (Zlib::BufError) buffer error Here's --backtrace C:\Documents and Settings\trans>gem install --backtrace facets ERROR: While executing gem ... (Zlib::BufError) buffer error c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:621:in `initialize' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:621:in `new' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:621:in `zipped_stream' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:596:in `each' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:448:in `each_entry' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:442:in `loop' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:442:in `each_entry' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:427:in `each' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:594:in `each' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:62:in `from_io' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:587:in `open_from_io' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb:805:in `open_from_io' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:59:in `from_io' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/format.rb:47:in `from_file_by_path' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/installer.rb:68:in `install' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/remote_installer.rb:68:in `install' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:87:in `execu te' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:49:in `each' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:49:in `execu te' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command.rb:70:in `invoke' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:121:in `process_args' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:92:in `run' c:/ruby/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:30:in `run' c:/ruby/bin/gem.bat:24 And with --debug: C:\Documents and Settings\trans>gem install --debug facets Exception `Errno::ENOENT' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/config_file .rb:51 - No such file or directory - C:\Documents and Settings\trans/.gemrc Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::BuildCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::CertCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::CheckCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::ContentsCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::DependencyCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::EnvironmentCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::HelpCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::InstallCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::OutdatedCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::PristineCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::QueryCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::ListCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::RdocCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::SearchCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::SourcesCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::SpecificationCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::UninstallCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::UnpackCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::CleanupCommand Exception `NameError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager .rb:145 - uninitialized constant Gem::Commands::UpdateCommand Exception `Zlib::BufError' at c:/ruby/lib/ruby/site_ruby/1.8/rubygems/package.rb :621 - buffer error ERROR: While executing gem ... (Zlib::BufError) buffer error -- 7rans From transfire at gmail.com Wed Nov 7 03:14:51 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 03:14:51 -0500 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <71166b3b0711062330w55e75ed7o86ef981ddedc2bda@mail.gmail.com> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> <4b6f054f0711062324j680217f3l611b0befae98082d@mail.gmail.com> <71166b3b0711062330w55e75ed7o86ef981ddedc2bda@mail.gmail.com> Message-ID: <4b6f054f0711070014p2e5d6cdfy286615d3ac29f515@mail.gmail.com> On Nov 7, 2007 2:30 AM, Luis Lavena wrote: > On 11/7/07, Trans wrote: > > On Nov 6, 2007 9:58 PM, Luis Lavena wrote: > > > On 11/6/07, Trans wrote: > > > > How long does it take to refresh the rubyforge gem index? I put a gem > > > > up 20mins ago and gem is still telling me it's not there: > > > > > > > > > > You should as RubyForge staff about that (Tom?). > > > > That's Tom Copeland. Not me. But Tom Copeland is a great guy :-) > > > > I missed the 'k' ... you should ask :-) Hahahaha. And I thought you had really botched that sentence :-) Ahhh... what am I doing up at this hour? Lol. T. From transfire at gmail.com Wed Nov 7 04:09:40 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 04:09:40 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <71166b3b0711061613h6d95f663p55035b9f2ae3e5e1@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> <4b6f054f0711060934l533bd6cbx8d17c61841f95d61@mail.gmail.com> <71166b3b0711060942n20286196g13aae34d134889e5@mail.gmail.com> <4b6f054f0711061030l21b0a657j27a3d4e0828a828b@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFBE72F85@ITOMAE2KM01.AD.QINTRA.COM> <4b6f054f0711061604k28d51febi26ca985b9b9ff0b0@mail.gmail.com> <71166b3b0711061613h6d95f663p55035b9f2ae3e5e1@mail.gmail.com> Message-ID: <4b6f054f0711070109i3a87b7d2y5c408191167e7e09@mail.gmail.com> On Nov 6, 2007 7:13 PM, Luis Lavena wrote: > On 11/6/07, Trans wrote: > > > On Nov 6, 2007 1:36 PM, Berger, Daniel wrote: > > > > > I think you have to do create_makefile('your_lib', 'foo') in the > > > extconf.rb file. > > > > Thank you. > > > > Sorry I'm so dense about this stuff. I've never worked with Makefiles > > before (beyond compiling someone else's code). I thought gems was > > responsible for moving the file, not the makefile. Anyway, I looked up > > mkmf.rb and got a better idea of what's going on. I manged to create a > > multi-platform gem, so that's cool. > > > > If you have a blog, I'll really enjoy reading about this, since > mkmf.rb is a real pain to understand! ;-) > > I don't know what happened to mkrf (which was supposed to replace > mkmf.rb with Rakefiles)... I wish there was some improvements on this > area :-) > > Also, I'll love to know how did you managed the cross-compile thing, > since lot of developers could learn from it. Oh nothing that fancy. Just compile on different platforms and add them to the repo. I use a special #require_arch method to load the correct one. T. From transfire at gmail.com Wed Nov 7 04:50:00 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 04:50:00 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> Message-ID: <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> On Nov 6, 2007 12:41 AM, Trans wrote: > On Nov 6, 2007 12:33 AM, Luis Lavena wrote: > > On 11/5/07, Trans wrote: > > > I'm a bit confused. If I have a pure-ruby version of my lib, but also > > > have some extensions that can speed things up, should the pure-ruby > > > gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is > > > the compile-on-install gem? Am I going about this wrong? I'm starting > > > to think it would be easier to create two packages, one for the > > > pure-ruby gem and another for the optional extensions. I need to provide these: * pure ruby version * compile-on-install version * win32 pre-built version I would like to make the first two a single gem, rather then two separate gems. To do that I need RubyGems not to abort if make fails. I am going to try to figure out a way to do that. But if someone already has an idea how, please let me know. T. From flori at nixe.ping.de Wed Nov 7 07:37:30 2007 From: flori at nixe.ping.de (Florian Frank) Date: 7 Nov 2007 13:37:30 +0100 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> Message-ID: <4731B18A.4000603@nixe.ping.de> Trans wrote: >>>> I'm a bit confused. If I have a pure-ruby version of my lib, but also >>>> have some extensions that can speed things up, should the pure-ruby >>>> gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is >>>> the compile-on-install gem? Am I going about this wrong? I'm starting >>>> to think it would be easier to create two packages, one for the >>>> pure-ruby gem and another for the optional extensions. >>>> > > I need to provide these: > > * pure ruby version > * compile-on-install version > * win32 pre-built version > > I would like to make the first two a single gem, rather then two > separate gems. To do that I need RubyGems not to abort if make fails. > I am going to try to figure out a way to do that. But if someone > already has an idea how, please let me know. > If you figure this out, please post the solution to the list. I had/have exactly the same problem with my json gem, which offers a pure ruby implementation variant and a faster c extension variant. I have used another name (json_pure) for the pure ruby variant, which solves one problem: You now can pick the json variant, if your platform supports compilation, and you can pick json_pure if you have to use the pure version. Ironically my json gem would automatically fallback to the pure variant anyway, if the shared objects couldn't be loaded. So the json_pure variant contains almost the same files as the json variant does, and the json variant includes the pure ruby version, which can be used by requiring 'json/pure' instead of requiring 'json'. Another problem isn't solved by this workaround, though. If some other developer adds json as a dependency, it will resolve to the compile variant, but the resolution will fail altogether on a platform like jruby, which doesn't support compilation. I have learned that merb ran into this problem, they now use json_pure as a dependency. This is far from optimal. I have made made a RubyGems feature request for a pure ruby platform (http://rubyforge.org/tracker/index.php?func=detail&aid=13290&group_id=126&atid=578) a while ago, in order to address this problem, but it was closed without a real solution. It's unfortunate, that RubyGems conflates gems, that are pure ruby with those that will trigger a compilation process, but I guess it's too late to change this now. In the case of json, it would be indeed be enough, if RubyGems would soldier on and just install the pure ruby stuff anyway, if compilation fails. But this isn't guaranteed to work for other gems, that don't have a pure ruby fallback. The gem command could do a better job to resolve dependencies as well: It could first figure out, if the platform under which is running, supports compilation. If the json dependency is being resolved on platform like jruby, that doesn't support compilation like jruby, it should first look for a binary platform specific gem, e. g. jruby platform. If none is found, it should look for a pure platform variant and try to install that one. If there is no pure platform found, it should assume, that the ruby platform gem is actually a pure ruby implementation and try to install that one. This could still fail, but this would be the same behaviour, that is happening now. If this algorithm would be implemented, merb could use the json dependency and automatically get the fastest possible variant on the given platform. I hope, that there will be a better solution for the pure ruby issue, but I don't know, how I could solve this by building the gems any differently. -- Florian Frank From halostatue at gmail.com Wed Nov 7 08:03:03 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Wed, 7 Nov 2007 08:03:03 -0500 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711062058h678a7cfbi333492593976bce0@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> <71166b3b0711062058h678a7cfbi333492593976bce0@mail.gmail.com> Message-ID: <9e7db9110711070503w4b6c0499ndd28b63b9734bc2c@mail.gmail.com> On 11/6/07, Luis Lavena wrote: > On 11/7/07, Austin Ziegler wrote: > > On 11/6/07, Luis Lavena wrote: > > > Been updating some gems locally (crafted by myself) and found a > > > curious situation: > > > Eric told me on #ruby-lang that Hoe include itself as dependency since > > > it's needed to perform gem 'check' operations. > > This and the other issues would be solved if someone added a > > "development dependencies" list (or a "gem dependencies", as in > > dependencies for working with the gem itself, not with the package > > contained within the gem... sort of). > In "The Real World"(tm) users read the documentation from the source > package to fulfill the required dependencies to compile build and pack > the application/library. Yeah. It'd just be nice if we could say: gem install --for-development foobar ;) Mostly, the problem is the same as everything else... someone needs to take the time to make a patch ;) -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 Wed Nov 7 09:08:28 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 09:08:28 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4731B18A.4000603@nixe.ping.de> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> Message-ID: <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> On 7 Nov 2007 13:37:30 +0100, Florian Frank wrote: > Trans wrote: > >>>> I'm a bit confused. If I have a pure-ruby version of my lib, but also > >>>> have some extensions that can speed things up, should the pure-ruby > >>>> gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is > >>>> the compile-on-install gem? Am I going about this wrong? I'm starting > >>>> to think it would be easier to create two packages, one for the > >>>> pure-ruby gem and another for the optional extensions. > >>>> > > > > I need to provide these: > > > > * pure ruby version > > * compile-on-install version > > * win32 pre-built version > > > > I would like to make the first two a single gem, rather then two > > separate gems. To do that I need RubyGems not to abort if make fails. > > I am going to try to figure out a way to do that. But if someone > > already has an idea how, please let me know. > > > If you figure this out, please post the solution to the list. I had/have > exactly the same problem with my json gem, which offers a pure ruby > implementation variant and a faster c extension variant. > > I have used another name (json_pure) for the pure ruby variant, which > solves one problem: You now can pick the json variant, if your platform > supports compilation, and you can pick json_pure if you have to use the > pure version. Ironically my json gem would automatically fallback to the > pure variant anyway, if the shared objects couldn't be loaded. So the > json_pure variant contains almost the same files as the json variant > does, and the json variant includes the pure ruby version, which can be > used by requiring 'json/pure' instead of requiring 'json'. > > Another problem isn't solved by this workaround, though. If some other > developer adds json as a dependency, it will resolve to the compile > variant, but the resolution will fail altogether on a platform like > jruby, which doesn't support compilation. > > I have learned that merb ran into this problem, they now use json_pure > as a dependency. This is far from optimal. I have made made a RubyGems > feature request for a pure ruby platform > (http://rubyforge.org/tracker/index.php?func=detail&aid=13290&group_id=126&atid=578) > a while ago, in order to address this problem, but it was closed without > a real solution. > > It's unfortunate, that RubyGems conflates gems, that are pure ruby with > those that will trigger a compilation process, but I guess it's too late > to change this now. In the case of json, it would be indeed be enough, > if RubyGems would soldier on and just install the pure ruby stuff > anyway, if compilation fails. But this isn't guaranteed to work for > other gems, that don't have a pure ruby fallback. > > The gem command could do a better job to resolve dependencies as well: > > It could first figure out, if the platform under which is running, > supports compilation. If the json dependency is being resolved on > platform like jruby, that doesn't support compilation like jruby, it > should first look for a binary platform specific gem, e. g. jruby > platform. If none is found, it should look for a pure platform variant > and try to install that one. If there is no pure platform found, it > should assume, that the ruby platform gem is actually a pure ruby > implementation and try to install that one. This could still fail, but > this would be the same behaviour, that is happening now. It can get tricky. Gems really needs to offer a switch as well so the installer can select the variant. I managed a partial solution. There did not seem to be a way to rescue the compile failure b/c Rubygems is shelling out the execution of extconf.rb. So instead I made prints a message when compiling fails that tells the user they can still use the library in pure-ruby mode by setting an environment variable and installing again. My extconf.rb looks like this: require 'mkmf' require 'rbconfig' extension_name = 'base64' arch = Config::CONFIG['arch'] FailedMessage.replace("Could not create Makefile, probably for the lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options (see below). TMail has a pure-ruby fallback mode, so you can still use this library. To do so, set the environment variable, export NORUBYEXT='true', and gem install again.\n\n") if ENV['NORUBYEXT'] == 'true' # Rubygems is sending all output to dev/null :( STDOUT << "NORUBYEXT option is set to true. Native extension will be omitted." File.open('Makefile', 'w') do |f| f << "all:\n" f << "install:\n" end else if (/mswin/ =~ RUBY_PLATFORM) and ENV['make'].nil? $LIBS += " msvcprt.lib" create_makefile(extension_name, "tmail/#{arch}") else $CFLAGS += " -D_FILE_OFFSET_BITS=64" #??? create_makefile(extension_name, "tmail/#{arch}") end end As you can see I just made a dummy Makefile that does nothing if RUBYNOEXT is set to 'true' (Hmm... I should probably give the variable a mode specific name, anyway...) You'll also notice I use 'arch' for the lib destination. I use a #require_arch method in my code to first attempt to load the native code: def require_arch(fname) arch = Config::CONFIG['arch'] begin path = File.join("tmail", arch, fname) require path rescue LoadError => e # try pre-built Windows binaries if arch =~ /mswin/ require File.join("tmail", 'mswin32', fname) else raise e end end end I'm still running it through some paces but it seems to be working fine. It's not the ideal solution, but it's workable for now. The ideal solution would be for RubyGems to add a 'ruby_ext_fallback' option to the gemspec. I have a quick patch if the RubyGem team is interested. I believe it's as simple adding an if @spec.ruby_ext_fallback to Installer#build_extensions method. T. From tom at infoether.com Wed Nov 7 09:13:59 2007 From: tom at infoether.com (Tom Copeland) Date: Wed, 07 Nov 2007 09:13:59 -0500 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> Message-ID: <1194444839.15593.6.camel@bugs.hal> On Tue, 2007-11-06 at 23:58 -0300, Luis Lavena wrote: > On 11/6/07, Trans wrote: > > How long does it take to refresh the rubyforge gem index? I put a gem > > up 20mins ago and gem is still telling me it's not there: > > > > You should as RubyForge staff about that (Tom?). We've got a cronjob that checks for new gems once an hour. Yours, Tom From tom at infoether.com Wed Nov 7 09:16:49 2007 From: tom at infoether.com (Tom Copeland) Date: Wed, 07 Nov 2007 09:16:49 -0500 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index Message-ID: <1194445009.15593.11.camel@bugs.hal> Hi all - Something seems to have changed in the indexer; only certain gems are getting picked up. For example, for wxruby we now see only: ========================== $ gem install wxruby Select which gem to install for your platform (i686-linux) 1. wxruby 1.9.2 (x86_64-linux) 2. wxruby 1.9.1 (x86_64-linux) 3. Cancel installation ========================== But there are a bunch of gems for different platforms available: ========================== $ ls /var/www/gems/gems/ | grep wxruby- wxruby-1.9.0-i386-mswin32.gem wxruby-1.9.0-i686-darwin8.4.1.gem wxruby-1.9.0-i686-linux.gem wxruby-1.9.0-powerpc-darwin8.10.0.gem wxruby-1.9.1-i386-mswin32.gem wxruby-1.9.1-i686-darwin8.4.1.gem wxruby-1.9.1-i686-linux.gem wxruby-1.9.1-powerpc-darwin8.3.0.gem wxruby-1.9.1-x86_64-linux.gem wxruby-1.9.2-i386-mswin32.gem wxruby-1.9.2-i686-darwin8.8.2.gem wxruby-1.9.2-i686-linux.gem wxruby-1.9.2-powerpc-darwin8.10.0.gem wxruby-1.9.2-x86_64-linux.gem ========================== Eric, maybe it's only getting the last gem for each name - something like that? Thanks, Tom From transfire at gmail.com Wed Nov 7 09:21:32 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 09:21:32 -0500 Subject: [Rubygems-developers] Rubyforge gem sync frequency In-Reply-To: <1194444839.15593.6.camel@bugs.hal> References: <4b6f054f0711061852m20a3f0b5ub4eccc896b9d3e66@mail.gmail.com> <71166b3b0711061858u758eb9bep55fdee3217fd650@mail.gmail.com> <1194444839.15593.6.camel@bugs.hal> Message-ID: <4b6f054f0711070621y3cfe5b1ft338859eed6ff0580@mail.gmail.com> On Nov 7, 2007 9:13 AM, Tom Copeland wrote: > On Tue, 2007-11-06 at 23:58 -0300, Luis Lavena wrote: > > On 11/6/07, Trans wrote: > > > How long does it take to refresh the rubyforge gem index? I put a gem > > > up 20mins ago and gem is still telling me it's not there: > > > > > > > You should as RubyForge staff about that (Tom?). > > We've got a cronjob that checks for new gems once an hour. Thanks. Good to know. T. From luislavena at gmail.com Wed Nov 7 10:51:44 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 12:51:44 -0300 Subject: [Rubygems-developers] On Windows Zlib::BufError In-Reply-To: <4b6f054f0711062336s7a155727y759d4890b8f76272@mail.gmail.com> References: <4b6f054f0711062336s7a155727y759d4890b8f76272@mail.gmail.com> Message-ID: <71166b3b0711070751r4ed6d22egf2e66985c5202b68@mail.gmail.com> On 11/7/07, Trans wrote: > No end of oddities for me.... Using Windows one click installer. Just > finished doing a gem update --system (twice): > > C:\Documents and Settings\trans>gem install facets > ERROR: While executing gem ... (Zlib::BufError) > buffer error > This is a known issue of Zlib [1] [2] Which version of One-Click-Installer did you use? Latest Release Candidate? Which version of rubygems did you tried to update? it seems the .bat file is form a older version. [1] http://weblog.rubyonrails.org/2007/6/29/capistrano-2-0-preview-4 [2] http://weblog.rubyonrails.org/2006/8/9/rails-1-1-5-mandatory-security-patch-and-other-tidbits -- 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 Wed Nov 7 10:58:29 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 12:58:29 -0300 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <9e7db9110711070503w4b6c0499ndd28b63b9734bc2c@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> <71166b3b0711062058h678a7cfbi333492593976bce0@mail.gmail.com> <9e7db9110711070503w4b6c0499ndd28b63b9734bc2c@mail.gmail.com> Message-ID: <71166b3b0711070758y6f014223n881b590a05f7a19f@mail.gmail.com> On 11/7/07, Austin Ziegler wrote: > > Yeah. It'd just be nice if we could say: > > gem install --for-development foobar > Sound good, but too verbose. I like the build-dep command of apt-get (that's the only thing I like, for the record) :-) > Mostly, the problem is the same as everything else... someone needs to > take the time to make a patch ;) This will require adding the new command, the new development_dependency (or build_dependency) to the specs and make check command use this instead. I'm trying to collect enough info to make this happen, then I can create a patch and submit to rubyforge. :-D -- 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 Wed Nov 7 11:45:33 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 11:45:33 -0500 Subject: [Rubygems-developers] extensions fall back option Message-ID: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> Would this suffice for adding a fall back option to Installer? It also requires that 'extensions_fallback' be added to the gemspec. # from installer.rb def build_extensions return if @spec.extensions.empty? say "Building native extensions. This could take a while..." start_dir = Dir.pwd dest_path = File.join @gem_dir, @spec.require_paths.first ran_rake = false # only run rake once @spec.extensions.each do |extension| break if ran_rake results = [] builder = case extension when /extconf/ then Gem::Ext::ExtConfBuilder when /configure/ then Gem::Ext::ConfigureBuilder when /rakefile/i, /mkrf_conf/i then ran_rake = true Gem::Ext::RakeBuilder else results = ["No builder for extension '#{extension}'"] nil end begin Dir.chdir File.join(@gem_dir, File.dirname(extension)) results = builder.build(extension, @gem_dir, dest_path, results) rescue => ex results = results.join "\n" File.open('gem_make.out', 'wb') { |f| f.puts results } # ADDED IF CONDITION HERE if @spec.extensions_fallback message = <<-EOF WARNING: Failed to build gem native extension. #{results} Results logged to #{File.join(Dir.pwd, 'gem_make.out')} This Gem has a pure-ruby fallback. You can still proceed to use this package without the native extension. EOF else message = <<-EOF ERROR: Failed to build gem native extension. #{results} Gem files will remain installed in #{@gem_dir} for inspection. Results logged to #{File.join(Dir.pwd, 'gem_make.out')} EOF raise ExtensionBuildError, message end ensure Dir.chdir start_dir end end end From luislavena at gmail.com Wed Nov 7 11:48:06 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 13:48:06 -0300 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> Message-ID: <71166b3b0711070848j1cc88b9au39e763ac375627c4@mail.gmail.com> On 11/7/07, Trans wrote: > Would this suffice for adding a fall back option to Installer? It also > requires that 'extensions_fallback' be added to the gemspec. > Trans, will be better if you provide an unified diff from rubygems svn repository checkout. Also, will be really helpful if you include some tests that prove this is working. 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 hgs at dmu.ac.uk Wed Nov 7 11:32:29 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 7 Nov 2007 16:32:29 +0000 (WET) Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4731B18A.4000603@nixe.ping.de> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> Message-ID: On Wed, 7 Nov 2007, Florian Frank wrote: > Trans wrote: > >>>> I'm a bit confused. If I have a pure-ruby version of my lib, but also > >>>> have some extensions that can speed things up, should the pure-ruby > >>>> gem be named plainly? Eg. 'foo-1.0.0.gem'. But then what platform is [...] > > > > I need to provide these: > > > > * pure ruby version > > * compile-on-install version > > * win32 pre-built version > > > > I would like to make the first two a single gem, rather then two > > separate gems. To do that I need RubyGems not to abort if make fails. [...] > > > If you figure this out, please post the solution to the list. I had/have > exactly the same problem with my json gem, which offers a pure ruby > implementation variant and a faster c extension variant. > I wonder if this could be expressed in the gem spec file (whose format I forget now)? Could a gem "know" to look for a faster version of itself if exists and is up to date, given the version constraints applied to require? What would we need if this were possible: :preferred_alternatives_by_platform => {win32 => thingy-0.1.2, ...} :fallback_alternatives_by_platform => {win32 => slow_thingy-0.1.2, ...} :deprecated_alternatives_by_platform => [...] Not sure what else we'd need to Caveat agnus, I mean lector. Hugh From transfire at gmail.com Wed Nov 7 12:35:35 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 12:35:35 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> Message-ID: <4b6f054f0711070935i22e1a45aj407dbcd6a8fd6807@mail.gmail.com> On Nov 7, 2007 9:08 AM, Trans wrote: > if ENV['NORUBYEXT'] == 'true' > # Rubygems is sending all output to dev/null :( > STDOUT << "NORUBYEXT option is set to true. Native extension will > be omitted." > File.open('Makefile', 'w') do |f| > f << "all:\n" > f << "install:\n" > end > else > if (/mswin/ =~ RUBY_PLATFORM) and ENV['make'].nil? > $LIBS += " msvcprt.lib" > create_makefile(extension_name, "tmail/#{arch}") > else > $CFLAGS += " -D_FILE_OFFSET_BITS=64" #??? > create_makefile(extension_name, "tmail/#{arch}") > end > end The top of this condition didn't quite work for windows. I had to fake windows out by adding: File.open('nmake.bat', 'w'){ |f| f << 'echo' } T. From thewoolleyman at gmail.com Wed Nov 7 15:15:34 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 7 Nov 2007 13:15:34 -0700 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711070758y6f014223n881b590a05f7a19f@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <9e7db9110711062012s6b03b267nbeb17c96213fdeff@mail.gmail.com> <71166b3b0711062058h678a7cfbi333492593976bce0@mail.gmail.com> <9e7db9110711070503w4b6c0499ndd28b63b9734bc2c@mail.gmail.com> <71166b3b0711070758y6f014223n881b590a05f7a19f@mail.gmail.com> Message-ID: On 11/7/07, Luis Lavena wrote: > I'm trying to collect enough info to make this happen, then I can > create a patch and submit to rubyforge. :-D That would be cool. I also think it would help efforts like Tinderbox/Firebrigade. Look at the failure on my gem - if it only knew about my development dependencies, my gem would be green: http://firebrigade.seattlerb.org/build/show/20378 From transfire at gmail.com Wed Nov 7 16:30:17 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 16:30:17 -0500 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <71166b3b0711070848j1cc88b9au39e763ac375627c4@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <71166b3b0711070848j1cc88b9au39e763ac375627c4@mail.gmail.com> Message-ID: <4b6f054f0711071330r4cf25236lbe06d87b2400f106@mail.gmail.com> On Nov 7, 2007 11:48 AM, Luis Lavena wrote: > On 11/7/07, Trans wrote: > > Would this suffice for adding a fall back option to Installer? It also > > requires that 'extensions_fallback' be added to the gemspec. > > > > > Trans, will be better if you provide an unified diff from rubygems svn > repository checkout. Just diff the one file? > Also, will be really helpful if you include some tests that prove this > is working. Ugh, well I'll glance at it. Seems like it could be a tricky thing to test. T. From luislavena at gmail.com Wed Nov 7 16:38:50 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 7 Nov 2007 18:38:50 -0300 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <4b6f054f0711071330r4cf25236lbe06d87b2400f106@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <71166b3b0711070848j1cc88b9au39e763ac375627c4@mail.gmail.com> <4b6f054f0711071330r4cf25236lbe06d87b2400f106@mail.gmail.com> Message-ID: <71166b3b0711071338k75704bcdvdb1f3e6da1da8da5@mail.gmail.com> On 11/7/07, Trans wrote: > On Nov 7, 2007 11:48 AM, Luis Lavena wrote: > > On 11/7/07, Trans wrote: > > > Would this suffice for adding a fall back option to Installer? It also > > > requires that 'extensions_fallback' be added to the gemspec. > > > > > > > > > Trans, will be better if you provide an unified diff from rubygems svn > > repository checkout. > > Just diff the one file? > if you work on a checkout of rubygems, you can do 'svn diff' to get the unified diff of the changes you introduced. > > Also, will be really helpful if you include some tests that prove this > > is working. > > Ugh, well I'll glance at it. Seems like it could be a tricky thing to test. > There are some tests for gems with extensions in it. -- 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 Wed Nov 7 22:50:45 2007 From: transfire at gmail.com (Trans) Date: Wed, 7 Nov 2007 22:50:45 -0500 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711070935i22e1a45aj407dbcd6a8fd6807@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> <4b6f054f0711070935i22e1a45aj407dbcd6a8fd6807@mail.gmail.com> Message-ID: <4b6f054f0711071950p79314b60y71cea30c232b6862@mail.gmail.com> Well, here's my final hack. Now I path RubyGems to handle this the right way. require 'mkmf' require 'rbconfig' FailedMessage.replace("Compilation of native extension failed. Check mkmf.log for details. You may need configuration options. This Gem has a pure-ruby fall back option, so you can still use it. To do so, export the environment variable to NORUBYEXT='true' and gem install again.\n\n") extension_name = 'scanner_c' arch = Config::CONFIG['arch'] windows = (/mswin/ =~ arch) #RUBY_PLATFORM if (ENV['NORUBYEXT'] == 'true') || windows # TEMPORARILY ADD WINDOWS HERE # LETS TRY FAKING IT OUT. if windows File.open('make.bat', 'w') do |f| f << 'echo Native extension will be omitted.' end File.open('nmake.bat', 'w') do |f| f << 'echo Native extension will be omitted.' end end File.open('Makefile', 'w') do |f| f << "all:\n" f << "install:\n" end else if windows && ENV['make'].nil? $LIBS += " msvcprt.lib" #dir_config(extension_name) #create_makefile(extension_name, "tmail") create_makefile(extension_name, "tmail/#{arch}") else $CFLAGS += " -D_FILE_OFFSET_BITS=64" #??? #dir_config(extension_name) #create_makefile(extension_name, "tmail") create_makefile(extension_name, "tmail/#{arch}") end end From tom at infoether.com Thu Nov 8 09:02:23 2007 From: tom at infoether.com (Tom Copeland) Date: Thu, 08 Nov 2007 09:02:23 -0500 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <1194445009.15593.11.camel@bugs.hal> References: <1194445009.15593.11.camel@bugs.hal> Message-ID: <1194530543.22696.25.camel@bugs.hal> On Wed, 2007-11-07 at 09:16 -0500, Tom Copeland wrote: > Hi all - > > Something seems to have changed in the indexer; only certain gems are > getting picked up. For example, for wxruby we now see only: > > ========================== > $ gem install wxruby > Select which gem to install for your platform (i686-linux) > 1. wxruby 1.9.2 (x86_64-linux) > 2. wxruby 1.9.1 (x86_64-linux) > 3. Cancel installation > ========================== Further investigation shows that the indexer thinks most of the wxruby gems are "misnamed"; more details here: http://rubyforge.org/tracker/index.php?func=detail&aid=15417&group_id=5&atid=102 Still not sure exactly which side the problem is on, though... Yours, Tom From luislavena at gmail.com Thu Nov 8 10:50:19 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 8 Nov 2007 12:50:19 -0300 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <1194530543.22696.25.camel@bugs.hal> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> Message-ID: <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> On Nov 8, 2007 11:02 AM, Tom Copeland wrote: > > Further investigation shows that the indexer thinks most of the wxruby > gems are "misnamed"; more details here: > > http://rubyforge.org/tracker/index.php?func=detail&aid=15417&group_id=5&atid=102 > > Still not sure exactly which side the problem is on, though... > Tom, I think is related to the RubyGems version and the specific platform: Gems made with rubygems 0.8.11, and without platform (just RUBY), everything works. Gems made with rubygems 0.8.11 but platform specific (the case of wxRuby), fails. Gems made with rubygems > 0.9.2 without platform (just RUBY), works. Gems made with rubygems > 0.9.2 platform specific, works. It ring a bell to someone? I'm trying to pinpoint where the specific RubyGems version is evaluated... so far didn't find it. -- 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 Thu Nov 8 13:11:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 8 Nov 2007 15:11:02 -0300 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> Message-ID: <71166b3b0711081011he1a99bcga2b3b7ae460cf8e7@mail.gmail.com> On Nov 8, 2007 12:50 PM, Luis Lavena wrote: > On Nov 8, 2007 11:02 AM, Tom Copeland wrote: > > > > Further investigation shows that the indexer thinks most of the wxruby > > gems are "misnamed"; more details here: > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=15417&group_id=5&atid=102 > > > > Still not sure exactly which side the problem is on, though... > > > > Tom, > > I think is related to the RubyGems version and the specific platform: > > Gems made with rubygems 0.8.11, and without platform (just RUBY), > everything works. > Gems made with rubygems 0.8.11 but platform specific (the case of > wxRuby), fails. > Gems made with rubygems > 0.9.2 without platform (just RUBY), works. > Gems made with rubygems > 0.9.2 platform specific, works. > > It ring a bell to someone? I'm trying to pinpoint where the specific > RubyGems version is evaluated... so far didn't find it. > Ok, more information: lib/rubygems/package.rb:568 (load_gemspec) it uses #from_yaml at Specification to load the metadata, and at this point the platform get evaluated (since YAML is converting it to Gem::Specification object). which fires yaml_initialize (specification.rb:734) where: self.platform = Gem::Platform.new @platform and bang!, the original platform gets destroyed. Still, some gems works (like mongrel mswin32) but others fails (like wxRuby ones). This is the pastie for the caller stack of three gems: http://pastie.caboo.se/115525 Gems: mongrel-1.0.1-mswin32.gem wxruby-1.9.0-i386-mswin32.gem wxruby-1.9.0-powerpc-darwin8.10.0.gem -- 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 ryand-ruby at zenspider.com Thu Nov 8 13:46:29 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 8 Nov 2007 10:46:29 -0800 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> Message-ID: <7C6CBEA6-D979-4FD1-BACE-0D0D5EECF492@zenspider.com> On Nov 8, 2007, at 07:50 , Luis Lavena wrote: > I think is related to the RubyGems version and the specific platform: > > Gems made with rubygems 0.8.11, and without platform (just RUBY), > everything works. > Gems made with rubygems 0.8.11 but platform specific (the case of > wxRuby), fails. > Gems made with rubygems > 0.9.2 without platform (just RUBY), works. > Gems made with rubygems > 0.9.2 platform specific, works. > > It ring a bell to someone? I'm trying to pinpoint where the specific > RubyGems version is evaluated... so far didn't find it. Eric is back from post-conf-month vacation and is catching up with life. I suspect he knows the issue and will be on it soon. From luislavena at gmail.com Thu Nov 8 15:37:34 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 8 Nov 2007 17:37:34 -0300 Subject: [Rubygems-developers] Deep thoughts about 0.9.4.6 Message-ID: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> Hello List, Been working along this beta since a few weeks backs, so my understand could not match the one of the creators or big contributors, but found a few issues that I'll really appreciate some insight. - Latest beta always try to use SSL (OpenSSL or SSL in the jruby) even when you don't ask for it (filled a ticket about this). - Currently some gems shipped with "jruby" as platform got missed by the new Indexer: irb(main):003:0> Gem::Platform.local => # irb(main):004:0> Gem::Platform.new 'jruby' => # - Also, the indexer miss some gems due "misnamed gem", which was discussed previously. This raises a new issue: chicken-egg situation: using the new yaml index will force the clients to have latest rubygems to work with, since platform: reference in the spec is now a class. Shouldn't the gem specification version be bumped one time and encapsulate these "differences"? Again, I'm exposing this in my low understanding of the real situation :-) (dumping this here for future references) :-) -- 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 tom at infoether.com Thu Nov 8 18:02:04 2007 From: tom at infoether.com (Tom Copeland) Date: Thu, 08 Nov 2007 18:02:04 -0500 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <7C6CBEA6-D979-4FD1-BACE-0D0D5EECF492@zenspider.com> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> <7C6CBEA6-D979-4FD1-BACE-0D0D5EECF492@zenspider.com> Message-ID: <1194562924.1301.0.camel@bugs.hal> On Thu, 2007-11-08 at 10:46 -0800, Ryan Davis wrote: > On Nov 8, 2007, at 07:50 , Luis Lavena wrote: > > > I think is related to the RubyGems version and the specific platform: > > > > Gems made with rubygems 0.8.11, and without platform (just RUBY), > > everything works. > > Gems made with rubygems 0.8.11 but platform specific (the case of > > wxRuby), fails. > > Gems made with rubygems > 0.9.2 without platform (just RUBY), works. > > Gems made with rubygems > 0.9.2 platform specific, works. > > > > It ring a bell to someone? I'm trying to pinpoint where the specific > > RubyGems version is evaluated... so far didn't find it. > > Eric is back from post-conf-month vacation and is catching up with > life. I suspect he knows the issue and will be on it soon. Cool, right on, sounds good... Yours, Tom From luislavena at gmail.com Thu Nov 8 18:08:27 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 8 Nov 2007 20:08:27 -0300 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <7C6CBEA6-D979-4FD1-BACE-0D0D5EECF492@zenspider.com> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> <7C6CBEA6-D979-4FD1-BACE-0D0D5EECF492@zenspider.com> Message-ID: <71166b3b0711081508l33e52261re9615ebb267413c0@mail.gmail.com> On Nov 8, 2007 3:46 PM, Ryan Davis wrote: > > Eric is back from post-conf-month vacation and is catching up with > life. I suspect he knows the issue and will be on it soon. > Thanks Ryan for the update. -- 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 thewoolleyman at gmail.com Fri Nov 9 12:13:40 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 9 Nov 2007 10:13:40 -0700 Subject: [Rubygems-developers] Deep thoughts about 0.9.4.6 In-Reply-To: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> References: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> Message-ID: On 11/8/07, Luis Lavena wrote: > Hello List, > > Been working along this beta since a few weeks backs, so my understand > could not match the one of the creators or big contributors, but found > a few issues that I'll really appreciate some insight. Thanks for summarizing this, Luis, and for all your other recent efforts on RubyGems.. -- Chad From drbrain at segment7.net Fri Nov 9 16:41:16 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 13:41:16 -0800 Subject: [Rubygems-developers] rubygems over dialup In-Reply-To: References: Message-ID: <316A7822-E805-47DC-915E-C54AB6825E67@segment7.net> On Nov 3, 2007, at 14:27 , Brian Sammon wrote: > Does anyone out there use rubygems over dialup? > Am I correct in my understanding that it wants to download a 12MB > index file > before installing anything? You can use the -B flag to force it to download ~ 9000 files instead, but you have to wait for it to complete :/ > I tried to install a package, and killed rubygems after 15 minutes > because I > was tired of waiting for it. > Does anyone have any practical suggestions for using rubygems 0.9.4 > with a > dialup connection? Manual local installations work :/ Otherwise, no. > Also, what about a progressbar feature? Is anyone working on that? Unfortunately, open-uri does not support progressbars with HTTP, only FTP. I'd like to have a progressbar, but it is not worth the effort to implement. -- 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 Nov 9 16:44:42 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 13:44:42 -0800 Subject: [Rubygems-developers] Gem install not working? In-Reply-To: <4b6f054f0711051109tfb02ffdhfaae601cf3ea925e@mail.gmail.com> References: <4b6f054f0711050908m76e00adak49e5f5f74f4000d6@mail.gmail.com> <71166b3b0711050919r152e14e4h173b9c0b332f11f9@mail.gmail.com> <4b6f054f0711051109tfb02ffdhfaae601cf3ea925e@mail.gmail.com> Message-ID: On Nov 5, 2007, at 11:09 , Trans wrote: > On Nov 5, 2007 12:19 PM, Luis Lavena wrote: >> On 11/5/07, Trans wrote: >>> Something isn't right... >>> >>> trans at transhuttlex:~/Ruby/tmail/trunk$ sudo gem install rake >>> [sudo] password for trans: >>> Need to update 3 gems from http://gems.rubyforge.org >>> ... >>> complete >>> Successfully installed rake-0.7.3 >>> Installing ri documentation for rake-0.7.3... >>> Installing RDoc documentation for rake-0.7.3... >>> trans at transhuttlex:~/Ruby/tmail/trunk$ less /usr/local/lib/ >>> site_ruby/1.8/ >>> i486-linux/ oll.rb pony/ ratch/ roll/ `gem install` never puts anything in site_ruby. >>> trans at transhuttlex:~/Ruby/tmail/trunk$ rake -T >>> The program 'rake' is currently not installed. You can install >>> it by typing: >>> sudo apt-get install rake >> >> 1a) what is your gem env result? >> 1b) did oyu manually install gem? >> 1c) what options did you use to install it? > > It was a debian install of gems. I just tossed it and installed form > source. All better now :-) your PATH may have been wrong. -- 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 Nov 9 16:55:47 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 13:55:47 -0800 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> Message-ID: On Nov 5, 2007, at 19:55 , Trans wrote: > One last question (hopefully). In the gemspec it says: > > extensions > > Type: Array; Optional > Description > > The paths to extconf.rb-style files used to compile extensions. > Usage > > spec.extensions << 'ext/rmagic/extconf.rb' > > Notes > > These files will be run when the gem is installed, causing the C (or > whatever) code to be compiled on the user's machine. > > > But does this have to be extconf.rb scripts? Or can it be any script > in the package? And does gems run 'make' on its own, or does the > extconf.rb (or other) scripts need to do that? extconf.rb, configure, or rakefile or mkrf_conf are supported. -- 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 Nov 9 16:57:45 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 13:57:45 -0800 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> Message-ID: On Nov 5, 2007, at 22:19 , Trans wrote: > On Nov 6, 2007 12:36 AM, Luis Lavena wrote: > >> You should create a test gem and check the whole scenario for your >> own >> understanding of the workflow. >> >> I did and make my life more easy :-) > > Ok. I did it. And it did exactly what you said it would. I can live > with the running of make, but the files do not belong in lib/. They at > least belong in the project subdir, (eg. lib/foo/), but I would expect > there would be some way to specify where to put them. Is there? Typically you want ext/foo/foo.c => ext/foo/foo.so, and require 'foo/ foo' to work so your build process shouldn't install anything, instead you should add ext/ to your require_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 Nov 9 17:04:27 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 14:04:27 -0800 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> Message-ID: <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> On Nov 7, 2007, at 08:45 , Trans wrote: > Would this suffice for adding a fall back option to Installer? It also > requires that 'extensions_fallback' be added to the gemspec. extconf.rb can be set up to do this already. Check for all your dependencies, and if one of them doesn't exist, generate a Makefile that does nothing. If you fail to compile for some other reason, I think it is too dangerous to automatically fall back. -- 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 Nov 9 17:15:18 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 14:15:18 -0800 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> <4b6f054f0711070608g5cbf728au83a4c45c1e8214e6@mail.gmail.com> Message-ID: <5A6E4D00-7393-4F8C-981A-67245D66134A@segment7.net> On Nov 7, 2007, at 06:08 , Trans wrote: > FailedMessage.replace("Could not create Makefile, probably for the > lack of necessary libraries and/or headers. Check the mkmf.log file > for more details. You may need configuration options (see below). > TMail has a pure-ruby fallback mode, so you can still use this > library. To do so, set the environment variable, export > NORUBYEXT='true', and gem install again.\n\n") Why not just generate the do-nothing Makefile instead of telling the user to force it, if that's the behavior you want? -- 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 Nov 9 17:22:24 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 14:22:24 -0800 Subject: [Rubygems-developers] pure-ruby vs. compile-on-intsall In-Reply-To: References: <4b6f054f0711051638g5effaf00i718503414150593c@mail.gmail.com> <71166b3b0711052133t27b1e4fdt6c45e529d643f17c@mail.gmail.com> <4b6f054f0711052141m3c120193u10a486a219f38269@mail.gmail.com> <4b6f054f0711070150l3f390fdfudb687909f32f3be4@mail.gmail.com> <4731B18A.4000603@nixe.ping.de> Message-ID: On Nov 7, 2007, at 08:32 , Hugh Sasse wrote: > I wonder if this could be expressed in the gem spec file (whose > format I forget now)? Could a gem "know" to look for a faster > version of itself if exists and is up to date, given the version > constraints applied to require? extconf.rb & friends are flexible enough to handle this in exactly the manner the author intends, and that seems to be a workable solution. -- 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 Nov 9 17:31:53 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 14:31:53 -0800 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> Message-ID: <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> On Nov 5, 2007, at 07:02 , Luis Lavena wrote: >> I wish we had unified packages, though, rather then having to create >> separate packages for each platform. >> > > The problem will that will be how identify extensions compiled for > windows, linux or darwin, all in the same package. > > Kernel#require is not clever as rubygems require version to find the > matching -mswin32 or -darwin or -bsd version of the specific > extension. At RubyConf, we (RubyGems & ruby-core members) decided moving away from modifying Kernel#require was a good thing. Besides, there are plenty of tools to completely automate every step of releasing a gem. If you're doing it right, releasing a platform gem is as easy as `rake release`. -- 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 Nov 9 17:47:51 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 14:47:51 -0800 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> Message-ID: <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> On Nov 6, 2007, at 18:44 , Luis Lavena wrote: > Been updating some gems locally (crafted by myself) and found a > curious situation: > > Eric told me on #ruby-lang that Hoe include itself as dependency since > it's needed to perform gem 'check' operations. > > Also, on FireBrigade, 'as gem developer' there is listed that Rake and > RSpec are included if Rakefile or spec/* folder is found in the gem, > just to ease the task if you forgot to include. > > This raise me the question: this is right? I mean, sometimes when I > download some gems, I trust they work as expected by the release > notes. If not, I checkout the source code (if some repo is available) > and perform my tests locally. > > For some gems it's overkill to depend on rspec when you're working > with trunk to perform some test -- since there is no official release > of latest changes -- and include vendor/rspec distract from the task. > > What is the best approach for this? Include everything as dependency? Including everything is the best approach. My conclusion is that people only want to bikeshed[1] about this topic. They don't want to define an actual solution. When this issue first came up (with hoe) people complained loudly, and I told them that the best way to handle this would be "developer dependencies". It took eight months for the feature request to show up on the tracker[2]. Two and a half months later, the requester hasn't defined how they think developer dependencies are supposed to work. Things that need to be discussed are: * should developer dependencies by installed by default? * what does the command-line option look like? * what happens on uninstall? * what should `gem check` do if all dependencies aren't installed? Before attempting a patch, I think at least these questions should be answered. There are probably more, since getting it to work well requires changes and hooks in lots of places. Its really easy to say "gems should have developer dependencies". Its a lot of work to make it a reality. [1] http://www.bikeshed.org/ [2] http://rubyforge.org/tracker/index.php? func=detail&aid=13287&group_id=126&atid=578 -- 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 thewoolleyman at gmail.com Fri Nov 9 19:08:30 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 9 Nov 2007 17:08:30 -0700 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> Message-ID: On 11/9/07, Eric Hodel wrote: > > What is the best approach for this? Include everything as dependency? > > Including everything is the best approach. > > Things that need to be discussed are: > * should developer dependencies by installed by default? > * what does the command-line option look like? > * what happens on uninstall? > * what should `gem check` do if all dependencies aren't installed? > > Its really easy to say "gems should have developer dependencies". > Its a lot of work to make it a reality. > > [1] http://www.bikeshed.org/ > [2] http://rubyforge.org/tracker/index.php? > func=detail&aid=13287&group_id=126&atid=578 Hi, I'm really trying to NOT bikeshed, and know I won't have the time to do anything about it other than pimp my tool I wrote to address this issue. I agree that this will probably be really hard to implement in rubygems, and I'll believe you that it's not worth it. However, there's still valid reasons for both sides of the argument. On one hand, it can be considered dangerous to include unused dependencies on a production box. Here's a real case in point that just happened to us on a shared box. There's a bug in the latest edge rails gem that the mere existence of an unused soap4r dependency causes failures: http://dev.rubyonrails.org/ticket/10001 Now, we were able to handle this by auto-installing and locking down the soap4r version (using GemInstaller), and we were proactive enough to find it on a demo box instead of prod, but it's still an example of a completely unrelated dependency causing problems. Also, in some cases, it just obviously doesn't make sense to include all dependencies. For example, on GemInstaller, it is a tool itself to manage dependencies, and I don't want to force everyone who uses it to install the dozen-plus build- and deploy- and test-time dependencies I have (http://geminstaller.rubyforge.org/svn/trunk/geminstaller.yml). This would freak some people out when they installed it and make them not want to use the gem. Plus, it's very likely (especially in the case of Rspec) that one of my dependency versions conflicts with something else on their system, and unless they have their rspec version locked down everywhere (unlikely) the mere installation of my gem will screw them if it auto-installs a newer version of rspec that's incompatible with their old specs. Now, playing advocate for the other side, it may be a GOOD thing to always include all dependencies on all platforms. By NOT doing so, you may open yourself up to unexpected behavior on non-development platforms. This could happen if the absence of a 'development' dependency somehow breaks your application through the dynamic magic of Ruby. This is very possible, and I think I just convinced myself that I agree with you, at least in the case of Rails apps (because this is what we've done for dozens of projects and it works fine). Regardless, there are valid points on both sides. If building this support into RubyGems really is too hard (and I believe you), then we need alternate approaches. Ok, pimp-mode on: I think that my GemInstaller tool (http://geminstaller.rubyforge.org) is perfect for this - it centrally manaages all your dependencies via an erb-parsed file (or files). This allows you to explicitly manage your dependencies, and have them behave differently based on whatever criteria you want - RAILS_ENV, hostname, environment variables, whatever. If you have a startup check in your app that installs and loads the appropriate gems in development or test mode (rake or test_helper), then you can only include actual runtime dependencies in your gem, but ensure that anyone who wants to build/test your app still has the gems they need. Thanks, -- Chad From transfire at gmail.com Fri Nov 9 19:09:25 2007 From: transfire at gmail.com (Trans) Date: Fri, 9 Nov 2007 19:09:25 -0500 Subject: [Rubygems-developers] gemspec extensions attribute In-Reply-To: References: <4b6f054f0711051955s79d4dd2fpe96e6e328ec67369@mail.gmail.com> <71166b3b0711052136h48d9d22dre0e55f7d2d80e8d0@mail.gmail.com> <4b6f054f0711052219y4313588dlac90647377d3ca96@mail.gmail.com> Message-ID: <4b6f054f0711091609s6317e03cqa85f8515c17cb3b8@mail.gmail.com> On Nov 9, 2007 4:57 PM, Eric Hodel wrote: > On Nov 5, 2007, at 22:19 , Trans wrote: > > On Nov 6, 2007 12:36 AM, Luis Lavena wrote: > > > >> You should create a test gem and check the whole scenario for your > >> own > >> understanding of the workflow. > >> > >> I did and make my life more easy :-) > > > > Ok. I did it. And it did exactly what you said it would. I can live > > with the running of make, but the files do not belong in lib/. They at > > least belong in the project subdir, (eg. lib/foo/), but I would expect > > there would be some way to specify where to put them. Is there? > > Typically you want ext/foo/foo.c => ext/foo/foo.so, and require 'foo/ > foo' to work > > so your build process shouldn't install anything, instead you should > add ext/ to your require_path. Ok. That's what I thought originally. Thanks, T. From drbrain at segment7.net Fri Nov 9 19:10:09 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 16:10:09 -0800 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <71166b3b0711081011he1a99bcga2b3b7ae460cf8e7@mail.gmail.com> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> <71166b3b0711081011he1a99bcga2b3b7ae460cf8e7@mail.gmail.com> Message-ID: <728D8192-4464-490B-97B0-A9441DBB19AE@segment7.net> On Nov 8, 2007, at 10:11 , Luis Lavena wrote: > On Nov 8, 2007 12:50 PM, Luis Lavena wrote: >> On Nov 8, 2007 11:02 AM, Tom Copeland wrote: >>> Further investigation shows that the indexer thinks most of the >>> wxruby >>> gems are "misnamed"; more details here: >>> >>> http://rubyforge.org/tracker/index.php? >>> func=detail&aid=15417&group_id=5&atid=102 >>> >>> Still not sure exactly which side the problem is on, though... >> >> I think is related to the RubyGems version and the specific platform: >> >> Gems made with rubygems 0.8.11, and without platform (just RUBY), >> everything works. >> Gems made with rubygems 0.8.11 but platform specific (the case of >> wxRuby), fails. >> Gems made with rubygems > 0.9.2 without platform (just RUBY), works. >> Gems made with rubygems > 0.9.2 platform specific, works. >> >> It ring a bell to someone? I'm trying to pinpoint where the specific >> RubyGems version is evaluated... so far didn't find it. > > Ok, more information: > > lib/rubygems/package.rb:568 (load_gemspec) > > it uses #from_yaml at Specification to load the metadata, and at this > point the platform get evaluated (since YAML is converting it to > Gem::Specification object). > > which fires yaml_initialize (specification.rb:734) where: > > self.platform = Gem::Platform.new @platform > > and bang!, the original platform gets destroyed. I made some changes to record the original platform (from spec) for uninstallation to work, but didn't extend that to the indexer. > mongrel-1.0.1-mswin32.gem > wxruby-1.9.0-i386-mswin32.gem > wxruby-1.9.0-powerpc-darwin8.10.0.gem trunk has all these gems being indexed 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 transfire at gmail.com Fri Nov 9 19:14:51 2007 From: transfire at gmail.com (Trans) Date: Fri, 9 Nov 2007 19:14:51 -0500 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> Message-ID: <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> On Nov 9, 2007 5:04 PM, Eric Hodel wrote: > On Nov 7, 2007, at 08:45 , Trans wrote: > > > Would this suffice for adding a fall back option to Installer? It also > > requires that 'extensions_fallback' be added to the gemspec. > > extconf.rb can be set up to do this already. Check for all your > dependencies, and if one of them doesn't exist, generate a Makefile > that does nothing. If you fail to compile for some other reason, I > think it is too dangerous to automatically fall back. That doesn't work if there is no make/nmake on the system. Plus, the fall back is pure ruby. So if it fails for _any reason_ it would be okay --that's the point. It would just give a warning that native extension didn't compile, but the library was still usable in pure ruby "mode". T. From transfire at gmail.com Fri Nov 9 19:23:02 2007 From: transfire at gmail.com (Trans) Date: Fri, 9 Nov 2007 19:23:02 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> Message-ID: <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> On Nov 9, 2007 5:31 PM, Eric Hodel wrote: > On Nov 5, 2007, at 07:02 , Luis Lavena wrote: > >> I wish we had unified packages, though, rather then having to create > >> separate packages for each platform. > >> > > > > The problem will that will be how identify extensions compiled for > > windows, linux or darwin, all in the same package. > > > > Kernel#require is not clever as rubygems require version to find the > > matching -mswin32 or -darwin or -bsd version of the specific > > extension. > > At RubyConf, we (RubyGems & ruby-core members) decided moving away > from modifying Kernel#require was a good thing. > > Besides, there are plenty of tools to completely automate every step > of releasing a gem. If you're doing it right, releasing a platform > gem is as easy as `rake release`. Yes. I've reconsidered my position. I think a platform gem is a rather special case. For instance a Windows binary, b/c Windows often lacks the needed compile tools. But on most other systems it seems unccessary. Is that a fair assessment? T. From drbrain at segment7.net Fri Nov 9 20:10:43 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 17:10:43 -0800 Subject: [Rubygems-developers] Deep thoughts about 0.9.4.6 In-Reply-To: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> References: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> Message-ID: <9DBEAC69-F8EE-4692-B625-0446FCC05F7C@segment7.net> On Nov 8, 2007, at 12:37 , Luis Lavena wrote: > Been working along this beta since a few weeks backs, so my understand > could not match the one of the creators or big contributors, but found > a few issues that I'll really appreciate some insight. > > - Latest beta always try to use SSL (OpenSSL or SSL in the jruby) even > when you don't ask for it (filled a ticket about this). I think this is too invasive to fix right now. Maybe for the next release. > - Currently some gems shipped with "jruby" as platform got missed by > the new Indexer: Fixed. > - Also, the indexer miss some gems due "misnamed gem", which was > discussed previously. Fixed. > This raises a new issue: chicken-egg situation: using the new yaml > index will force the clients to have latest rubygems to work with, > since platform: reference in the spec is now a class. The yaml index should be backwards compatible. If its not, then RubyGems has a bug. I changed things around some by storing a Gem::Platform in @new_platform, and leaving @platform alone (as best I could). This should fix the YAML problems with respect to backwards compatibility. > Shouldn't the gem specification version be bumped one time and > encapsulate these "differences"? It has, but the code in Gem::Specification doesn't handle forward- compatiblity well. I've worked around it as much as I can. -- 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 Nov 9 20:33:08 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 17:33:08 -0800 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> Message-ID: <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> On Nov 9, 2007, at 16:08 , Chad Woolley wrote: > On 11/9/07, Eric Hodel wrote: >>> What is the best approach for this? Include everything as >>> dependency? >> >> Including everything is the best approach. >> >> Things that need to be discussed are: >> * should developer dependencies by installed by default? >> * what does the command-line option look like? >> * what happens on uninstall? >> * what should `gem check` do if all dependencies aren't installed? >> >> Its really easy to say "gems should have developer dependencies". >> Its a lot of work to make it a reality. >> >> [1] http://www.bikeshed.org/ >> [2] http://rubyforge.org/tracker/index.php? >> func=detail&aid=13287&group_id=126&atid=578 > > Hi, > > I'm really trying to NOT bikeshed, and know I won't have > the time to do anything about it other than pimp my tool I wrote to > address this issue. Granted. In the general community (ruby-talk) there is much bikeshedding about this feature request and no action. You're probably the person most-likely to have a valid opinion about how the feature should behave. > I agree that this will probably be really hard to implement in > rubygems, and I'll believe you that it's not worth it. However, > there's still valid reasons for both sides of the argument. I'm not saying its not worth doing, but it's much, much easier said than done. > On one hand, it can be considered dangerous to include unused > dependencies on a production box. Here's a real case in point that > just happened to us on a shared box. There's a bug in the latest edge > rails gem that the mere existence of an unused soap4r dependency > causes failures: http://dev.rubyonrails.org/ticket/10001 Now, we were > able to handle this by auto-installing and locking down the soap4r > version (using GemInstaller), and we were proactive enough to find it > on a demo box instead of prod, but it's still an example of a > completely unrelated dependency causing problems. Granted, but I think that's orthogonal to this feature. (Especially since you're using a development version of something in production.) > Also, in some cases, it just obviously doesn't make sense to include > all dependencies. For example, on GemInstaller, it is a tool itself > to manage dependencies, and I don't want to force everyone who uses it > to install the dozen-plus build- and deploy- and test-time > dependencies I have > (http://geminstaller.rubyforge.org/svn/trunk/geminstaller.yml). This > would freak some people out when they installed it and make them not > want to use the gem. I've installed things that easily have more dependencies than that. I think lots of dependencies with a small gem is a good thing, since it means the author is probably being a good citizen. I've heard an alternate version of this argument, "I audit everything, and this is too much", but there's just too much code out there for me believe any effective auditing is performed. (For example, recent vulnerabilities in pcre and perl with respect to regular expressions.) > Plus, it's very likely (especially in the case > of Rspec) that one of my dependency versions conflicts with something > else on their system, and unless they have their rspec version locked > down everywhere (unlikely) the mere installation of my gem will screw > them if it auto-installs a newer version of rspec that's incompatible > with their old specs. I believe that RubyGems has the ability to handle this gracefully with sane versioning schemes combined with the existing requirement specifiers (including '~>'), and that this is primarily a gem author education problem. When severity of changes doesn't match changes in version numbers, everybody is going to suffer. > Now, playing advocate for the other side, it may be a GOOD thing to > always include all dependencies on all platforms. By NOT doing so, > you may open yourself up to unexpected behavior on non-development > platforms. This could happen if the absence of a 'development' > dependency somehow breaks your application through the dynamic magic > of Ruby. This is very possible, and I think I just convinced myself > that I agree with you, at least in the case of Rails apps (because > this is what we've done for dozens of projects and it works fine). FreeBSD's ports has run and build dependencies. I think its fine for RubyGems to have an equivalent. Retrofitting the distinction on is complicated, though. > Regardless, there are valid points on both sides. If building this > support into RubyGems really is too hard (and I believe you), then we > need alternate approaches. Again, I don't think it's too hard, but it is harder than people think. Or, it's easy, once we know exactly what it is supposed to do (which is hard). > Ok, pimp-mode on: I think that my GemInstaller tool > (http://geminstaller.rubyforge.org) is perfect for this - it centrally > manaages all your dependencies via an erb-parsed file (or files). > This allows you to explicitly manage your dependencies, and have them > behave differently based on whatever criteria you want - RAILS_ENV, > hostname, environment variables, whatever. If you have a startup > check in your app that installs and loads the appropriate gems in > development or test mode (rake or test_helper), then you can only > include actual runtime dependencies in your gem, but ensure that > anyone who wants to build/test your app still has the gems they need. For production Rails apps, I tend manually lock down versions explicitly. `gem lock` is a lightweight way to generate the #gem calls for this (which I discovered recently), but doesn't handle all the other issues that your tool does. -- 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 Nov 9 20:35:15 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 17:35:15 -0800 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> Message-ID: On Nov 9, 2007, at 16:23 , Trans wrote: > On Nov 9, 2007 5:31 PM, Eric Hodel wrote: >> On Nov 5, 2007, at 07:02 , Luis Lavena wrote: >>>> I wish we had unified packages, though, rather then having to >>>> create >>>> separate packages for each platform. >>> >>> The problem will that will be how identify extensions compiled for >>> windows, linux or darwin, all in the same package. >>> >>> Kernel#require is not clever as rubygems require version to find the >>> matching -mswin32 or -darwin or -bsd version of the specific >>> extension. >> >> At RubyConf, we (RubyGems & ruby-core members) decided moving away >> from modifying Kernel#require was a good thing. >> >> Besides, there are plenty of tools to completely automate every step >> of releasing a gem. If you're doing it right, releasing a platform >> gem is as easy as `rake release`. > > Yes. I've reconsidered my position. I think a platform gem is a rather > special case. For instance a Windows binary, b/c Windows often lacks > the needed compile tools. But on most other systems it seems > unccessary. Is that a fair assessment? I think so. Most other systems have compilers by default, or a compiler can easily be added to them. -- 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 Nov 9 22:44:41 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 10 Nov 2007 00:44:41 -0300 Subject: [Rubygems-developers] Deep thoughts about 0.9.4.6 In-Reply-To: <9DBEAC69-F8EE-4692-B625-0446FCC05F7C@segment7.net> References: <71166b3b0711081237t33d81e35n5a99c2e71555e161@mail.gmail.com> <9DBEAC69-F8EE-4692-B625-0446FCC05F7C@segment7.net> Message-ID: <71166b3b0711091944j7b35eb34p50032e6982e49bda@mail.gmail.com> On Nov 9, 2007 10:10 PM, Eric Hodel wrote: > > I changed things around some by storing a Gem::Platform in > @new_platform, and leaving @platform alone (as best I could). This > should fix the YAML problems with respect to backwards compatibility. > > > Shouldn't the gem specification version be bumped one time and > > encapsulate these "differences"? > > It has, but the code in Gem::Specification doesn't handle forward- > compatiblity well. I've worked around it as much as I can. > Thank you Eric. I understand the complexity of the situation, also that RubyGems could came the point of failure of the whole ruby-on-your-platform since almost every ruby library or application right now is bundled as gem. And everybody knows that you exceed the average expectations on fixing and finding solutions or workaround for all these problems. Again, thank 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 luislavena at gmail.com Fri Nov 9 23:09:02 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 10 Nov 2007 01:09:02 -0300 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> Message-ID: <71166b3b0711092009h3b78831k8bf4051a5fd4cfe9@mail.gmail.com> On Nov 9, 2007 7:47 PM, Eric Hodel wrote: > > Including everything is the best approach. > > My conclusion is that people only want to bikeshed[1] about this > topic. They don't want to define an actual solution. When this > issue first came up (with hoe) people complained loudly, and I told > them that the best way to handle this would be "developer > dependencies". It took eight months for the feature request to show > up on the tracker[2]. Two and a half months later, the requester > hasn't defined how they think developer dependencies are supposed to > work. > Thanks for the bikeshed reference, I wasn't aware of the right term in english. :-) Please excuse the noise, I missed the discussion about this (maybe I joined the party too late) :-P > Things that need to be discussed are: > * should developer dependencies by installed by default? > * what does the command-line option look like? > * what happens on uninstall? > * what should `gem check` do if all dependencies aren't installed? > I'm seeing this like apt-get build-dep command (and lot of users will argue this is not the best way) -- still, fits best: if you intent to build ruby1.8, you need to download the packages that are marked as dependencies for compilation/build: sudo apt-get build-dep ruby1.8 Now, you can grab the source code for ruby1.8 and start the compile process (if you have the compiler installed, of course) I see the compile process as the 'rake compile test package' tasks sequence. Uninstalling of the gem isn't related here, mostly since you're trying to build from source or perform some kind of check for the gem. 'gem check' should only yell at you that not all the dependencies for testing/building are installed, and guide you to 'build-dep ' to correct the issue. I must honestly say what I don't know what to do with orphaned gems, mostly since these gems could the useful for others or even the final user: - I manually install rspec for my own, personal use. - Try to do some work on DataMapper, which need rspec as build-dep - gem build-dep datamapper - rake test package (datamapper) and then gem install it. - Found it good, but just got bored of it (gem uninstall datamapper) - rspec shouldn't be removed... even if it's a build dependency of datamapper and there isn't another gem using it. > Before attempting a patch, I think at least these questions should be > answered. There are probably more, since getting it to work well > requires changes and hooks in lots of places. > What about a proof of concept? maybe using some text field of the specification to track this... and create the fake build-dep command that use that information and manage the installation of dependencies? > Its really easy to say "gems should have developer dependencies". > Its a lot of work to make it a reality. > Is easier say than do... "show me the code" often came after that line ;-) 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 luislavena at gmail.com Fri Nov 9 23:12:53 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 10 Nov 2007 01:12:53 -0300 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> Message-ID: <71166b3b0711092012i37eaf40et759abacd19b4c5ea@mail.gmail.com> On Nov 9, 2007 9:14 PM, Trans wrote: > On Nov 9, 2007 5:04 PM, Eric Hodel wrote: > > On Nov 7, 2007, at 08:45 , Trans wrote: > > > > > Would this suffice for adding a fall back option to Installer? It also > > > requires that 'extensions_fallback' be added to the gemspec. > > > > extconf.rb can be set up to do this already. Check for all your > > dependencies, and if one of them doesn't exist, generate a Makefile > > that does nothing. If you fail to compile for some other reason, I > > think it is too dangerous to automatically fall back. > > That doesn't work if there is no make/nmake on the system. Plus, the > fall back is pure ruby. So if it fails for _any reason_ it would be > okay --that's the point. It would just give a warning that native > extension didn't compile, but the library was still usable in pure > ruby "mode". > The only problem is nmake. make can handle empty makefiles, also nmake (if present). If all the steps you test in extconf.rb fails, you should create nmake.bat and create the empty makefile. I guess that will work... but must validate my idea later (with a windows machine handy) :) -- 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 Fri Nov 9 23:39:53 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Fri, 9 Nov 2007 23:39:53 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> Message-ID: <9e7db9110711092039p1e8a1e4fk94ac6e0779c28dea@mail.gmail.com> On 11/9/07, Eric Hodel wrote: > On Nov 9, 2007, at 16:23 , Trans wrote: > > Yes. I've reconsidered my position. I think a platform gem is a rather > > special case. For instance a Windows binary, b/c Windows often lacks > > the needed compile tools. But on most other systems it seems > > unccessary. Is that a fair assessment? > I think so. Most other systems have compilers by default, or a > compiler can easily be added to them. Erm. It's mostly a theoretical at this point, but if I wanted to do something with Ruby on ESX Server Console (a variant of Red Hat ES 3), I'd be SOL if I wanted to install an extension gem using the "gem" command. It would be nice to have the ability to do a "gem repack" or something like that to take a currently installed gem and repack it into a new deployable gem that could be used locally. -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 tom at infoether.com Sat Nov 10 00:29:45 2007 From: tom at infoether.com (Tom Copeland) Date: Sat, 10 Nov 2007 00:29:45 -0500 Subject: [Rubygems-developers] Platform-specific gems not getting picked up in the index In-Reply-To: <728D8192-4464-490B-97B0-A9441DBB19AE@segment7.net> References: <1194445009.15593.11.camel@bugs.hal> <1194530543.22696.25.camel@bugs.hal> <71166b3b0711080750g15470d80r622d63f94de13846@mail.gmail.com> <71166b3b0711081011he1a99bcga2b3b7ae460cf8e7@mail.gmail.com> <728D8192-4464-490B-97B0-A9441DBB19AE@segment7.net> Message-ID: <1194672585.1301.48.camel@bugs.hal> On Fri, 2007-11-09 at 16:10 -0800, Eric Hodel wrote: > > mongrel-1.0.1-mswin32.gem > > wxruby-1.9.0-i386-mswin32.gem > > wxruby-1.9.0-powerpc-darwin8.10.0.gem > > trunk has all these gems being indexed now. As does RubyForge now, thanks for the fix, Eric! Yours, Tom From drbrain at segment7.net Sat Nov 10 02:41:02 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 9 Nov 2007 23:41:02 -0800 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <9e7db9110711092039p1e8a1e4fk94ac6e0779c28dea@mail.gmail.com> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <3ff47be90711041941oa5989f0ob66a02dded7e2bb9@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> <9e7db9110711092039p1e8a1e4fk94ac6e0779c28dea@mail.gmail.com> Message-ID: <93D7BDFB-FA66-488E-BA76-2BEE661CD54F@segment7.net> On Nov 9, 2007, at 20:39 , Austin Ziegler wrote: > On 11/9/07, Eric Hodel wrote: >> On Nov 9, 2007, at 16:23 , Trans wrote: >>> Yes. I've reconsidered my position. I think a platform gem is a >>> rather >>> special case. For instance a Windows binary, b/c Windows often lacks >>> the needed compile tools. But on most other systems it seems >>> unccessary. Is that a fair assessment? >> I think so. Most other systems have compilers by default, or a >> compiler can easily be added to them. > > Erm. It's mostly a theoretical at this point, but if I wanted to do > something with Ruby on ESX Server Console (a variant of Red Hat ES 3), > I'd be SOL if I wanted to install an extension gem using the "gem" > command. > > It would be nice to have the ability to do a "gem repack" or something > like that to take a currently installed gem and repack it into a new > deployable gem that could be used locally. hrm, maybe `gem unpack` plus `gem spec > file` plus `gem build file`. (I didn't verify if those three would work.) -- 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 Nov 10 06:05:51 2007 From: transfire at gmail.com (Trans) Date: Sat, 10 Nov 2007 06:05:51 -0500 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <71166b3b0711092012i37eaf40et759abacd19b4c5ea@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> <71166b3b0711092012i37eaf40et759abacd19b4c5ea@mail.gmail.com> Message-ID: <4b6f054f0711100305w57a28a8evd20be6814905d918@mail.gmail.com> On Nov 9, 2007 11:12 PM, Luis Lavena wrote: > > On Nov 9, 2007 9:14 PM, Trans wrote: > > On Nov 9, 2007 5:04 PM, Eric Hodel wrote: > > > On Nov 7, 2007, at 08:45 , Trans wrote: > > > > > > > Would this suffice for adding a fall back option to Installer? It also > > > > requires that 'extensions_fallback' be added to the gemspec. > > > > > > extconf.rb can be set up to do this already. Check for all your > > > dependencies, and if one of them doesn't exist, generate a Makefile > > > that does nothing. If you fail to compile for some other reason, I > > > think it is too dangerous to automatically fall back. > > > > That doesn't work if there is no make/nmake on the system. Plus, the > > fall back is pure ruby. So if it fails for _any reason_ it would be > > okay --that's the point. It would just give a warning that native > > extension didn't compile, but the library was still usable in pure > > ruby "mode". > > > > The only problem is nmake. make can handle empty makefiles, also nmake > (if present). > > If all the steps you test in extconf.rb fails, you should create > nmake.bat and create the empty makefile. > > I guess that will work... but must validate my idea later (with a > windows machine handy) :) If you read my prior poists, you would know that's exactly what I did with the current TMail gem. And in no uncertain terms it is a complete *hack*. Nor is it a perfect solution. If nmake or make is not present it still bombs. I would like to know the RubyGems official policy on supporting a pure-ruby version of a library that can also have platform extensions. As far as I can tell, there is no clear policy for this. T. From halostatue at gmail.com Sat Nov 10 07:56:34 2007 From: halostatue at gmail.com (Austin Ziegler) Date: Sat, 10 Nov 2007 07:56:34 -0500 Subject: [Rubygems-developers] How to bundle up MS Windows version separately In-Reply-To: <93D7BDFB-FA66-488E-BA76-2BEE661CD54F@segment7.net> References: <57a815bf0711041935l521d7eaekd4ebc316667e3bf6@mail.gmail.com> <4b6f054f0711041946y49d2a7abm591785f8c3a60bc7@mail.gmail.com> <71166b3b0711050635y3fac9298v7df07e6c4b1ebf12@mail.gmail.com> <4b6f054f0711050650o10e3b083j655902fac9e0220d@mail.gmail.com> <71166b3b0711050702t60f393a6t7012ed59d8767cd3@mail.gmail.com> <51ACBE29-F35B-4D7F-999D-F38A4ECAC438@segment7.net> <4b6f054f0711091623p65e693c5j5cf74e9f4696e30a@mail.gmail.com> <9e7db9110711092039p1e8a1e4fk94ac6e0779c28dea@mail.gmail.com> <93D7BDFB-FA66-488E-BA76-2BEE661CD54F@segment7.net> Message-ID: <9e7db9110711100456i24fa9b42h9b72bd4eccf53e62@mail.gmail.com> On 11/10/07, Eric Hodel wrote: > hrm, maybe `gem unpack` plus `gem spec > file` plus `gem build > file`. (I didn't verify if those three would work.) I'll put this on a "I should look at this list" and try to look at it soon. If it works, then it'll be worth documenting that, at least. -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 thewoolleyman at gmail.com Sat Nov 10 14:26:00 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 10 Nov 2007 12:26:00 -0700 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> Message-ID: On 11/9/07, Eric Hodel wrote: > On Nov 9, 2007, at 16:08 , Chad Woolley wrote: > > I don't want to force everyone who uses it > > to install the dozen-plus build- and deploy- and test-time > > dependencies I have. This > > would freak some people out when they installed it and make them not > > want to use the gem. > > I've installed things that easily have more dependencies than that. > I think lots of dependencies with a small gem is a good thing, since > it means the author is probably being a good citizen. Hmm. Interesting, and still a matter of opinion :) Why does that make you a good citizen? Because you are reusing code? Or because you are being explicit about your dependencies? In my experience, I've found that LESS actual dependencies is a good thing, because that's less opportunity for me to get in dependency hell (incompatibilities that I don't understand or can't resolve). For example, I started using needle on my project, but then rolled my own DI so I wouldn't have that dependency, and it was simpler and better-tested. Granted, this is probably a somewhat-unnecessary holdover from my Java days, because it's much easier to deal with this in ruby by monkey-patching. > > Plus, it's very likely (especially in the case > > of Rspec) that one of my dependency versions conflicts with something > > else on their system, and unless they have their rspec version locked > > down everywhere (unlikely) the mere installation of my gem will screw > > them if it auto-installs a newer version of rspec that's incompatible > > with their old specs. > > I believe that RubyGems has the ability to handle this gracefully > with sane versioning schemes combined with the existing requirement > specifiers (including '~>'), and that this is primarily a gem author > education problem. When severity of changes doesn't match changes in > version numbers, everybody is going to suffer. Sorry, I've gotta disagree here (and I'm_definitely not bikeshedding here, because my and my shop, which includes an rspec committer, are early rspec adopters, and we have been along for the whole ride). Even if rspec had sane versiong schemes (which they really don't), it wouldn't solve the problem I mentioned: 1. I force a newer version of rspec to be installed with my gem because it's a test dependency 2. User installs my gem, and they could care less about ever building or testing it, they just want to use it 3. The newer version of rspec breaks all my user's tests, because they don't have their rspec version locked down in their app 4. User gets pissed because my gem "broke" them. Yes, it's their fault for not locking down their rspec version, but the user is always right! Plus, they have a somewhat valid reason to be pissed, because the newer version of rspec is completely unnecessary for my gem to work correctly for them. This scenario is amplified with rspec, which has no compunctions about drastically changing their API (sane versioning aside, there's nothing fundamentally wrong with that), but it can apply to any library that is primarily used as a development dependency. To me, the "right" thing to do is not force the installation of a gem that I know is unnecesary at runtime, and is likely to spew deprecation if not break many users. I'm being a better citizen if I reliabily make sure the right dependencies is installed and used whenever somebody DOES want to build or test my gem, and don't force an unnecessary runtime dependency. And (pimpmode) this is really easy to do with GemInstaller. > FreeBSD's ports has run and build dependencies. I think its fine for > RubyGems to have an equivalent. Retrofitting the distinction on is > complicated, though. > > Again, I don't think it's too hard, but it is harder than people > think. Or, it's easy, once we know exactly what it is supposed to do > (which is hard). Right. Now we just need someone to get on that :) > > > Ok, pimp-mode on: I think that my GemInstaller tool > > (http://geminstaller.rubyforge.org) is perfect for this > > For production Rails apps, I tend manually lock down versions > explicitly. `gem lock` is a lightweight way to generate the #gem > calls for this (which I discovered recently), but doesn't handle all > the other issues that your tool does. Yes - we do lots of cool stuff with it that's handy in a large, Agile Rails shop - like: * locking down all apps' dependencies in a standard yaml file with common bits extracted across apps * allowing apps with different dependency version requirements to run without hassles across a variety of shared pair-stations * overriding to use a specified beta rails gem based on a env var, auto-installing all new required gems across all dev/ci/demo/prod boxes * centrally dealing with silly issues so every app in the shop doesn't have to deal with them individually (like the latest Edge Rails gem requiring soap4r to be installed even though it's not used) Thanks for the thoughtful response, -- Chad From luislavena at gmail.com Sat Nov 10 14:26:36 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 10 Nov 2007 16:26:36 -0300 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <4b6f054f0711100305w57a28a8evd20be6814905d918@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> <71166b3b0711092012i37eaf40et759abacd19b4c5ea@mail.gmail.com> <4b6f054f0711100305w57a28a8evd20be6814905d918@mail.gmail.com> Message-ID: <71166b3b0711101126p7414c1a6h8f8b37de78c21bf6@mail.gmail.com> On Nov 10, 2007 8:05 AM, Trans wrote: > On Nov 9, 2007 11:12 PM, Luis Lavena wrote: > > > > I guess that will work... but must validate my idea later (with a > > windows machine handy) :) > > If you read my prior poists, you would know that's exactly what I did > with the current TMail gem. And in no uncertain terms it is a complete > *hack*. Nor is it a perfect solution. If nmake or make is not present > it still bombs. > I was lazy enough to look the previous post of this thread, sorry :-) > I would like to know the RubyGems official policy on supporting a > pure-ruby version of a library that can also have platform extensions. > As far as I can tell, there is no clear policy for this. I see this somehow different: is marked ::RUBY platform, and don't bundle the native extension (because it can run without it). _native or _c or _extension is just the extension compiled for the platform, or marked ::RUBY to fire the compile process. in you try rescue the presence of 'gemname_native', and also add that in the summary of the gem: "add gemname_native to get a boost of performance in your platform -- remember that you need a compiler in case no pre-built gem is available". Making this clear to the end-user will reduce the questions about it. Still, there are gems that cannot revert to pure-ruby solution for the missing extension, and is good they fail if no compiler is available. Trans, these are my POV of the situation, and I'm not trying to convince you is the right way of doing it :-) 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 Nov 10 15:27:11 2007 From: transfire at gmail.com (Trans) Date: Sat, 10 Nov 2007 15:27:11 -0500 Subject: [Rubygems-developers] extensions fall back option In-Reply-To: <71166b3b0711101126p7414c1a6h8f8b37de78c21bf6@mail.gmail.com> References: <4b6f054f0711070845p1009e86dtf9e03272b12ee0af@mail.gmail.com> <326AED84-8E4B-4273-B84A-CE5F9E9D43F3@segment7.net> <4b6f054f0711091614k209e6dd7l101ce747939d3e7d@mail.gmail.com> <71166b3b0711092012i37eaf40et759abacd19b4c5ea@mail.gmail.com> <4b6f054f0711100305w57a28a8evd20be6814905d918@mail.gmail.com> <71166b3b0711101126p7414c1a6h8f8b37de78c21bf6@mail.gmail.com> Message-ID: <4b6f054f0711101227g34b0b763rac8809ce15bcf5b9@mail.gmail.com> On Nov 10, 2007 2:26 PM, Luis Lavena wrote: > On Nov 10, 2007 8:05 AM, Trans wrote: > > On Nov 9, 2007 11:12 PM, Luis Lavena wrote: > > > > > > I guess that will work... but must validate my idea later (with a > > > windows machine handy) :) > > > > If you read my prior poists, you would know that's exactly what I did > > with the current TMail gem. And in no uncertain terms it is a complete > > *hack*. Nor is it a perfect solution. If nmake or make is not present > > it still bombs. > > > > I was lazy enough to look the previous post of this thread, sorry :-) I cam across a bit hard. I just wanted to let you know that I put a solution out for that a few posts back. But it was in separate thread: pure-ruby vs. compile-on-intsall > > I would like to know the RubyGems official policy on supporting a > > pure-ruby version of a library that can also have platform extensions. > > As far as I can tell, there is no clear policy for this. > > I see this somehow different: > > is marked ::RUBY platform, and don't bundle the native > extension (because it can run without it). > > _native or _c or _extension is just the extension compiled > for the platform, or marked ::RUBY to fire the compile process. > > in you try rescue the presence of 'gemname_native', and also > add that in the summary of the gem: > > "add gemname_native to get a boost of performance in your platform -- > remember that you need a compiler in case no pre-built gem is > available". > > Making this clear to the end-user will reduce the questions about it. > Still, there are gems that cannot revert to pure-ruby solution for the > missing extension, and is good they fail if no compiler is available. > > Trans, these are my POV of the situation, and I'm not trying to > convince you is the right way of doing it :-) I considered this approach. I thought: tmail-1.1.1.gem tmail_fast-1.1.1.gem But when someone depends on this library which do they choose? Do they choose the slow which they know will work, or the fast one which may not work? Clearly for the end-user I want them to have the fast one IF the compile works, and the slow otherwise. So maybe better: tmail-1.1.1.gem tmail_ruby-1.1.1.gem So then depend on tmail, and I could hack in a warning that compilation failed, and they can install tmail_ruby instead if they want. That's pretty good. But one of my jobs as a programmer is to make my end-users life as easy as possible, so why not have it complete installation without the extension if I set that option in the gemspec telling it that it is okay to do so, and just tell the end user it installed but without native extension. Think also of it this way. tmail-1.1.1.gem is going to contain almost the exact same files as tmail_ruby-1.1.1.gem, minus perhaps the ext/ source code. So why clutter up Rubyforge with two copies of every release when one would do? PLUS, what if someone installed both tmail and tmail_ruby? Probably it will be okay, but it might be dishing out files from two separate locations, so it might not. And finally what about gem tmail vs. gem tmail_ruby Might this not force my users to propagate this issue down the chain? So if I do it this way, does Nitro also have to do so too b/c it depends on tmail? nitro-0.50.gem nitro_ruby-0.50.gem I know that's not going to happen! If tmail's install blows so does nitro's install. Really that's simply not acceptable. There needs to be a single gem that just works --after all that was the problem with platform gems and that's why gem now automatically selects the right one. T. From drbrain at segment7.net Sat Nov 10 15:55:36 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 10 Nov 2007 12:55:36 -0800 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> Message-ID: <4D232BD3-1DC7-4A3D-9E3E-2EB4651565F1@segment7.net> On Nov 10, 2007, at 11:26 , Chad Woolley wrote: > On 11/9/07, Eric Hodel wrote: >> On Nov 9, 2007, at 16:08 , Chad Woolley wrote: >>> I don't want to force everyone who uses it >>> to install the dozen-plus build- and deploy- and test-time >>> dependencies I have. This >>> would freak some people out when they installed it and make them not >>> want to use the gem. >> >> I've installed things that easily have more dependencies than that. >> I think lots of dependencies with a small gem is a good thing, since >> it means the author is probably being a good citizen. > > Hmm. Interesting, and still a matter of opinion :) This is for C programs and libraries, primarily. > Why does that make you a good citizen? Because you are reusing code? > Or because you are being explicit about your dependencies? Code reuse. > In my experience, I've found that LESS actual dependencies is a good > thing, because that's less opportunity for me to get in dependency > hell (incompatibilities that I don't understand or can't resolve). > For example, I started using needle on my project, but then rolled my > own DI so I wouldn't have that dependency, and it was simpler and > better-tested. Granted, this is probably a somewhat-unnecessary > holdover from my Java days, because it's much easier to deal with this > in ruby by monkey-patching. I think the majority of the problem is that Ruby's libraries haven't matured enough yet. I'll use an external library until it becomes too complicated to maintain, then I'll fix it, and if I can't, I'll replace it. Without mature libraries, we all end up at step three too often. Sometimes often enough that we skip right to step three. >>> Plus, it's very likely (especially in the case >>> of Rspec) that one of my dependency versions conflicts with >>> something >>> else on their system, and unless they have their rspec version >>> locked >>> down everywhere (unlikely) the mere installation of my gem will >>> screw >>> them if it auto-installs a newer version of rspec that's >>> incompatible >>> with their old specs. >> >> I believe that RubyGems has the ability to handle this gracefully >> with sane versioning schemes combined with the existing requirement >> specifiers (including '~>'), and that this is primarily a gem author >> education problem. When severity of changes doesn't match changes in >> version numbers, everybody is going to suffer. > > Sorry, I've gotta disagree here (and I'm_definitely not bikeshedding > here, because my and my shop, which includes an rspec committer, are > early rspec adopters, and we have been along for the whole ride). > Even if rspec had sane versiong schemes (which they really don't), it > wouldn't solve the problem I mentioned: > > 1. I force a newer version of rspec to be installed > 2. User installs my gem > 3. The newer version of rspec breaks all my user's tests > 4. User gets pissed because my gem "broke" them. Yes, it's their > fault for not locking down their rspec version, but the user is always > right! Plus, they have a somewhat valid reason to be pissed, because > the newer version of rspec is completely unnecessary for my gem to > work correctly for them. Customers are always right, but I doubt these users paid you. IMO, tough for them (for 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 Sat Nov 10 16:00:25 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 10 Nov 2007 13:00:25 -0800 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <71166b3b0711092009h3b78831k8bf4051a5fd4cfe9@mail.gmail.com> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <71166b3b0711092009h3b78831k8bf4051a5fd4cfe9@mail.gmail.com> Message-ID: <32400412-9748-42DC-8B33-1BCB64DF2A4E@segment7.net> On Nov 9, 2007, at 20:09 , Luis Lavena wrote: > On Nov 9, 2007 7:47 PM, Eric Hodel wrote: >> Including everything is the best approach. >> >> My conclusion is that people only want to bikeshed[1] about this >> topic. They don't want to define an actual solution. When this >> issue first came up (with hoe) people complained loudly, and I told >> them that the best way to handle this would be "developer >> dependencies". It took eight months for the feature request to show >> up on the tracker[2]. Two and a half months later, the requester >> hasn't defined how they think developer dependencies are supposed to >> work. > > Thanks for the bikeshed reference, I wasn't aware of the right term in > english. :-) > > Please excuse the noise, I missed the discussion about this (maybe I > joined the party too late) :-P No, there hasn't been any discussion at all. >> Things that need to be discussed are: >> * should developer dependencies by installed by default? >> * what does the command-line option look like? >> * what happens on uninstall? >> * what should `gem check` do if all dependencies aren't installed? > > I'm seeing this like apt-get build-dep command (and lot of users will > argue this is not the best way) -- still, fits best: > > if you intent to build ruby1.8, you need to download the packages that > are marked as dependencies for compilation/build: > > sudo apt-get build-dep ruby1.8 > > Now, you can grab the source code for ruby1.8 and start the compile > process (if you have the compiler installed, of course) > > I see the compile process as the 'rake compile test package' tasks > sequence. > > Uninstalling of the gem isn't related here, mostly since you're trying > to build from source or perform some kind of check for the gem. I think this is right. > 'gem check' should only yell at you that not all the dependencies for > testing/building are installed, and guide you to 'build-dep ' > to correct the issue. I think this is right. > I must honestly say what I don't know what to do with orphaned gems, > mostly since these gems could the useful for others or even the final > user: > > - I manually install rspec for my own, personal use. > - Try to do some work on DataMapper, which need rspec as build-dep > - gem build-dep datamapper > - rake test package (datamapper) and then gem install it. > - Found it good, but just got bored of it (gem uninstall datamapper) > - rspec shouldn't be removed... even if it's a build dependency of > datamapper and there isn't another gem using it. I think this is right. >> Before attempting a patch, I think at least these questions should be >> answered. There are probably more, since getting it to work well >> requires changes and hooks in lots of places. > > What about a proof of concept? maybe using some text field of the > specification to track this... and create the fake build-dep command > that use that information and manage the installation of dependencies? Yes, it would help find problems, but there's also the problem of gems needing to be updated to work with the proof of concept (adding developer dependencies). So it couldn't be reliably tested without input from the community. >> Its really easy to say "gems should have developer dependencies". >> Its a lot of work to make it a reality. > > Is easier say than do... "show me the code" often came after that > line ;-) :) -- 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 thewoolleyman at gmail.com Sat Nov 10 21:13:22 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 10 Nov 2007 19:13:22 -0700 Subject: [Rubygems-developers] What is right and wrong with dependencies definitions? In-Reply-To: <4D232BD3-1DC7-4A3D-9E3E-2EB4651565F1@segment7.net> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> <4D232BD3-1DC7-4A3D-9E3E-2EB4651565F1@segment7.net> Message-ID: On 11/10/07, Eric Hodel wrote: > I think the majority of the problem is that Ruby's libraries haven't > matured enough yet. Totally agreed. We need tinderbox/gump for ruby. What is the status on firebrigade? I notice my gem hasn't built for several versions (and won't build without some help, due to the issues discussed in this thread). I've been meaning to offer to help with tinderbox in my non-existent spare time. I'll get on the list... From drbrain at segment7.net Sun Nov 11 23:51:39 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 11 Nov 2007 20:51:39 -0800 Subject: [Rubygems-developers] Tinderbox (Was: [dependencies]) In-Reply-To: References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> <4D232BD3-1DC7-4A3D-9E3E-2EB4651565F1@segment7.net> Message-ID: <78240373-4E7E-48E9-B542-5E0EA8F0B86A@segment7.net> On Nov 10, 2007, at 18:13 , Chad Woolley wrote: > On 11/10/07, Eric Hodel wrote: >> I think the majority of the problem is that Ruby's libraries haven't >> matured enough yet. > > Totally agreed. We need tinderbox/gump for ruby. What is the status > on firebrigade? I notice my gem hasn't built for several versions > (and won't build without some help, due to the issues discussed in > this thread). > > I've been meaning to offer to help with tinderbox in my non-existent > spare time. I'll get on the list... The number one problem with tinderbox is that it requires investment from the community to run tinderbox clients for firebrigade. I aim to remove this problem by using EC2, but I won't get to that until after RubyGems is released. The rest of the problems involve updating tinderbox for the changes in RubyGems. The internal APIs were not very friendly when I started tinderbox, so it has bitrotted a bit. -- 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 Nov 12 00:15:58 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 11 Nov 2007 21:15:58 -0800 Subject: [Rubygems-developers] RubyGems imported into 1.9 trunk In-Reply-To: <301C3C95-70CD-443E-A556-D973377AEB9E@segment7.net> References: <301C3C95-70CD-443E-A556-D973377AEB9E@segment7.net> Message-ID: <044560B8-4FE6-4F7B-8875-3B3366746D7F@segment7.net> On Nov 9, 2007, at 23:53 , Eric Hodel wrote: > There are a few tests breaking due to rbconfig.rb not matching > what ./miniruby ./runruby.rb provides, and I'm not sure how to work > around that. > > A few other tests are broken due to rake/rbconfig version mismatch > problem. > > RubyGems libraries won't work until gem_prelude.rb is committed. > > Please let me know if you come across any other problems. For the record, I've added two tasks to RubyGems' Rakefile to help maintain the ruby trunk export of RubyGems. `rake diff_ruby` will compare RubyGems' trunk with ruby's trunk, and `rake update_ruby` will rsync over a new copy of RubyGems into the right place. The tasks expect a specific directory layout which can be overridden. See the Rakefile for details. -- 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 Tue Nov 13 16:11:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 13 Nov 2007 13:11:50 -0800 Subject: [Rubygems-developers] New beta tonight Message-ID: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> I'm going to ship the final beta tonight. Barring any serious flaws, it will become RubyGems 0.9.5 next Monday. -- 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 stephen.bannasch at deanbrook.org Tue Nov 13 17:19:55 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 13 Nov 2007 17:19:55 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related Message-ID: Posted here in case this really is gem related and someone's seen it or something like it before. I think the problem may be in: GemPlugin::Manager.instance.load but I'm not sure at all yet. ----------------------------- After I updated to ruby 1.8.6p111 last night and updated some gems and now mongrel doesn't work: MacOS 10.4.10 $ ruby --version ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin8.10.1] $ gem list rails *** LOCAL GEMS *** rails (1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6) Here's a simple test: $ rails test5 create ... $ cd test5 $ script/server => Booting Mongrel (use 'script/server webrick' to force WEBrick) => Rails application starting on http://0.0.0.0:3000 => Call with -d to detach => Ctrl-C to shutdown server ** Starting Mongrel listening at 0.0.0.0:3000 ** Starting Rails with development environment... ** Rails loaded. ** Loading any Rails specific GemPlugins Exiting /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: undefined method `options' for []:Array (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' Here were the gems I upgraded: $ gem outdated Bulk updating Gem source index for: http://gems.rubyforge.org fastercsv (1.2.0 < 1.2.1) ruby-debug (0.8.1 < 0.9.3) mofo (0.2.1 < 0.2.10) mongrel (1.0.1 < 1.1.1) rails (1.2.4 < 1.2.5) actionwebservice (1.2.4 < 1.2.5) ruby-debug-base (0.8.1 < 0.9.3) activerecord (1.15.4 < 1.15.5) tzinfo (0.3.3 < 0.3.5) gem_plugin (0.2.2 < 0.2.3) libxml-ruby (0.3.8.4.1 < 0.5.2.0) ruport (0.8.12 < 1.2.2) image_science (1.1.1 < 1.1.3) erubis (2.2.0 < 2.4.1) uuidtools (1.0.0 < 1.0.2) cgi_multipart_eof_fix (2.1 < 2.5.0) attributes (4.0.0 < 5.0.0) net-ssh (1.0.10 < 1.1.2) mongrel_cluster (1.0.2 < 1.0.4) capistrano (1.4.1 < 2.1.0) merb (0.2.0 < 0.4.1) actionmailer (1.3.4 < 1.3.5) actionpack (1.13.4 < 1.13.5) json (1.0.1 < 1.1.1) daemons (1.0.5 < 1.0.9) RubyInline (3.6.2 < 3.6.5) activesupport (1.4.3 < 1.4.4) builder (2.1.1 < 2.1.2) hpricot (0.5.110 < 0.6) fastthread (1.0 < 1.0.1) -------------------------------------- Some more clues from tracing with ruby-debug (I'm still learning how o use this tool): dev mode, rails 1.2.5, ruby 1.8.6 patchlevel 111, gem v0.9.4 this is on a newly created rails app with no changes to it I set a debugger statement at the end of environment.rb and run script/server. When it fires I set this breakpoint: b /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:114 This is in the middle of the GemPlugin::Manager.instance.load loop where gems are loaded which is called from load_plugins line 231 in in mongrels configurator.rb. (rdb:1) where --> #0 /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:114 in 'load' #1 /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:166 in 'each' #2 /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:112 in 'load' #3 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:231 in 'load_plugins' #4 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:117 in 'cloaker_' (rdb:1) l 112 [107, 116] in /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb 107 def load(needs = {}) 108 sdir = File.join(Gem.dir, "specifications") 109 gems = Gem::SourceIndex.from_installed_gems(sdir) 110 needs = needs.merge({"gem_plugin" => INCLUDE}) 111 112 gems.each do |path, gem| 113 # don't load gems more than once => 114 next if @gems.has_key? gem.name 115 check = needs.dup gems.length => 315 I set an exception capture here for the NoMethodError cat NoMethodError then 34 times through this loop (many 'conts') (rdb:1) cont Exiting /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS Catchpoint at /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: `undefined method `options' for []:Array' (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from script/server:3 /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18 ARGV.clone.options do |opts| [13, 22] in /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb 13 :ip => "0.0.0.0", 14 :environment => (ENV['RAILS_ENV'] || "development").dup, 15 :detach => false 16 } 17 => 18 ARGV.clone.options do |opts| 19 opts.on("-p", "--port=port", Integer, "Runs Rails on the specified port.", "Default: 3000") { |v| OPTIONS[:port] = v } 20 opts.on("-b", "--binding=ip", String, "Binds Rails to the specified ip.", "Default: 0.0.0.0") { |v| OPTIONS[:ip] = v } 21 opts.on("-d", "--daemon", "Make server run as a Daemon.") { OPTIONS[:detach] = true } 22 opts.on("-e", "--environment=name", String, From stephen.bannasch at deanbrook.org Tue Nov 13 17:28:41 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 13 Nov 2007 17:28:41 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: Message-ID: somebody probably wiser than me wrote: >IIRC, if you update ruby, you're supposed to reinstall your gems -- >especially those with C components. (You'll probably want to update >mysql, too.) Something about libraries and linking...? I didn't do that -- and that sounds like a likely cause for strange errors. Hmmm ... is there an easy way to ask all the versions of all my gems to rebuild themselves -- I don't actually need to download them -- they're already on my system. From drbrain at segment7.net Tue Nov 13 21:02:37 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 13 Nov 2007 18:02:37 -0800 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: Message-ID: <5653F746-DDC7-4A20-9F4C-1ADD15A31E96@segment7.net> On Nov 13, 2007, at 14:28 , Stephen Bannasch wrote: > somebody probably wiser than me wrote: >> IIRC, if you update ruby, you're supposed to reinstall your gems -- >> especially those with C components. (You'll probably want to update >> mysql, too.) Something about libraries and linking...? > > I didn't do that -- and that sounds like a likely cause for strange > errors. I've never heard of this before, and I've been using gems for a long time. I've never reinstalled my gems when upgrading ruby. I've used C components from ruby 1.8.2 with 1.8.6. If you do have to recompile, this is a bug in either Ruby or the extension because something changed incompatibly. Probably the extension 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 drbrain at segment7.net Tue Nov 13 21:03:21 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 13 Nov 2007 18:03:21 -0800 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: Message-ID: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> On Nov 13, 2007, at 14:19 , Stephen Bannasch wrote: > Posted here in case this really is gem related and someone's seen it > or something like it before. I think the problem may be in: > > GemPlugin::Manager.instance.load > > but I'm not sure at all yet. > > ----------------------------- > > After I updated to ruby 1.8.6p111 last night and updated some gems > and now > mongrel doesn't work: > > MacOS 10.4.10 > > $ ruby --version > ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-darwin8.10.1] > > $ gem list rails > > *** LOCAL GEMS *** > > rails (1.2.5, 1.2.4, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.6) > > Here's a simple test: > > $ rails test5 > create ... > > $ cd test5 > $ script/server > => Booting Mongrel (use 'script/server webrick' to force WEBrick) > => Rails application starting on http://0.0.0.0:3000 > => Call with -d to detach > => Ctrl-C to shutdown server > ** Starting Mongrel listening at 0.0.0.0:3000 > ** Starting Rails with development environment... > ** Rails loaded. > ** Loading any Rails specific GemPlugins > Exiting > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/ > mongrel.rb:15: > > warning: already initialized constant OPTIONS > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/ > mongrel.rb:18: > > undefined method `options' for []:Array (NoMethodError) > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ > active_support/dependencies.rb:495:in > > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ > active_support/dependencies.rb:342:in > > `new_constants_in' > from > /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/ > active_support/dependencies.rb:495:in > > `require' > from > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/ > server.rb:39 > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `gem_original_require' > from > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in > `require' Nothing in this stack trace points to RubyGems. -- 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 Tue Nov 13 22:05:13 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 14 Nov 2007 00:05:13 -0300 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> Message-ID: <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> On Nov 13, 2007 6:11 PM, Eric Hodel wrote: > I'm going to ship the final beta tonight. Barring any serious flaws, > it will become RubyGems 0.9.5 next Monday. > I'll suggest that Tom perform a reindex of rubyforge gems since there are a few odd-balls still there (that report x86-mswin32). -- 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 Nov 13 22:23:34 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 13 Nov 2007 19:23:34 -0800 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> Message-ID: On Nov 13, 2007, at 19:05 , Luis Lavena wrote: > On Nov 13, 2007 6:11 PM, Eric Hodel wrote: >> I'm going to ship the final beta tonight. Barring any serious flaws, >> it will become RubyGems 0.9.5 next Monday. > > I'll suggest that Tom perform a reindex of rubyforge gems since there > are a few odd-balls still there (that report x86-mswin32). I had him perform one after my last change to the gemspec/indexer code. You may need to `gem sources -c`. If this doesn't fix the problem, which gems are still affected? This will help me track it down. -- 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 stephen.bannasch at deanbrook.org Tue Nov 13 21:15:19 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 13 Nov 2007 21:15:19 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <5653F746-DDC7-4A20-9F4C-1ADD15A31E96@segment7.net> References: <5653F746-DDC7-4A20-9F4C-1ADD15A31E96@segment7.net> Message-ID: >On Nov 13, 2007, at 14:28 , Stephen Bannasch wrote: >> somebody probably wiser than me wrote: >>> IIRC, if you update ruby, you're supposed to reinstall your gems -- >>> especially those with C components. (You'll probably want to update >>> mysql, too.) Something about libraries and linking...? >> >> I didn't do that -- and that sounds like a likely cause for strange >> errors. > >I've never heard of this before, and I've been using gems for a long >time. I've never reinstalled my gems when upgrading ruby. I've used >C components from ruby 1.8.2 with 1.8.6. Well -- your experience certainly lowers the probability of that being the cause. I'll get back to learning more about ruby-debug and tracing out the issue. From stephen.bannasch at deanbrook.org Wed Nov 14 00:46:35 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 14 Nov 2007 00:46:35 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> Message-ID: At 6:03 PM -0800 11/13/07, Eric Hodel wrote: > >Nothing in this stack trace points to RubyGems. The crash appears to be happening in GemPlugin::Manager.instance.load (but of course things are not always as they appear). Here's where I am now: I have a breakpoint on lines 231 and 232 (I added line 232) in a mongrel script . I never get to line 232. The problem seems to occur in GemPlugin::Manager.instance.load. I don't think it's an obvious bug in the Gem code. I expect there is some gem that is screwed up in some way that the causes GemPlugin::Manager.instance.load to blow up. [226, 235] in /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb 226 ops[:excludes].each do |plugin| 227 load_settings[plugin] = GemPlugin::EXCLUDE 228 end 229 end 230 => 231 GemPlugin::Manager.instance.load(load_settings) 232 puts "after looading plugins ..." 233 end 234 235 here the stack: (rdb:1) where --> #0 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:231 in 'load_plugins' #1 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:117 in 'cloaker_' #2 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:149 in 'call' #3 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:99 in 'cloaker_' #4 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:50 in 'call' #5 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:84 in 'new' #6 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:84 in 'run' #7 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/command.rb:212 in 'run' #8 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:281 #9 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:488 in 'load' #10 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:488 in 'load' #11 /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:60 #12 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 in 'require' #13 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495 in 'require' #14 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495 in 'require' #15 /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 #16 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 in 'require' #17 ./script/server.rb:3 and here's the stacktrace from the error: (rdb:1) cont Exiting /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: undefined method `options' for []:Array (NoMethodError) from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in' from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from ./script/server.rb:3 from /usr/local/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/bin/rdebug:136:in `debug_load' from /usr/local/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/bin/rdebug:136 from /usr/local/bin/rdebug:16:in `load' from /usr/local/bin/rdebug:16 --------------------------------------- Here's what I found tracing GemPlugin::Manager.instance.load: I setup this conditional break at line 115 (gems.length == 315): b /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 if gem.name == "daemons" /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 check = needs.dup [110, 119] in /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb 110 needs = needs.merge({"gem_plugin" => INCLUDE}) 111 112 gems.each do |path, gem| 113 # don't load gems more than once 114 next if @gems.has_key? gem.name => 115 check = needs.dup 116 117 # rolls through the depends and inverts anything it finds 118 gem.dependencies.each do |dep| 119 # this will fail if a gem is depended more than once On the 10th pass through the conditional break at 115. I get the next two startup messages displayed: (rdb:1) cont ** Rails loaded. ** Loading any Rails specific GemPlugins Breakpoint 1 at /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 But after four more times through the conditional break at 115 I get back to the error described above: I still need to do more work to complete tracing the path to the error. From drbrain at segment7.net Wed Nov 14 01:02:16 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 13 Nov 2007 22:02:16 -0800 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> Message-ID: <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> On Nov 13, 2007, at 21:46 , Stephen Bannasch wrote: > At 6:03 PM -0800 11/13/07, Eric Hodel wrote: >> >> Nothing in this stack trace points to RubyGems. > > The crash appears to be happening in > GemPlugin::Manager.instance.load (but of course things are not > always as they appear). GemPlugin is not part of RubyGems. I think its part of mongrel. -- 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 kevin.clark at gmail.com Wed Nov 14 01:03:12 2007 From: kevin.clark at gmail.com (Kevin Clark) Date: Tue, 13 Nov 2007 22:03:12 -0800 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> Message-ID: This error is caused by a bad require in environment.rb: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/e1cb5d99ff0313c5 On Nov 13, 2007 9:46 PM, Stephen Bannasch wrote: > At 6:03 PM -0800 11/13/07, Eric Hodel wrote: > > > >Nothing in this stack trace points to RubyGems. > > The crash appears to be happening in GemPlugin::Manager.instance.load (but of course things are not always as they appear). > > Here's where I am now: > > I have a breakpoint on lines 231 and 232 (I added line 232) in a mongrel script . I never get to line 232. The problem seems to occur in GemPlugin::Manager.instance.load. I don't think it's an obvious bug in the Gem code. I expect there is some gem that is screwed up in some way that the causes GemPlugin::Manager.instance.load to blow up. > > [226, 235] in /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb > 226 ops[:excludes].each do |plugin| > 227 load_settings[plugin] = GemPlugin::EXCLUDE > 228 end > 229 end > 230 > => 231 GemPlugin::Manager.instance.load(load_settings) > 232 puts "after looading plugins ..." > 233 end > 234 > 235 > > here the stack: > > (rdb:1) where > --> #0 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:231 in 'load_plugins' > #1 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:117 in 'cloaker_' > #2 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:149 in 'call' > #3 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:99 in 'cloaker_' > #4 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/configurator.rb:50 in 'call' > #5 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:84 in 'new' > #6 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:84 in 'run' > #7 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/lib/mongrel/command.rb:212 in 'run' > #8 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.1/bin/mongrel_rails:281 > #9 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:488 in 'load' > #10 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:488 in 'load' > #11 /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:60 > #12 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 in 'require' > #13 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495 in 'require' > #14 /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495 in 'require' > #15 /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 > #16 /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27 in 'require' > #17 ./script/server.rb:3 > > and here's the stacktrace from the error: > > (rdb:1) cont > Exiting > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS > /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/servers/mongrel.rb:18: undefined method `options' for []:Array (NoMethodError) > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `gem_original_require' > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in `require' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:342:in `new_constants_in' > from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/dependencies.rb:495:in `require' > from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.5/lib/commands/server.rb:39 > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' > from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' > from ./script/server.rb:3 > from /usr/local/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/bin/rdebug:136:in `debug_load' > from /usr/local/lib/ruby/gems/1.8/gems/ruby-debug-0.9.3/bin/rdebug:136 > from /usr/local/bin/rdebug:16:in `load' > from /usr/local/bin/rdebug:16 > > --------------------------------------- > > Here's what I found tracing GemPlugin::Manager.instance.load: > > I setup this conditional break at line 115 (gems.length == 315): > > b /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 if gem.name == "daemons" > > /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 check = needs.dup > [110, 119] in /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb > 110 needs = needs.merge({"gem_plugin" => INCLUDE}) > 111 > 112 gems.each do |path, gem| > 113 # don't load gems more than once > 114 next if @gems.has_key? gem.name > => 115 check = needs.dup > 116 > 117 # rolls through the depends and inverts anything it finds > 118 gem.dependencies.each do |dep| > 119 # this will fail if a gem is depended more than once > > On the 10th pass through the conditional break at 115. I get the next two startup messages displayed: > > (rdb:1) cont > ** Rails loaded. > ** Loading any Rails specific GemPlugins > Breakpoint 1 at /usr/local/lib/ruby/gems/1.8/gems/gem_plugin-0.2.3/lib/gem_plugin.rb:115 > > But after four more times through the conditional break at 115 I get back to the error described above: > > I still need to do more work to complete tracing the path to the error. > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Kevin Clark http://glu.ttono.us From jeremy at hinegardner.org Wed Nov 14 01:32:00 2007 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Tue, 13 Nov 2007 23:32:00 -0700 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> Message-ID: <20071114063200.GB16046@hinegardner.org> On Tue, Nov 13, 2007 at 10:02:16PM -0800, Eric Hodel wrote: > On Nov 13, 2007, at 21:46 , Stephen Bannasch wrote: > > At 6:03 PM -0800 11/13/07, Eric Hodel wrote: > >> > >> Nothing in this stack trace points to RubyGems. > > > > The crash appears to be happening in > > GemPlugin::Manager.instance.load (but of course things are not > > always as they appear). > > GemPlugin is not part of RubyGems. I think its part of mongrel. I would be you have a gem installed that depends on GemPlugin but doesn't have an init.rb or fails to initialize itself correctly. Try this and see what happens: require 'rubygems' require 'mongrel' g = GemPlugin::Manager.instance g.load( {'mongrel' => GemPlugin::INCLUDE }) puts g.gems.inspect If that blows up then its probably some gem that depends on mongrel not initalizing correctly. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From tom at infoether.com Wed Nov 14 09:48:29 2007 From: tom at infoether.com (Tom Copeland) Date: Wed, 14 Nov 2007 09:48:29 -0500 Subject: [Rubygems-developers] New beta tonight In-Reply-To: References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> Message-ID: <1195051709.26046.16.camel@bugs.hal> On Tue, 2007-11-13 at 19:23 -0800, Eric Hodel wrote: > On Nov 13, 2007, at 19:05 , Luis Lavena wrote: > > On Nov 13, 2007 6:11 PM, Eric Hodel wrote: > >> I'm going to ship the final beta tonight. Barring any serious flaws, > >> it will become RubyGems 0.9.5 next Monday. > > > > I'll suggest that Tom perform a reindex of rubyforge gems since there > > are a few odd-balls still there (that report x86-mswin32). > > I had him perform one after my last change to the gemspec/indexer > code. You may need to `gem sources -c`. If this doesn't fix the > problem, which gems are still affected? This will help me track it > down. FWIW, Alex Fenton is reporting that 0.9.2 is having trouble reading all the gems in the index: http://rubyforge.org/tracker/index.php?func=detail&aid=15417&group_id=5&atid=102 Works fine for me with 0.9.0. Yours, Tom From luislavena at gmail.com Wed Nov 14 09:59:48 2007 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 14 Nov 2007 11:59:48 -0300 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <1195051709.26046.16.camel@bugs.hal> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> Message-ID: <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> On Nov 14, 2007 11:48 AM, Tom Copeland wrote: > > FWIW, Alex Fenton is reporting that 0.9.2 is having trouble reading all > the gems in the index: > > http://rubyforge.org/tracker/index.php?func=detail&aid=15417&group_id=5&atid=102 I just added some comment about that after digging the wxRuby gem issues, pasting the comment here: The other thing is that wxRuby is being marked as 'x86-mswin32' platform gem, when the file is 'i386-mswin32' Doing deep in the problem, I see this from the metadata: rubygems_version: 0.9.4 platform: i386-mswin32 Compared to mongrel-1.1.1-mswin32.gem: rubygems_version: 0.9.4 platform: mswin32 Err... anyone noticing the difference? who wxRuby team is coding the platform? there wasn't a 'i386-mswin32' Gem::Platform constant for that in 0.9.4... They are using Gem::Platform::WIN32 for mswin platform: rake/rakepackage.rb:80 self.platform = gem_platform Err... me confused... don't know why was that... Or wxRuby team was using the beta of rubygems to create the gem (since Gem::PLATFORM::WIN32 on beta will generate the new platform syntax) or they managed to brake RubyGems ;-) I used the same constant for Mongrel and the platform is correct. -- 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 Nov 14 16:53:25 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 14 Nov 2007 13:53:25 -0800 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <20071114063200.GB16046@hinegardner.org> References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> <20071114063200.GB16046@hinegardner.org> Message-ID: <162D11DC-BD53-4946-A8B3-808441B9081B@segment7.net> On Nov 13, 2007, at 22:32 , Jeremy Hinegardner wrote: > On Tue, Nov 13, 2007 at 10:02:16PM -0800, Eric Hodel wrote: >> On Nov 13, 2007, at 21:46 , Stephen Bannasch wrote: >>> At 6:03 PM -0800 11/13/07, Eric Hodel wrote: >>>> >>>> Nothing in this stack trace points to RubyGems. >>> >>> The crash appears to be happening in >>> GemPlugin::Manager.instance.load (but of course things are not >>> always as they appear). >> >> GemPlugin is not part of RubyGems. I think its part of mongrel. > > I would be you have a gem installed that depends on GemPlugin but > doesn't have an init.rb or fails to initialize itself correctly. Try > this and see what happens: > > require 'rubygems' > require 'mongrel' > g = GemPlugin::Manager.instance > g.load( {'mongrel' => GemPlugin::INCLUDE }) > puts g.gems.inspect > > If that blows up then its probably some gem that depends on mongrel > not > initalizing correctly. If it isn't failing with a stack trace that points to RubyGems then you'll need to go ask the GemPlugin author for support. I haven't seen such a stack trace yet. -- 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 stephen.bannasch at deanbrook.org Thu Nov 15 02:43:09 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 15 Nov 2007 02:43:09 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <162D11DC-BD53-4946-A8B3-808441B9081B@segment7.net> References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> <20071114063200.GB16046@hinegardner.org> <162D11DC-BD53-4946-A8B3-808441B9081B@segment7.net> Message-ID: At 1:53 PM -0800 11/14/07, Eric Hodel wrote: >On Nov 13, 2007, at 22:32 , Jeremy Hinegardner wrote: >> On Tue, Nov 13, 2007 at 10:02:16PM -0800, Eric Hodel wrote: >>> On Nov 13, 2007, at 21:46 , Stephen Bannasch wrote: >>>> At 6:03 PM -0800 11/13/07, Eric Hodel wrote: >>>>> >>>>> Nothing in this stack trace points to RubyGems. >>>> >>>> The crash appears to be happening in >>>> GemPlugin::Manager.instance.load (but of course things are not > >>> always as they appear). >>> >>> GemPlugin is not part of RubyGems. I think its part of mongrel. >> >> I would be you have a gem installed that depends on GemPlugin but >> doesn't have an init.rb or fails to initialize itself correctly. Try >> this and see what happens: >> >> require 'rubygems' >> require 'mongrel' >> g = GemPlugin::Manager.instance >> g.load( {'mongrel' => GemPlugin::INCLUDE }) >> puts g.gems.inspect >> >> If that blows up then its probably some gem that depends on mongrel >> not >> initalizing correctly. > >If it isn't failing with a stack trace that points to RubyGems then >you'll need to go ask the GemPlugin author for support. I haven't >seen such a stack trace yet. Eric and Jeremy, Thanks for all your responses -- they definitely helped me spend less time in dead-end investigations. I was confused (and tired) when I was tracing through the gem_plugin code and confused it with gem proper. GemPlugin was written by the author of mongrel Zed Shaw. I think it is possible that some gems have gotten corrupted however. I was able to get rails and mongrel to start up properly by uninstalling ruport v0.8.12 -- that gem should have nothing to do with rails or mongrel?? Anyways if you are interested here's a link to a longer report I made on the debugging I did in Mongrel and gem_plugin on the mongrel-users email list: http://rubyforge.org/pipermail/mongrel-users/2007-November/004499.html >From Zed's description of gem_plugin: # Implements a dynamic plugin loading, configuration, and discovery system # based on RubyGems and a simple additional name space that looks like a URI. http://mongrel.rubyforge.org/svn/trunk/projects/gem_plugin/lib/gem_plugin.rb In further testing I discovered: After uninstalling ruport 0.8.11, 0.8.12, and 1.2.2 starting rails and mongrel worked. After re-installing ruport 1.2.2 starting rails and mongrel worked. After re-installing ruport 0.8.12 starting rails and mongrel DID NOT work. After uninstalling ruport 1.2.2 starting rails and mongrel DID NOT work. After uninstalling ruport 0.8.12 starting rails and mongrel worked. Here's a link to that actual testing: http://pastie.caboo.se/118251 The error messages were not helpful in tracking this problem down. From darix at web.de Thu Nov 15 07:36:40 2007 From: darix at web.de (Marcus Rueckert) Date: Thu, 15 Nov 2007 13:36:40 +0100 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> <20071114063200.GB16046@hinegardner.org> <162D11DC-BD53-4946-A8B3-808441B9081B@segment7.net> Message-ID: <20071115123640.GV4383@pixel.global-banlist.de> wouldnt be the first gem which breaks mongrel/gemplugin. i saw another user in #mongrel with the same problem. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From drbrain at segment7.net Thu Nov 15 16:43:12 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 15 Nov 2007 13:43:12 -0800 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> Message-ID: On Nov 14, 2007, at 06:59 , Luis Lavena wrote: > On Nov 14, 2007 11:48 AM, Tom Copeland wrote: >> FWIW, Alex Fenton is reporting that 0.9.2 is having trouble >> reading all >> the gems in the index: >> >> http://rubyforge.org/tracker/index.php? >> func=detail&aid=15417&group_id=5&atid=102 > > I just added some comment about that after digging the wxRuby gem > issues, pasting the comment here: > > > The other thing is that wxRuby is being marked as 'x86-mswin32' > platform gem, when the file is 'i386-mswin32' > > Doing deep in the problem, I see this from the metadata: > > rubygems_version: 0.9.4 > platform: i386-mswin32 > > Compared to mongrel-1.1.1-mswin32.gem: > rubygems_version: 0.9.4 > platform: mswin32 > > > Err... anyone noticing the difference? who wxRuby team is coding > the platform? there wasn't a 'i386-mswin32' Gem::Platform constant > for that in 0.9.4... > > They are using Gem::Platform::WIN32 for mswin platform: > rake/rakepackage.rb:80 > > self.platform = gem_platform > > > Err... me confused... don't know why was that... > > > Or wxRuby team was using the beta of rubygems to create the gem (since > Gem::PLATFORM::WIN32 on beta will generate the new platform syntax) or > they managed to brake RubyGems ;-) > > I used the same constant for Mongrel and the platform is correct. They probably specified it by hand. There's all kinds of bizarre platforms in existence that don't match the constants. The indexer should support all these legacy strings, 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 Thu Nov 15 19:05:47 2007 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 15 Nov 2007 21:05:47 -0300 Subject: [Rubygems-developers] New beta tonight In-Reply-To: References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> Message-ID: <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> On Nov 15, 2007 6:43 PM, Eric Hodel wrote: > > They probably specified it by hand. There's all kinds of bizarre > platforms in existence that don't match the constants. The indexer > should support all these legacy strings, though. > The use Gem::Platform::CURRENT which took RUBY_PLATFORM as spec.platform :-P The new indexer is processing i386-mswin32 with the new GNU-triplet instead of the old ::WIN32 'mswin32' platform. Chicken-egg situation :-P (New indexer interpreting old gems -- 0.9.4 rubygems_version as > 0.9.4). -- 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 Nov 16 03:40:09 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 16 Nov 2007 00:40:09 -0800 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> Message-ID: <0B07E9D2-C99F-488D-87C6-901D73CEA2F1@segment7.net> On Nov 15, 2007, at 16:05 , Luis Lavena wrote: > On Nov 15, 2007 6:43 PM, Eric Hodel wrote: >> They probably specified it by hand. There's all kinds of bizarre >> platforms in existence that don't match the constants. The indexer >> should support all these legacy strings, though. > > The use Gem::Platform::CURRENT which took RUBY_PLATFORM as > spec.platform :-P > > The new indexer is processing i386-mswin32 with the new GNU-triplet > instead of the old ::WIN32 'mswin32' platform. > > Chicken-egg situation :-P > (New indexer interpreting old gems -- 0.9.4 rubygems_version as > > 0.9.4). I forced the indexer to always use @original_platform when doing its thing, so it won't be interpreted. This should be 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 drbrain at segment7.net Fri Nov 16 04:05:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 16 Nov 2007 01:05:05 -0800 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> Message-ID: <36676091-485F-41AE-9E07-2556327C640A@segment7.net> On Nov 15, 2007, at 16:05 , Luis Lavena wrote: > On Nov 15, 2007 6:43 PM, Eric Hodel wrote: >> They probably specified it by hand. There's all kinds of bizarre >> platforms in existence that don't match the constants. The indexer >> should support all these legacy strings, though. > > The use Gem::Platform::CURRENT which took RUBY_PLATFORM as > spec.platform :-P > > The new indexer is processing i386-mswin32 with the new GNU-triplet > instead of the old ::WIN32 'mswin32' platform. > > Chicken-egg situation :-P > (New indexer interpreting old gems -- 0.9.4 rubygems_version as > > 0.9.4). Oh, I see what's different. I'll poke again at this tomorrow. I thought for sure I had 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 tom at infoether.com Fri Nov 16 09:08:50 2007 From: tom at infoether.com (Tom Copeland) Date: Fri, 16 Nov 2007 09:08:50 -0500 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <0B07E9D2-C99F-488D-87C6-901D73CEA2F1@segment7.net> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> <0B07E9D2-C99F-488D-87C6-901D73CEA2F1@segment7.net> Message-ID: <1195222130.11742.2.camel@bugs.hal> On Fri, 2007-11-16 at 00:40 -0800, Eric Hodel wrote: > On Nov 15, 2007, at 16:05 , Luis Lavena wrote: > > On Nov 15, 2007 6:43 PM, Eric Hodel wrote: > >> They probably specified it by hand. There's all kinds of bizarre > >> platforms in existence that don't match the constants. The indexer > >> should support all these legacy strings, though. > > > > The use Gem::Platform::CURRENT which took RUBY_PLATFORM as > > spec.platform :-P > > > > The new indexer is processing i386-mswin32 with the new GNU-triplet > > instead of the old ::WIN32 'mswin32' platform. > > > > Chicken-egg situation :-P > > (New indexer interpreting old gems -- 0.9.4 rubygems_version as > > > 0.9.4). > > I forced the indexer to always use @original_platform when doing its > thing, so it won't be interpreted. This should be fixed. Hm, we're getting reports of platform gem problems, e.g.: http://rubyforge.org/tracker/?func=detail&atid=101&aid=15665&group_id=5 Eric, should I update to the latest RubyGems trunk? I'm using rev 1497 at the moment... Thanks, Tom From stephen.bannasch at deanbrook.org Fri Nov 16 10:21:34 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Fri, 16 Nov 2007 10:21:34 -0500 Subject: [Rubygems-developers] getting an error using mongrel that might be gem related In-Reply-To: <20071115123640.GV4383@pixel.global-banlist.de> References: <6D1ECFEE-9858-4DAF-A52B-3AAFB27E7266@segment7.net> <99B4334B-4F83-49BE-8D83-B82541481101@segment7.net> <20071114063200.GB16046@hinegardner.org> <162D11DC-BD53-4946-A8B3-808441B9081B@segment7.net> <20071115123640.GV4383@pixel.global-banlist.de> Message-ID: At 1:36 PM +0100 11/15/07, Marcus Rueckert wrote: >wouldnt be the first gem which breaks mongrel/gemplugin. >i saw another user in #mongrel with the same problem. To follow up and close this thread on rubygems-dev here are some responses from developers on other lists: Greg Brown is the lead developer on Ruport: At 8:02 AM -0500 11/15/07, Gregory Brown wrote on the list ruport: >Okay, after digging through all of this it sounds like Rails / >GemPlugin are trying to autoload the ruport gem itself even though it >isn't a plugin (has no init.rb). This to me sounds like Rails is >abusing gem_plugin, because Ruport does not depend on rails and thus >should not be loaded. > >That having been said, Ruport 1.0 on up don't explicitly depend on >gem_plugin, so it won't be detected by Rails, and thus won't break. (I >think). > >If you have versions 0.8.10 -> 0.8.14 laying around and are >experiencing this problem, try deleting them. > >Also, thanks for pointing this problem out, I've seen it before but >only in weird cases, and was wondering what happened. Evan Weaver has the most commits to the mongrel set of projects: At 4:10 PM -0500 11/15/07, Evan Weaver wrote on the list mongrel-users: >No aspersions cast on Zed but I hate gem_plugin, and the team is >planning to remove it in a couple months. We just need a temporary >hack for now so that Ruport isn't busted. From drbrain at segment7.net Fri Nov 16 16:52:19 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 16 Nov 2007 13:52:19 -0800 Subject: [Rubygems-developers] New beta tonight In-Reply-To: <1195222130.11742.2.camel@bugs.hal> References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> <0B07E9D2-C99F-488D-87C6-901D73CEA2F1@segment7.net> <1195222130.11742.2.camel@bugs.hal> Message-ID: On Nov 16, 2007, at 06:08 , Tom Copeland wrote: > On Fri, 2007-11-16 at 00:40 -0800, Eric Hodel wrote: >> I forced the indexer to always use @original_platform when doing its >> thing, so it won't be interpreted. This should be fixed. > > Hm, we're getting reports of platform gem problems, e.g.: > > http://rubyforge.org/tracker/? > func=detail&atid=101&aid=15665&group_id=5 > > Eric, should I update to the latest RubyGems trunk? I'm using rev > 1497 > at the moment... I only half fixed things. I'll ping you on IM when I've got it fixed proper. -- 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 Fri Nov 16 16:54:08 2007 From: tom at infoether.com (Tom Copeland) Date: Fri, 16 Nov 2007 16:54:08 -0500 Subject: [Rubygems-developers] New beta tonight In-Reply-To: References: <66CB7BE4-3F9E-4AB7-9AEB-68C6EC87B893@segment7.net> <71166b3b0711131905t3d2ff99fxb00210b3923d1b6d@mail.gmail.com> <1195051709.26046.16.camel@bugs.hal> <71166b3b0711140659y32ef2024gd5289a628f87a191@mail.gmail.com> <71166b3b0711151605o52b361e5ja577f8dc955dcd73@mail.gmail.com> <0B07E9D2-C99F-488D-87C6-901D73CEA2F1@segment7.net> <1195222130.11742.2.camel@bugs.hal> Message-ID: <009701c8289b$3712f3d0$a538db70$@com> > I only half fixed things. I'll ping you on IM when I've got it fixed > proper. Cool, ok, thanks! Tom From stephen.bannasch at deanbrook.org Sun Nov 18 02:07:50 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 18 Nov 2007 02:07:50 -0500 Subject: [Rubygems-developers] what version rubygems for ruby 1.9? Message-ID: I'm testing things in trunk ruby 1.9 and trunk rubygems is working so far. When I tried to instead install rubgems-0.9.4 I got an error running setup.rb. Is this expected -- should I only use the newer releases with 1.9? fyi: here's the error produced: [~/dev/ruby/src/rubygems-0.9.4]$ which ruby /Users/stephen/dev/ruby/1.9_trunk/bin/ruby [~/dev/ruby/src/rubygems-0.9.4]$ ruby setup.rb ... install sha1.rb /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/digest install sha2.rb /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/digest <--- lib/rubygems/digest <--- lib/rubygems <--- lib /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:27:in `gem_original_require': /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:63: syntax error, unexpected ',', expecting tASSOC (SyntaxError) ...ormat.file_entries << [{"size", entry.size, "mode", entry.mo... ... ^ /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:63: syntax error, unexpected ',', expecting tCOLON2 or '[' or '.' ...< [{"size", entry.size, "mode", entry.mode, ... ^ /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:64: syntax error, unexpected ',', expecting tCOLON2 or '[' or '.' "path", entry.full_name}, entry.read] ^ /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:64: syntax error, unexpected '}', expecting keyword_end "path", entry.full_name}, entry.read] ^ /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:64: syntax error, unexpected ']', expecting keyword_end /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/format.rb:70: syntax error, unexpected $end, expecting keyword_end from /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:27:in `require' from /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/installer.rb:10:in `' from /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:27:in `gem_original_require' from /Users/stephen/dev/ruby/1.9_trunk/lib/ruby/site_ruby/1.9/rubygems/custom_require.rb:27:in `require' from /Users/stephen/dev/ruby/src/rubygems-0.9.4/./post-install.rb:83:in `install_sources' from /Users/stephen/dev/ruby/src/rubygems-0.9.4/./post-install.rb:116:in `run_hook' from setup.rb:1560:in `instance_eval' from setup.rb:1560:in `run_hook' from setup.rb:1526:in `exec_task_traverse' from setup.rb:1342:in `exec_install' from setup.rb:1000:in `exec_install' from setup.rb:814:in `invoke' from setup.rb:773:in `invoke' from setup.rb:1578:in `
' From luislavena at gmail.com Sun Nov 18 13:05:25 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 18 Nov 2007 15:05:25 -0300 Subject: [Rubygems-developers] what version rubygems for ruby 1.9? In-Reply-To: References: Message-ID: <71166b3b0711181005k6ad38c5eubf468d117271752c@mail.gmail.com> On Nov 18, 2007 4:07 AM, Stephen Bannasch wrote: > I'm testing things in trunk ruby 1.9 and trunk rubygems is working so > far. When I tried to instead install rubgems-0.9.4 I got an error > running setup.rb. Is this expected -- should I only use the newer > releases with 1.9? > Latest trunk of rubygems is compatible with latest trunk of ruby. Prior versions of RubyGems are not compatible with 1.9, as stated by Eric Hodel in his blog: http://blog.segment7.net/articles/2007/09/20/rubygems-tests-pass-on-1-9 (Or maybe I interpreted that from the post). All the functionality you had with previous stable 0.9.4 is present in latest beta. In case you're worried about stability, why use ruby 1.9 in the first place? ;-) -- 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 stephen.bannasch at deanbrook.org Mon Nov 19 09:38:14 2007 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 19 Nov 2007 09:38:14 -0500 Subject: [Rubygems-developers] what version rubygems for ruby 1.9? In-Reply-To: <71166b3b0711181005k6ad38c5eubf468d117271752c@mail.gmail.com> References: <71166b3b0711181005k6ad38c5eubf468d117271752c@mail.gmail.com> Message-ID: >On Nov 18, 2007 4:07 AM, Stephen Bannasch > wrote: >> I'm testing things in trunk ruby 1.9 and trunk rubygems is working so >> far. When I tried to instead install rubgems-0.9.4 I got an error >> running setup.rb. Is this expected -- should I only use the newer >> releases with 1.9? >> > >Latest trunk of rubygems is compatible with latest trunk of ruby. Thanks for the info. >Prior versions of RubyGems are not compatible with 1.9, as stated by >Eric Hodel in his blog: > >http://blog.segment7.net/articles/2007/09/20/rubygems-tests-pass-on-1-9 > >(Or maybe I interpreted that from the post). > >All the functionality you had with previous stable 0.9.4 is present in >latest beta. > >In case you're worried about stability, why use ruby 1.9 in the first place? ;-) I'm not worried about stability -- in working on my last issue I learned how to easily setup and maintain multiple ruby and gems environments and decided to try out 1.9. I was just checking different combinations because it was so easy. From thewoolleyman at gmail.com Mon Nov 19 13:10:29 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 19 Nov 2007 11:10:29 -0700 Subject: [Rubygems-developers] Tinderbox (Was: [dependencies]) In-Reply-To: <78240373-4E7E-48E9-B542-5E0EA8F0B86A@segment7.net> References: <71166b3b0711061844k21e4544qda364b897d972861@mail.gmail.com> <61686418-BB5B-4EEA-AA4E-96290021E489@segment7.net> <069ED27E-B289-45FF-BD03-95F230880289@segment7.net> <4D232BD3-1DC7-4A3D-9E3E-2EB4651565F1@segment7.net> <78240373-4E7E-48E9-B542-5E0EA8F0B86A@segment7.net> Message-ID: On 11/11/07, Eric Hodel wrote: > The number one problem with tinderbox is that it requires investment > from the community to run tinderbox clients for firebrigade. I aim > to remove this problem by using EC2, but I won't get to that until > after RubyGems is released. Ping me when you start this. This sounds interesting, especially the EC2 setup stuff. The OS setup is up my alley, and I can probably get my company to pop for Windows licenses, etc. Is there funding lined up (http://rubyforge.org/credits/ ?) for the actual EC2 instances? > > The rest of the problems involve updating tinderbox for the changes > in RubyGems. The internal APIs were not very friendly when I started > tinderbox, so it has bitrotted a bit. OK. Again, let me know how this goes. Do you plan on just cranking this out yourself, or would you want help? If you want help, do you plan on starting a list/tracker, keeping it on this list, or via private email? Thanks, Chad From drbrain at segment7.net Mon Nov 19 15:08:31 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 19 Nov 2007 12:08:31 -0800 Subject: [Rubygems-developers] what version rubygems for ruby 1.9? In-Reply-To: References: Message-ID: On Nov 17, 2007, at 23:07 , Stephen Bannasch wrote: > I'm testing things in trunk ruby 1.9 and trunk rubygems is working so > far. When I tried to instead install rubgems-0.9.4 I got an error > running setup.rb. Is this expected -- should I only use the newer > releases with 1.9? RubyGems has been in 1.9 for a couple weeks now, no need to install anything. -- 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 Nov 19 23:18:15 2007 From: transfire at gmail.com (Trans) Date: Mon, 19 Nov 2007 23:18:15 -0500 Subject: [Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again) Message-ID: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> I'm still trying to figure how to package a project that has native extensions but also pure ruby fallbacks. My inclination is to have the gem automatically fallback to pure Ruby if extension compilation fails. I've even made a patch to RubyGems that allows for this, via a settable gemspec option. Would others like to see this in RubyGems? Is it worth my effort to submit the patch? If not, my only alternative seems to be to separate the native extension into a different package. However, I would still like others to be able to add the native extension package as a dependency --but a non-critical one. That is to say, if the dependency fails to compile, I don't want it to halt the installation of the primary package. This is important. ActionMailer depends on TMail. But currently it hauls around a vendors copy of the pure Ruby version. For it to have an external dependency instead it must count on TMail be fault tolerant, and not to derail the installation of Rails. T. From drbrain at segment7.net Tue Nov 20 01:12:58 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 19 Nov 2007 22:12:58 -0800 Subject: [Rubygems-developers] [ANN] RubyGems 0.9.5 Message-ID: <7744FFF7-6CF0-4AAC-9BBE-284284E36497@segment7.net> RubyGems 0.9.5 adds several new features and fixes several bugs. To upgrade to the latest RubyGems: gem update --system To upgrade to the latest RubyGems by hand: * Download RubyGems from http://rubyforge.org/frs/? group_id=126&release_id=16500 * `gem install rubygems-update-0.9.5.gem` * `update_rubygems` To install RubyGems from scratch: * Download RubyGems source .tgz or .zip file from http://rubyforge.org/frs/?group_id=126&release_id=16500 * Unpack the source .tgz or .zip * `ruby setup.rb` To install RubyGems on Ruby 1.9 update your ruby trunk checkout and reinstall. 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 * `gem.bat` and bin stubs on mswin platforms are improved and compatible with the One-Click Installer * Multi-version diamond dependencies only are installed once * Bulk index updates take less memory * -V now enables verbose instead of -v to avoid collision with -- version's -v * `gem install -i` makes sure all depenencies are installed * `gem update --system` reinstalls into the prefix it was originally installe 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::Platfor::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 souces --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 * Removed gem* commands are now replaced with stubs that warn * 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 === Special Thanks * Daniel Berger for win32 support and testing * Luis Lavena for win32 support and testing * Tom Copeland for help testing and releasing the new indexer * Wilson Bilkovich for the new Marshal 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 weyus at att.net Tue Nov 20 02:24:46 2007 From: weyus at att.net (Wes Gamble) Date: Tue, 20 Nov 2007 01:24:46 -0600 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? Message-ID: <47428BBE.1020309@att.net> I updated to 0.9.5 Rubygems, and now all of my updates of my (previously) precompiled Windows gems are now attempting to compile via extconf.rb, etc. Are precompiled versions of gems for Windows available? If so, how do I specify that I want one? I attempted to use the --platform x86-mswin32-80 modifier which I thought would pull a precompiled gem, but no such luck. Thanks, Wes From drbrain at segment7.net Tue Nov 20 03:33:10 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 20 Nov 2007 00:33:10 -0800 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? In-Reply-To: <47428BBE.1020309@att.net> References: <47428BBE.1020309@att.net> Message-ID: <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> On Nov 19, 2007, at 23:24 , Wes Gamble wrote: > I updated to 0.9.5 Rubygems, and now all of my updates of my > (previously) precompiled Windows gems are now attempting to compile > via > extconf.rb, etc. > > Are precompiled versions of gems for Windows available? If so, how > do I > specify that I want one? > > I attempted to use the --platform x86-mswin32-80 modifier which I > thought would pull a precompiled gem, but no such luck. Please provide `gem env` output and an screen capture per the release notes. -- 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 weyus at att.net Tue Nov 20 09:50:18 2007 From: weyus at att.net (Wes Gamble) Date: Tue, 20 Nov 2007 08:50:18 -0600 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? In-Reply-To: <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> References: <47428BBE.1020309@att.net> <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> Message-ID: <4742F42A.80705@att.net> Eric Hodel wrote: > On Nov 19, 2007, at 23:24 , Wes Gamble wrote: > > >> I updated to 0.9.5 Rubygems, and now all of my updates of my >> (previously) precompiled Windows gems are now attempting to compile >> via >> extconf.rb, etc. >> >> Are precompiled versions of gems for Windows available? If so, how >> do I >> specify that I want one? >> >> I attempted to use the --platform x86-mswin32-80 modifier which I >> thought would pull a precompiled gem, but no such luck. >> > > Please provide `gem env` output and an screen capture per the release > notes. > I seem to have mostly figured out my problem. I was able to update most of my precompiled gems on my Windows install by passing "mswin32" to the --platform option. Clearly, this does not jive with the help which implies that the format of the --platform argument should be #{cpu}-#{os}-#{version}. The only gem I was unable to update was "fastthread" which attempts to compile no matter what I pass it. All of my other gems update correctly. Is there a way to force the platform globally (via an env. var. or something) so I don't have to remember to specify "--platform mswin32" on future updates? Below is "gem env" output followed by a failed attempt to update one gem (with no --platform setting) and a successful attempt to update the same gem (with --platform mswin32). Thanks, Wes C:\eclipse\workspace>gem env RubyGems Environment: - RUBYGEMS VERSION: 0.9.5 (0.9.5) - RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [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 C:\eclipse\workspace>gem update rjb Updating installed gems... Attempting remote update of rjb Building native extensions. This could take a while... ERROR: Error installing rjb: ERROR: Failed to build gem native extension. c:/ruby/bin/ruby.exe extconf.rb update rjb checking for jni.h... no *** extconf.rb failed *** Could not create Makefile due to some reason, probably lack of necessary libraries and/or headers. Check the mkmf.log file for more details. You may need configuration options. Provided configuration options: --with-opt-dir --without-opt-dir --with-opt-include --without-opt-include=${opt-dir}/include --with-opt-lib --without-opt-lib=${opt-dir}/lib --with-make-prog --srcdir=. --curdir --ruby=c:/ruby/bin/ruby Gem files will remain installed in c:/ruby/lib/ruby/gems/1.8/gems/rjb-1.0.11 for inspection. Results logged to c:/ruby/lib/ruby/gems/1.8/gems/rjb-1.0.11/ext/gem_make.out Gems: [rjb] updated C:\eclipse\workspace>gem update rjb --platform mswin32 Updating installed gems... Attempting remote update of rjb Successfully installed rjb-1.0.11-mswin32 1 gem installed Gems: [rjb] updated From luislavena at gmail.com Tue Nov 20 10:33:26 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 20 Nov 2007 12:33:26 -0300 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? In-Reply-To: <4742F42A.80705@att.net> References: <47428BBE.1020309@att.net> <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> <4742F42A.80705@att.net> Message-ID: <71166b3b0711200733q12374e2cme234ec2a2c035b6c@mail.gmail.com> On Nov 20, 2007 11:50 AM, Wes Gamble wrote: > Eric Hodel wrote: > > On Nov 19, 2007, at 23:24 , Wes Gamble wrote: > > > > > >> I updated to 0.9.5 Rubygems, and now all of my updates of my > >> (previously) precompiled Windows gems are now attempting to compile > >> via > >> extconf.rb, etc. > >> > >> Are precompiled versions of gems for Windows available? If so, how > >> do I > >> specify that I want one? > >> > >> I attempted to use the --platform x86-mswin32-80 modifier which I > >> thought would pull a precompiled gem, but no such luck. > >> > > > > Please provide `gem env` output and an screen capture per the release > > notes. > > > I seem to have mostly figured out my problem. I was able to update most > of my precompiled gems on my Windows > install by passing "mswin32" to the --platform option. Clearly, this > does not jive with the help which implies that the > format of the --platform argument should be #{cpu}-#{os}-#{version}. > Wes let me clear your problem: You said that you platform was x86-mswin32-80, but actually is x86-mswin32-60. I have installed successfully gems made with platform mswin32 under x86-mswin32-60. x86-mswin32-80 is another breed of platform, since the libruby library (msvcrt-ruby18.dll) is not the same for VC8 (msvcr80-ruby18.dll) so the pre-compiled gems will fail. I'll check this later at the office with both versions (VC6 and VC8) versions of ruby and see what happens. > The only gem I was unable to update was "fastthread" which attempts to > compile no matter what I pass it. > All of my other gems update correctly. > Latest fastthread version is not available as pre-compiled, since poses no use for Windows (this was discussed long time ago in mongrel-users list) and also 1.8.6 Ruby ships with fastthread enabled in the core, so no need for the gem. > Is there a way to force the platform globally (via an env. var. or > something) so I don't have to remember to specify "--platform mswin32" > on future updates? > It seems odd that didn't take in consideration mswin32 as x86-mswin32-60 compatible, this was working before without problems. Maybe some of the changes introduced to fix the Indexer produced this incompatibility. Will check later and provide feedback (also will try patches since they are more useful) :-) > Below is "gem env" output followed by a failed attempt to update one gem > (with no --platform setting) and a successful attempt to update the same > gem (with --platform mswin32). > BTW, I suggest you update your ruby to patchlevel 111 (you can use latest one-click installer release candidate for that). Patchlevel 0 didn't have a working fastthread bundled :-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 weyus at att.net Tue Nov 20 14:16:18 2007 From: weyus at att.net (Wes Gamble) Date: Tue, 20 Nov 2007 13:16:18 -0600 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? In-Reply-To: <71166b3b0711200733q12374e2cme234ec2a2c035b6c@mail.gmail.com> References: <47428BBE.1020309@att.net> <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> <4742F42A.80705@att.net> <71166b3b0711200733q12374e2cme234ec2a2c035b6c@mail.gmail.com> Message-ID: <47433282.8010301@att.net> Luis Lavena wrote: > On Nov 20, 2007 11:50 AM, Wes Gamble wrote: > >> Eric Hodel wrote: >> >>> On Nov 19, 2007, at 23:24 , Wes Gamble wrote: >>> >>> >>>> I updated to 0.9.5 Rubygems, and now all of my updates of my >>>> (previously) precompiled Windows gems are now attempting to compile >>>> via >>>> extconf.rb, etc. >>>> >>>> Are precompiled versions of gems for Windows available? If so, how >>>> do I >>>> specify that I want one? >>>> >>>> I attempted to use the --platform x86-mswin32-80 modifier which I >>>> thought would pull a precompiled gem, but no such luck. >>>> >>>> >>> > Wes let me clear your problem: > > You said that you platform was x86-mswin32-80, but actually is x86-mswin32-60. > > > Luis, thanks for the information. Just to be clear, my initial attempt to use --platform _was_ incorrect (using 80 instead of 60), but specifying x86-mswin32-60 also does not work, which makes sense, since I assume that this is what is used if I don't specify --platform explicitly. Thanks, Wes From luislavena at gmail.com Tue Nov 20 14:39:31 2007 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 20 Nov 2007 16:39:31 -0300 Subject: [Rubygems-developers] Are pre-compiled gems for Windows available anymore under 0.9.5? In-Reply-To: <47433282.8010301@att.net> References: <47428BBE.1020309@att.net> <7FD7E935-4CC2-481F-A96C-B7D1452A0EF3@segment7.net> <4742F42A.80705@att.net> <71166b3b0711200733q12374e2cme234ec2a2c035b6c@mail.gmail.com> <47433282.8010301@att.net> Message-ID: <71166b3b0711201139k4ec0cdb0w3cf32a0c6cc805c1@mail.gmail.com> On Nov 20, 2007 4:16 PM, Wes Gamble wrote: > Luis, thanks for the information. Just to be clear, my initial attempt > to use --platform _was_ incorrect (using 80 instead of 60), > but specifying x86-mswin32-60 also does not work, which makes sense, > since I assume that this is what is used if I don't specify > --platform explicitly. I know, but just wanted to state that in a mail for the record ;-) Anyway, I'm seeing this behavior: Some gems uses 'mswin32' (Gem::Platform::WIN32) as specification platform, get parsed by RubyGems 0.9.5 in this way: D:\Users\Luis\sources\oss\rubygems-trunk>irb -Ilib irb(main):001:0> require 'rubygems' => true irb(main):002:0> Gem::Platform.new('mswin32') => # Other gems, uses ::CURRENT to set the platform, and CURRENT is interpreted as RUBY_PLATFORM (i386-mswin32): irb(main):003:0> Gem::Platform.new(RUBY_PLATFORM) => # Sooo: irb(main):008:0> Gem::Platform.local === Gem::Platform.new('i386-mswin32') => true irb(main):009:0> Gem::Platform.local === Gem::Platform.new('mswin32') => false Eric: could see in which place of install_command the platform is checked... and there is no 'exception' to the 'mswin32' and 'i386-mswin32' rule. Mea culpa: some gems opted for the WIN32 platform 'mswin32' platform set in the gem platform specification file, but this is wrong and should have used CURRENT all the time. Mongrel, like rjb shows this problem, and we need to fix it in some place (either rubygems or the published gems). -- 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 Sat Nov 24 19:11:51 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 24 Nov 2007 21:11:51 -0300 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. Message-ID: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> Hello Guys, Trying to fit latest rubygems into One-Click Installer (RC2-> Final release) found that gems with 'mswin32' aren't used and 'ruby' ones takes priority: gem install mongrel --no-ri --no-rdoc: ... ERROR: Failed to build gem native extension. ... The mongrel gem metadata contains 'mswin32' as platform (Gem::Platform:WIN32, built with 0.9.4) -- I used that based on other gems using that platform -- my mistake. There's also others gems like FXRuby that indicates mswin32 as platform in their gem specification. wxRuby gems, on the other hand, install successfully since they used Gem::Platform::CURRENT to set their specification metadata. (i386-mswin32, built with 0.9.4) Also tried supply --platform 'mswin32', 'x86-mswin32-60', 'i386-mswin32' all with and without single quotes. all with the same result. I'm looking into the tests cases and there isn't anyone specified for this (looked into test_gem_installer.rb, test_gem_commands_install_command.rb) Daniel and Eric, what do you think about this? Where should I create a fake platform specific gem to test this out? I guess that final 1.8.6-p111 One-Click will ship with 0.9.4 for the time being. Thanks in advance all for your time. Have a nice 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 From djberg96 at gmail.com Sat Nov 24 21:58:26 2007 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 24 Nov 2007 19:58:26 -0700 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> Message-ID: <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> On Nov 24, 2007 5:11 PM, Luis Lavena wrote: > Hello Guys, > > Trying to fit latest rubygems into One-Click Installer (RC2-> Final > release) found that gems with 'mswin32' aren't used and 'ruby' ones > takes priority: > > gem install mongrel --no-ri --no-rdoc: > ... > ERROR: Failed to build gem native extension. > ... > > The mongrel gem metadata contains 'mswin32' as platform > (Gem::Platform:WIN32, built with 0.9.4) -- I used that based on other > gems using that platform -- my mistake. > > There's also others gems like FXRuby that indicates mswin32 as > platform in their gem specification. > > wxRuby gems, on the other hand, install successfully since they used > Gem::Platform::CURRENT to set their specification metadata. > (i386-mswin32, built with 0.9.4) > > Also tried supply --platform 'mswin32', 'x86-mswin32-60', > 'i386-mswin32' all with and without single quotes. all with the same > result. > > I'm looking into the tests cases and there isn't anyone specified for > this (looked into test_gem_installer.rb, > test_gem_commands_install_command.rb) > > Daniel and Eric, what do you think about this? Where should I create a > fake platform specific gem to test this out? > > I guess that final 1.8.6-p111 One-Click will ship with 0.9.4 for the time being. I'm not sure yet. At this point I'm inclined to think we should go back to the "ask to install" approach, and add a "--no-ask" option to skip it, because there's always going to be a case where a user wanted version X but instead got version Y. Regards, Dan From luislavena at gmail.com Sun Nov 25 00:59:23 2007 From: luislavena at gmail.com (Luis Lavena) Date: Sun, 25 Nov 2007 02:59:23 -0300 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> Message-ID: <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> On Nov 24, 2007 11:58 PM, Daniel Berger wrote: > On Nov 24, 2007 5:11 PM, Luis Lavena wrote: > > > > Daniel and Eric, what do you think about this? Where should I create a > > fake platform specific gem to test this out? > > > > I guess that final 1.8.6-p111 One-Click will ship with 0.9.4 for the time being. > > I'm not sure yet. > > At this point I'm inclined to think we should go back to the "ask to > install" approach, and add a "--no-ask" option to skip it, because > there's always going to be a case where a user wanted version X but > instead got version Y. > It's odd because of the two gems with the same version number, RubyGems choose ::RUBY one instead of 'mswin32'. I failed to find the right place where that comparison is made to recreate the scenario and provide a patch, is beyond my knowledge and understanding on how RubyGems works. (maybe need to invest more time on it). Also, is useless the platform switch in this case, since it always prioritize the RUBY version instead of the platform specific one. Oh well, maybe a fresh look during the week will be more productive. I'm burned out :-P Thanks in advance for your time. -- 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 Nov 25 06:38:23 2007 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 25 Nov 2007 03:38:23 -0800 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> Message-ID: <8FA6BCB1-E8B5-450E-B614-913675BAB23D@segment7.net> On Nov 24, 2007, at 21:59 , Luis Lavena wrote: > On Nov 24, 2007 11:58 PM, Daniel Berger wrote: >> On Nov 24, 2007 5:11 PM, Luis Lavena wrote: >>> >>> Daniel and Eric, what do you think about this? Where should I >>> create a >>> fake platform specific gem to test this out? >>> >>> I guess that final 1.8.6-p111 One-Click will ship with 0.9.4 for >>> the time being. >> >> I'm not sure yet. >> >> At this point I'm inclined to think we should go back to the "ask to >> install" approach, and add a "--no-ask" option to skip it, because >> there's always going to be a case where a user wanted version X but >> instead got version Y. > > It's odd because of the two gems with the same version number, > RubyGems choose ::RUBY one instead of 'mswin32'. > > I failed to find the right place where that comparison is made to > recreate the scenario and provide a patch, is beyond my knowledge and > understanding on how RubyGems works. (maybe need to invest more time > on it). > > Also, is useless the platform switch in this case, since it always > prioritize the RUBY version instead of the platform specific one. > > Oh well, maybe a fresh look during the week will be more productive. > I'm burned out :-P I think an index update with the new code will fix it. Currently the gems all have nil for the cpu field. -- 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 Sun Nov 25 18:33:21 2007 From: tom at infoether.com (Tom Copeland) Date: Sun, 25 Nov 2007 18:33:21 -0500 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <8FA6BCB1-E8B5-450E-B614-913675BAB23D@segment7.net> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> <8FA6BCB1-E8B5-450E-B614-913675BAB23D@segment7.net> Message-ID: <1196033601.6294.38.camel@bugs.hal> On Sun, 2007-11-25 at 03:38 -0800, Eric Hodel wrote: > I think an index update with the new code will fix it. Currently the > gems all have nil for the cpu field. Cool, done, how's it look now? Yours, Tom From luislavena at gmail.com Mon Nov 26 08:39:21 2007 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 26 Nov 2007 10:39:21 -0300 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <1196033601.6294.38.camel@bugs.hal> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> <8FA6BCB1-E8B5-450E-B614-913675BAB23D@segment7.net> <1196033601.6294.38.camel@bugs.hal> Message-ID: <71166b3b0711260539k7876dc70x3b604f060ea3087e@mail.gmail.com> On Nov 25, 2007 8:33 PM, Tom Copeland wrote: > On Sun, 2007-11-25 at 03:38 -0800, Eric Hodel wrote: > > I think an index update with the new code will fix it. Currently the > > gems all have nil for the cpu field. > > Cool, done, how's it look now? > Now it install, but the platform thing is still bitching all over...: This is limited to gems with WIN32 platform use as reference: mongrel 1.1.1 (platform: mswin32). mongrel-1.1.1-mswin32.gem gem install mongrel: Bulk updating Gem source index for: http://gems.rubyforge.org Successfully installed gem_plugin-0.2.3 Successfully installed cgi_multipart_eof_fix-2.5.0 Successfully installed mongrel-1.1.1-x86-mswin32 3 gems installed This looks good, but notice the platform of mongrel: x86-mswin32 Now, irb: irb(main):001:0> require 'rubygems' => true irb(main):002:0> require 'mongrel' LoadError: no such file to load -- mongrel from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from (irb):2 D:\Users\Luis>dir "C:/Ruby/lib/ruby/gems/1.8/gems" mongrel-1.1.1-x86-mswin32 If I manually rename the mongrel directory to "mongrel-1.1.1-mswin32" it the require works. Guess the installer isn't honoring the @original_platform? -- 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 todd.fisher at gmail.com Mon Nov 26 13:54:54 2007 From: todd.fisher at gmail.com (Todd Fisher) Date: Mon, 26 Nov 2007 13:54:54 -0500 Subject: [Rubygems-developers] Change in Gem::Requirement.create("~> 1.0.0").satisfied_by? semantics? Message-ID: Hi, After upgrading from rubygems 0.9.4 to 0.9.5 I noticed a change in how the satisfied_by? method compares versions. Here's a simple example to demonstrate the change in behavior. 0.9.5: irb(main):001:0> gem_list = ["1.0.67943", "1.1.75596"] => ["1.0.67943", "1.1.75596"] irb(main):002:0> req = Gem::Requirement.create("~> 1.0.0") => #", #]], @version=nil> irb(main):003:0> gem_list.select{|v| req.satisfied_by?(Gem::Version.new(v))} => ["1.0.67943", "1.1.75596"] 0.9.4: irb(main):002:0> gem_list = ["1.0.67943", "1.1.75596"] => ["1.0.67943", "1.1.75596"] irb(main):003:0> req = Gem::Requirement.create("~> 1.0.0") => #", #]]> irb(main):004:0> gem_list.select{|v| req.satisfied_by?(Gem::Version.new(v))} => ["1.0.67943"] irb(main):005:0> Is this an intended change? Thanks, Todd From drbrain at segment7.net Mon Nov 26 18:06:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 26 Nov 2007 15:06:50 -0800 Subject: [Rubygems-developers] Change in Gem::Requirement.create("~> 1.0.0").satisfied_by? semantics? In-Reply-To: References: Message-ID: On Nov 26, 2007, at 10:54 , Todd Fisher wrote: > After upgrading from rubygems 0.9.4 to 0.9.5 I noticed a change in > how the satisfied_by? method compares versions. > > Here's a simple example to demonstrate the change in behavior. > > > 0.9.5: > > irb(main):001:0> gem_list = ["1.0.67943", "1.1.75596"] > => ["1.0.67943", "1.1.75596"] > irb(main):002:0> req = Gem::Requirement.create("~> 1.0.0") > => #", # "1.0.0">]], @version=nil> > irb(main):003:0> gem_list.select{|v| req.satisfied_by? > (Gem::Version.new(v))} > => ["1.0.67943", "1.1.75596"] > > > 0.9.4: > > irb(main):002:0> gem_list = ["1.0.67943", "1.1.75596"] > => ["1.0.67943", "1.1.75596"] > irb(main):003:0> req = Gem::Requirement.create("~> 1.0.0") > => # @requirements=[["~>", #]]> > irb(main):004:0> gem_list.select{|v| req.satisfied_by? > (Gem::Version.new(v))} > => ["1.0.67943"] > irb(main):005:0> > > > Is this an intended change? No. Please file a bug. -- 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 Nov 26 18:07:37 2007 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 26 Nov 2007 15:07:37 -0800 Subject: [Rubygems-developers] Latest trunk still misses 'mswin32' as valid platform when installing gems. In-Reply-To: <71166b3b0711260539k7876dc70x3b604f060ea3087e@mail.gmail.com> References: <71166b3b0711241611i42788c7bq121c7f11de7daf25@mail.gmail.com> <6037b70c0711241858t1f0ac5b5sef165919b0f60df@mail.gmail.com> <71166b3b0711242159r46955709i2d8fb39e67fdeaf1@mail.gmail.com> <8FA6BCB1-E8B5-450E-B614-913675BAB23D@segment7.net> <1196033601.6294.38.camel@bugs.hal> <71166b3b0711260539k7876dc70x3b604f060ea3087e@mail.gmail.com> Message-ID: <4B971F66-7DEA-49C1-808D-1EF63E3E7F14@segment7.net> On Nov 26, 2007, at 05:39 , Luis Lavena wrote: > On Nov 25, 2007 8:33 PM, Tom Copeland wrote: >> On Sun, 2007-11-25 at 03:38 -0800, Eric Hodel wrote: >>> I think an index update with the new code will fix it. Currently >>> the >>> gems all have nil for the cpu field. >> >> Cool, done, how's it look now? > > Now it install, but the platform thing is still bitching all over...: > > This is limited to gems with WIN32 platform > > use as reference: mongrel 1.1.1 (platform: mswin32). mongrel-1.1.1- > mswin32.gem > gem install mongrel: > Bulk updating Gem source index for: http://gems.rubyforge.org > Successfully installed gem_plugin-0.2.3 > Successfully installed cgi_multipart_eof_fix-2.5.0 > Successfully installed mongrel-1.1.1-x86-mswin32 > 3 gems installed > > This looks good, but notice the platform of mongrel: x86-mswin32 > > Now, irb: > irb(main):001:0> require 'rubygems' > => true > irb(main):002:0> require 'mongrel' > LoadError: no such file to load -- mongrel > from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/ > custom_require.rb:27:in > `gem_original_require' > from C:/Ruby/lib/ruby/site_ruby/1.8/rubygems/ > custom_require.rb:27:in > `require' > from (irb):2 > > D:\Users\Luis>dir "C:/Ruby/lib/ruby/gems/1.8/gems" > mongrel-1.1.1-x86-mswin32 > > If I manually rename the mongrel directory to "mongrel-1.1.1-mswin32" > it the require works. > Guess the installer isn't honoring the @original_platform? Ok. I will walk through that code again and sprinkle in extra tests and make it work later 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 todd.fisher at gmail.com Tue Nov 27 05:18:38 2007 From: todd.fisher at gmail.com (Todd Fisher) Date: Tue, 27 Nov 2007 05:18:38 -0500 Subject: [Rubygems-developers] Change in Gem::Requirement.create("~> 1.0.0").satisfied_by? semantics? In-Reply-To: References: Message-ID: bug 15948 On 11/26/07, Eric Hodel wrote: > On Nov 26, 2007, at 10:54 , Todd Fisher wrote: > > After upgrading from rubygems 0.9.4 to 0.9.5 I noticed a change in > > how the satisfied_by? method compares versions. > > > > Here's a simple example to demonstrate the change in behavior. > > > > > > 0.9.5: > > > > irb(main):001:0> gem_list = ["1.0.67943", "1.1.75596"] > > => ["1.0.67943", "1.1.75596"] > > irb(main):002:0> req = Gem::Requirement.create("~> 1.0.0") > > => #", # > "1.0.0">]], @version=nil> > > irb(main):003:0> gem_list.select{|v| req.satisfied_by? > > (Gem::Version.new(v))} > > => ["1.0.67943", "1.1.75596"] > > > > > > 0.9.4: > > > > irb(main):002:0> gem_list = ["1.0.67943", "1.1.75596"] > > => ["1.0.67943", "1.1.75596"] > > irb(main):003:0> req = Gem::Requirement.create("~> 1.0.0") > > => # > @requirements=[["~>", #]]> > > irb(main):004:0> gem_list.select{|v| req.satisfied_by? > > (Gem::Version.new(v))} > > => ["1.0.67943"] > > irb(main):005:0> > > > > > > Is this an intended change? > > No. Please file a bug. > > -- > 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 mfp at acm.org Tue Nov 27 14:40:37 2007 From: mfp at acm.org (Mauricio Fernandez) Date: Tue, 27 Nov 2007 20:40:37 +0100 Subject: [Rubygems-developers] gem update --system probably broken on OSX Message-ID: <20071127194037.GC3721@tux-chan> I haven't experienced this directly, but the code is quite clear. I had to take a look at lib/rubygems.rb after receiving bug reports for FastRI+Leopard and found: Index: lib/rubygems.rb =================================================================== --- lib/rubygems.rb (revision 1493) +++ lib/rubygems.rb (revision 1498) [...] @@ -519,7 +522,7 @@ # not specified in the environment. def default_dir if defined? RUBY_FRAMEWORK_VERSION - return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems") + return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems", Config::CONFIG['ruby_version']) else File.join(Config::CONFIG['libdir'], 'ruby', 'gems', Config::CONFIG['ruby_version']) end It seems that doing gem update --system will lose all your gems. PS: is such vendor/repackager-specific patching encouraged? In other words, would it be acceptable to have FreeBSD, Debian, Gentoo and friends add a number of if defined? __SOME_PLATFORM_ID__ ...? If they were all allowed to do what Apple did (provide patches to be applied by the RubyGems developers), they would be able to solve problems like those discussed in ruby-talk recently. Until a better alternative is provided, this would let those who care about their RubyGems packaging help themselves, the way Apple did. -- Mauricio Fernandez - http://eigenclass.org From laurent.sansonetti at gmail.com Tue Nov 27 17:11:08 2007 From: laurent.sansonetti at gmail.com (Laurent Sansonetti) Date: Tue, 27 Nov 2007 23:11:08 +0100 Subject: [Rubygems-developers] gem update --system probably broken on OSX In-Reply-To: <20071127194037.GC3721@tux-chan> References: <20071127194037.GC3721@tux-chan> Message-ID: <1be7247c0711271411j39ac45f4s7f4959e9f475dc53@mail.gmail.com> On Nov 27, 2007 8:40 PM, Mauricio Fernandez wrote: > I haven't experienced this directly, but the code is quite clear. > I had to take a look at lib/rubygems.rb after receiving bug reports for > FastRI+Leopard and found: > > Index: lib/rubygems.rb > =================================================================== > --- lib/rubygems.rb (revision 1493) > +++ lib/rubygems.rb (revision 1498) > [...] > @@ -519,7 +522,7 @@ > # not specified in the environment. > def default_dir > if defined? RUBY_FRAMEWORK_VERSION > - return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems") > + return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems", Config::CONFIG['ruby_version']) > else > File.join(Config::CONFIG['libdir'], 'ruby', 'gems', Config::CONFIG['ruby_version']) > end > > It seems that doing gem update --system will lose all your gems. > Actually no, this code path wasn't used until Leopard provided a version of Ruby distributed as a framework. The version of RubyGems that ships by default in Leopard has this change too. Upgrading RubyGems gem should not break anything in Leopard. > PS: is such vendor/repackager-specific patching encouraged? In other words, > would it be acceptable to have FreeBSD, Debian, Gentoo and friends add a > number of if defined? __SOME_PLATFORM_ID__ ...? If they were all allowed to > do what Apple did (provide patches to be applied by the RubyGems developers), > they would be able to solve problems like those discussed in ruby-talk > recently. Until a better alternative is provided, this would let those who > care about their RubyGems packaging help themselves, the way Apple did. > This isn't really a vendor-specific change. RUBY_FRAMEWORK_VERSION is supposed to be defined by Ruby builds that have been frameworki'zed (in a special directory bundle). Such a version could potentially be made for GNUStep too, for example. However, there was another change to support the Apple dual-repository configuration, which is this time purely vendor specific. I would also be glad to get rid of this change in the future. The 1.9 integration might help. Laurent From mfp at acm.org Tue Nov 27 18:38:51 2007 From: mfp at acm.org (Mauricio Fernandez) Date: Wed, 28 Nov 2007 00:38:51 +0100 Subject: [Rubygems-developers] gem update --system probably broken on OSX In-Reply-To: <1be7247c0711271411j39ac45f4s7f4959e9f475dc53@mail.gmail.com> References: <20071127194037.GC3721@tux-chan> <1be7247c0711271411j39ac45f4s7f4959e9f475dc53@mail.gmail.com> Message-ID: <20071127233851.GD3721@tux-chan> On Tue, Nov 27, 2007 at 11:11:08PM +0100, Laurent Sansonetti wrote: > On Nov 27, 2007 8:40 PM, Mauricio Fernandez wrote: > > I haven't experienced this directly, but the code is quite clear. > > I had to take a look at lib/rubygems.rb after receiving bug reports for > > FastRI+Leopard and found: > > > > Index: lib/rubygems.rb > > =================================================================== > > --- lib/rubygems.rb (revision 1493) > > +++ lib/rubygems.rb (revision 1498) > > [...] > > @@ -519,7 +522,7 @@ > > # not specified in the environment. > > def default_dir > > if defined? RUBY_FRAMEWORK_VERSION > > - return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems") > > + return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems", Config::CONFIG['ruby_version']) > > else > > File.join(Config::CONFIG['libdir'], 'ruby', 'gems', Config::CONFIG['ruby_version']) > > end > > > > It seems that doing gem update --system will lose all your gems. > > > > Actually no, this code path wasn't used until Leopard provided a > version of Ruby distributed as a framework. The version of RubyGems > that ships by default in Leopard has this change too. Upgrading > RubyGems gem should not break anything in Leopard. (What happens if: * you are using Tiger & have a number of gems installed * you upgrade from Tiger to Leopard ? It looks like the path changes both when RUBY_FRAMEWORK_VERSION was defined (because CONFIG["ruby_version"] is appended) and when it wasn't.) As I said, I haven't experienced this myself. I got a bug report for FastRI caused by this path modification, and I was told that gem update --system didn't work properly. There might be some other reason for that. On further reflection, this doesn't matter that much anyway, since binary compatibility is not ensured across minor Ruby releases. It'd be nice if RubyGems were smart enough to know against which ABI the extensions were built, recompile when needed, and migrate all the pure-Ruby libs. > > PS: is such vendor/repackager-specific patching encouraged? In other words, > > would it be acceptable to have FreeBSD, Debian, Gentoo and friends add a > > number of if defined? __SOME_PLATFORM_ID__ ...? If they were all allowed to > > do what Apple did (provide patches to be applied by the RubyGems developers), > > they would be able to solve problems like those discussed in ruby-talk > > recently. Until a better alternative is provided, this would let those who > > care about their RubyGems packaging help themselves, the way Apple did. > > > > This isn't really a vendor-specific change. RUBY_FRAMEWORK_VERSION is > supposed to be defined by Ruby builds that have been frameworki'zed > (in a special directory bundle). Such a version could potentially be > made for GNUStep too, for example. > > However, there was another change to support the Apple dual-repository > configuration, which is this time purely vendor specific. I would also > be glad to get rid of this change in the future. The 1.9 integration > might help. Yes, I was referring to APPLE_GEM_HOME. The 1.9 integration only helps to the extent that it makes easier to standardize changes in rbconfig.rb, but 1.8 needs a solution more urgently. -- Mauricio Fernandez - http://eigenclass.org From laurent.sansonetti at gmail.com Tue Nov 27 19:20:45 2007 From: laurent.sansonetti at gmail.com (Laurent Sansonetti) Date: Wed, 28 Nov 2007 01:20:45 +0100 Subject: [Rubygems-developers] gem update --system probably broken on OSX In-Reply-To: <20071127233851.GD3721@tux-chan> References: <20071127194037.GC3721@tux-chan> <1be7247c0711271411j39ac45f4s7f4959e9f475dc53@mail.gmail.com> <20071127233851.GD3721@tux-chan> Message-ID: <1be7247c0711271620o2b626571r9568bb66d6059ad6@mail.gmail.com> On Nov 28, 2007 12:38 AM, Mauricio Fernandez wrote: > On Tue, Nov 27, 2007 at 11:11:08PM +0100, Laurent Sansonetti wrote: > > On Nov 27, 2007 8:40 PM, Mauricio Fernandez wrote: > > > I haven't experienced this directly, but the code is quite clear. > > > I had to take a look at lib/rubygems.rb after receiving bug reports for > > > FastRI+Leopard and found: > > > > > > Index: lib/rubygems.rb > > > =================================================================== > > > --- lib/rubygems.rb (revision 1493) > > > +++ lib/rubygems.rb (revision 1498) > > > [...] > > > @@ -519,7 +522,7 @@ > > > # not specified in the environment. > > > def default_dir > > > if defined? RUBY_FRAMEWORK_VERSION > > > - return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems") > > > + return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems", Config::CONFIG['ruby_version']) > > > else > > > File.join(Config::CONFIG['libdir'], 'ruby', 'gems', Config::CONFIG['ruby_version']) > > > end > > > > > > It seems that doing gem update --system will lose all your gems. > > > > > > > Actually no, this code path wasn't used until Leopard provided a > > version of Ruby distributed as a framework. The version of RubyGems > > that ships by default in Leopard has this change too. Upgrading > > RubyGems gem should not break anything in Leopard. > > (What happens if: > * you are using Tiger & have a number of gems installed > * you upgrade from Tiger to Leopard > ? > If you installed a custom version of Ruby + RubyGems + some gems, they should stay at the same place. If you installed RubyGems with the system version of Ruby + some gems, then I'm not sure, I think that the installer is not going to keep them in the same place, because there would be some file system merge errors. This is something I can investigate. Anyway, the RUBY_FRAMEWORK_VERSION code path isn't executed in both use cases. > It looks like the path changes both when RUBY_FRAMEWORK_VERSION was defined > (because CONFIG["ruby_version"] is appended) and when it wasn't.) > RUBY_FRAMEWORK_VERSION is only defined in Leopard's Ruby. The code path was there previously, but AFAIK nobody used it yet. Adding the Ruby version to the path is crucial here, otherwise the same path would be used for different versions of Ruby. > As I said, I haven't experienced this myself. I got a bug report for FastRI > caused by this path modification, and I was told that gem update --system > didn't work properly. There might be some other reason for that. > gem update --system didn't work until 0.9.5, because it retrieved a version of RubyGems without the Leopard patch. Many people experienced it, this was probably the same issue. I am pretty sure doing gem update --system now doesn't break Leopard's configuration. Laurent From raasdnil at gmail.com Thu Nov 29 01:03:13 2007 From: raasdnil at gmail.com (Mikel Lindsaar) Date: Thu, 29 Nov 2007 17:03:13 +1100 Subject: [Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again) In-Reply-To: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> References: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> Message-ID: <57a815bf0711282203ja0fced3sf0be049305b62fdd@mail.gmail.com> Obviously I have a vested interest in this as I am part of the TMail maintenance team. I guess from my viewpoint, you want the install to be as smooth as possible and as optimistic as possible. Ideally I would like the following to occur as a default, and I don't think this is unreasonable. (1) try to compile the native extensions (going to be the best / fastest in pretty much every case) (2) if 1 fails then fall back to a plain ruby version - or at least (in the case of gems that don't have a ruby version) provide hooks for us to link into, like display a message that goes "We can't build, I can see you are running Windows from your environment, would you like to try to download and install the windows binary version?" If the user can't compile and wants the native extensions as a binary, then he/she can gem install name-win32 or name-linux or name-whatevergrabsyourfancy. This would have the following benefits: 1) Your gem should basically work on anything WITHOUT user intervention. 2) You have a good chance of getting a native binary built first shot 3) The user can choose to download the native binary themselves if they know how to do it and need it (which implies a certain skill level). 4) You don't have to padd out your gem with a lot of inapplicable binaries for everyone to download. 5) It would be a lot friendlier and useful than throwing unable to find nmake messages in the console. Trans, I think make the patch. OpenSource is all about scratching your own itch. If it is elegant and works then we would be accepted. Until then, really, it is just talk without any concrete examples. Regards Mikel On Nov 20, 2007 3:18 PM, Trans wrote: > I'm still trying to figure how to package a project that has native > extensions but also pure ruby fallbacks. > > My inclination is to have the gem automatically fallback to pure Ruby > if extension compilation fails. I've even made a patch to RubyGems > that allows for this, via a settable gemspec option. Would others like > to see this in RubyGems? Is it worth my effort to submit the patch? > > If not, my only alternative seems to be to separate the native > extension into a different package. However, I would still like others > to be able to add the native extension package as a dependency --but a > non-critical one. That is to say, if the dependency fails to compile, > I don't want it to halt the installation of the primary package. This > is important. ActionMailer depends on TMail. But currently it hauls > around a vendors copy of the pure Ruby version. For it to have an > external dependency instead it must count on TMail be fault tolerant, > and not to derail the installation of Rails. > > T. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20071129/ef5c5e53/attachment-0001.html From transfire at gmail.com Thu Nov 29 21:39:40 2007 From: transfire at gmail.com (Trans) Date: Thu, 29 Nov 2007 21:39:40 -0500 Subject: [Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again) In-Reply-To: <57a815bf0711282203ja0fced3sf0be049305b62fdd@mail.gmail.com> References: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> <57a815bf0711282203ja0fced3sf0be049305b62fdd@mail.gmail.com> Message-ID: <4b6f054f0711291839j3bb31cb3sbc1868e84999f7ae@mail.gmail.com> On Nov 29, 2007 1:03 AM, Mikel Lindsaar wrote: > Obviously I have a vested interest in this as I am part of the TMail > maintenance team. > > I guess from my viewpoint, you want the install to be as smooth as possible > and as optimistic as possible. > > Ideally I would like the following to occur as a default, and I don't think > this is unreasonable. > > (1) try to compile the native extensions (going to be the best / fastest in > pretty much every case) > > (2) if 1 fails then fall back to a plain ruby version - or at least (in the > case of gems that don't have a ruby version) provide hooks for us to link > into, like display a message that goes "We can't build, I can see you are > running Windows from your environment, would you like to try to download and > install the windows binary version?" > > If the user can't compile and wants the native extensions as a binary, then > he/she can gem install name-win32 or name-linux or > name-whatevergrabsyourfancy. well, i think they way it works now is that it will automatically grab the binary if it exists. --you'd have to download the non-binary manually if you wated to try a compiling install. --which is fine I think. > This would have the following benefits: > > 1) Your gem should basically work on anything WITHOUT user intervention. > > > 2) You have a good chance of getting a native binary built first shot > > 3) The user can choose to download the native binary themselves if they know > how to do it and need it (which implies a certain skill level). > > 4) You don't have to padd out your gem with a lot of inapplicable binaries > for everyone to download. > > 5) It would be a lot friendlier and useful than throwing unable to find > nmake messages in the console. > > > > Trans, I think make the patch. OpenSource is all about scratching your own > itch. If it is elegant and works then we would be accepted. Until then, > really, it is just talk without any concrete examples. Welll. I have it. Its quite simple. This is how it works: if you set 'extensions_fallback' to true in the gemspec and an extension fails to build on install then it says "Native extension failed to compile, but this gem has a fallback option. Would you like to complete the install without the native extensions or abort? [Y/n] If the RubyGems team thinks this is acceptable I'll send it their way... Honestly, I don't know how else it can be done. Without this one is stuck with maintaning a secondary gem and trying to inform potential users that there is a pure ruby option in case the native extension one fails --but maybe that's what the RubyGems team considers the better approach? T. From luislavena at gmail.com Fri Nov 30 00:29:44 2007 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 30 Nov 2007 02:29:44 -0300 Subject: [Rubygems-developers] Native Extensions and Pure Ruby Alternatives (again) In-Reply-To: <4b6f054f0711291839j3bb31cb3sbc1868e84999f7ae@mail.gmail.com> References: <4b6f054f0711192018i6eeb896aobe11a3280f1c3d40@mail.gmail.com> <57a815bf0711282203ja0fced3sf0be049305b62fdd@mail.gmail.com> <4b6f054f0711291839j3bb31cb3sbc1868e84999f7ae@mail.gmail.com> Message-ID: <71166b3b0711292129s5dd73144t5c80b49b1effa58c@mail.gmail.com> On Nov 29, 2007 11:39 PM, Trans wrote: > > Welll. I have it. Its quite simple. This is how it works: if you set > 'extensions_fallback' to true in the gemspec and an extension fails to > build on install then it says "Native extension failed to compile, but > this gem has a fallback option. Would you like to complete the install > without the native extensions or abort? [Y/n] > > If the RubyGems team thinks this is acceptable I'll send it their > way... Honestly, I don't know how else it can be done. Without this > one is stuck with maintaning a secondary gem and trying to inform > potential users that there is a pure ruby option in case the native > extension one fails --but maybe that's what the RubyGems team > considers the better approach? > I don't consider that a good approach: A) If you create a product (a gem) that couldn't exist without the native extension, you should try to provide the gem as pure ruby (Gem::Platform::RUBY) and state in the gem requirements "this gems need a compiler". Also, is possible to create gems with the extensions compiled for a specific platform, like we do for Mongrel gem, that will allow the user choose the best one for his case. B) If you create a product (a gem) that can exist without the native extension (being the native extension a enhancement in performance or functionality) offer the pure ruby version as the basic one, and the native extension in a similar fashion as I stated before, but maintain it as another gem. Then you put in your code a try/catch block to look for the "enhanced" version and fallback to the pure ruby one. In that way, you don't need to mess with gem specifications which could render the gems you create incompatible with the "standard" until your changes are merged and slip into mainstream. Of course, this is my point of view after been using rubygems a lot for Mongrel, creating gems also for applications and tools on Linux, Windows and FreeBSD. -- 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