' This is a confluence of several disparate factors, but i'll try to break it down: * Autotest provides a discovery process that scans for information contained within directories named 'autotest' on the load path. * Several gems (e.g. rspec, cucumber, merb) leverage this feature by providing their own lib/autotest directories. * Ruby 1.9 starts up with all gem bin/lib directories on the load path. * The autotest executable is also named 'autotest'. * So when the rubygems generated wrapper tries to load 'autotest', it hits one of the autotest directories (from another gem) before it hits the autotest executable. The load call then dies with something like: I can think of several ways to resolve this: 1. ZenTest could rename its executable or its discovery convention. 2. Ruby could ignore directories when it tries to load a file. 3. Rubygems could pass an absolute path to load. Are there any downsides to #3 ? By the time the wrapper is ready to load the executable we've already resolved which version of the gem to load so it seems like determining the absolute path is only a little more work. Are there scenarios other than this one with autotest in which a similiar conflict might occur? In other words, is it an edge case unique to autotest or might we run into other such conflicts? I'm happy to follow up on options #1 or #2 (or any others) but my initial guess was they would be harder or take longer to effect than #3. Thanks. lasitha. From lasitha.ranatunga at gmail.com Wed Feb 25 07:51:49 2009 From: lasitha.ranatunga at gmail.com (lasitha) Date: Wed, 25 Feb 2009 18:21:49 +0530 Subject: [Rubygems-developers] conflict when rubygems generated wrapper tries to load autotest executable on ruby 1.9 In-Reply-To: <268f428a0902201250u6f8e9495ja51ea0bfd08a14b1@mail.gmail.com> References: <268f428a0902201250u6f8e9495ja51ea0bfd08a14b1@mail.gmail.com> Message-ID: <268f428a0902250451j8d1755bv7457e29e3c080f84@mail.gmail.com> On Sat, Feb 21, 2009 at 2:20 AM, lasitha wrote: > Hello All, ?while trying out autotest (from ZenTest) on ruby 1.9 i ran > into a load path problem and i'd appreciate some insight on whether > rubygems might help sort it out. > > The exception is something like: > /usr/local/ruby1.9/bin/autotest:19:in `load': Is a directory - > /usr/local/ruby1.9/lib/ruby/gems/1.9.1/gems/cucumber-0.1.16/lib/autotest > (Errno::EISDIR) > ? ? ? ?from /usr/local/ruby1.9/bin/autotest:19:in `

' > > This is a confluence of several disparate factors, but i'll try to > break it down: > * Autotest provides a discovery process that scans for information > contained within directories named 'autotest' on the load path. > * Several gems (e.g. rspec, cucumber, merb) leverage this feature by > providing their own lib/autotest directories. > * Ruby 1.9 starts up with all gem bin/lib directories on the load path. > * The autotest executable is also named 'autotest'. > * So when the rubygems generated wrapper tries to load 'autotest', it > hits one of the autotest directories (from another gem) before it hits > the autotest executable. > > The load call then dies with something like: > > I can think of several ways to resolve this: > 1. ZenTest could rename its executable or its discovery convention. > 2. Ruby could ignore directories when it tries to load a file. > 3. Rubygems could pass an absolute path to load. > > Are there any downsides to #3 ? ?By the time the wrapper is ready to > load the executable we've already resolved which version of the gem to > load so it seems like determining the absolute path is only a little > more work. > > Are there scenarios other than this one with autotest in which a > similiar conflict might occur? ?In other words, is it an edge case > unique to autotest or might we run into other such conflicts? > > I'm happy to follow up on options #1 or #2 (or any others) but my > initial guess was they would be harder or take longer to effect than > #3. > This is mostly a bump, but i thought this code snippet might better describe what i'm on about: --- a/trunk/lib/rubygems/installer.rb +++ b/trunk/lib/rubygems/installer.rb @@ -433,1 +433,1 @@ -load '#{bin_file_name}' +load File.join( Gem.loaded_specs['#{@spec.name}'].full_gem_path, '#{@spec.bindir}', '#{bin_file_name}' ) That would be enough to get autotest working on ruby 1.9. Any downsides? Thanks, lasitha. From jftucker at gmail.com Thu Feb 26 06:41:07 2009 From: jftucker at gmail.com (James Tucker) Date: Thu, 26 Feb 2009 11:41:07 +0000 Subject: [Rubygems-developers] conflict when rubygems generated wrapper tries to load autotest executable on ruby 1.9 In-Reply-To: <268f428a0902250451j8d1755bv7457e29e3c080f84@mail.gmail.com> References: <268f428a0902201250u6f8e9495ja51ea0bfd08a14b1@mail.gmail.com> <268f428a0902250451j8d1755bv7457e29e3c080f84@mail.gmail.com> Message-ID: <7FDBEE9C-5A89-4B5D-BDD7-97DAB008193C@gmail.com> On 25 Feb 2009, at 12:51, lasitha wrote: > On Sat, Feb 21, 2009 at 2:20 AM, lasitha > wrote: >> Hello All, while trying out autotest (from ZenTest) on ruby 1.9 i >> ran >> into a load path problem and i'd appreciate some insight on whether >> rubygems might help sort it out. >> >> The exception is something like: >> /usr/local/ruby1.9/bin/autotest:19:in `load': Is a directory - >> /usr/local/ruby1.9/lib/ruby/gems/1.9.1/gems/cucumber-0.1.16/lib/ >> autotest >> (Errno::EISDIR) >> from /usr/local/ruby1.9/bin/autotest:19:in `

' >> >> This is a confluence of several disparate factors, but i'll try to >> break it down: >> * Autotest provides a discovery process that scans for information >> contained within directories named 'autotest' on the load path. >> * Several gems (e.g. rspec, cucumber, merb) leverage this feature by >> providing their own lib/autotest directories. >> * Ruby 1.9 starts up with all gem bin/lib directories on the load >> path. >> * The autotest executable is also named 'autotest'. >> * So when the rubygems generated wrapper tries to load 'autotest', it >> hits one of the autotest directories (from another gem) before it >> hits >> the autotest executable. >> >> The load call then dies with something like: >> >> I can think of several ways to resolve this: >> 1. ZenTest could rename its executable or its discovery convention. >> 2. Ruby could ignore directories when it tries to load a file. >> 3. Rubygems could pass an absolute path to load. >> >> Are there any downsides to #3 ? By the time the wrapper is ready to >> load the executable we've already resolved which version of the gem >> to >> load so it seems like determining the absolute path is only a little >> more work. >> >> Are there scenarios other than this one with autotest in which a >> similiar conflict might occur? In other words, is it an edge case >> unique to autotest or might we run into other such conflicts? >> >> I'm happy to follow up on options #1 or #2 (or any others) but my >> initial guess was they would be harder or take longer to effect than >> #3. >> > > This is mostly a bump, but i thought this code snippet might better > describe what i'm on about: > > --- a/trunk/lib/rubygems/installer.rb > +++ b/trunk/lib/rubygems/installer.rb > @@ -433,1 +433,1 @@ > -load '#{bin_file_name}' > +load File.join( Gem.loaded_specs['#{@spec.name}'].full_gem_path, > '#{@spec.bindir}', '#{bin_file_name}' ) > > That would be enough to get autotest working on ruby 1.9. > Any downsides? See Gem.bin_path patch here: http://rubyforge.org/tracker/index.php?func=detail&aid=24114&group_id=126&atid=577 > > > Thanks, > lasitha. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From djberg96 at gmail.com Thu Feb 26 14:14:40 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 26 Feb 2009 12:14:40 -0700 Subject: [Rubygems-developers] [Fwd: Re: Question about gems, platform and win32-api] Message-ID: <49A6EA20.4010109@gmail.com> Forwarding from Charley. Looks like there's some sort of gems/hoe interaction bug happening. Dan -------------- next part -------------- An embedded message was scrubbed... From: Charley Baker Subject: Re: Question about gems, platform and win32-api Date: Thu, 26 Feb 2009 12:10:30 -0700 Size: 8104 URL: