From djberg96 at gmail.com Thu Jan 1 09:03:44 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 01 Jan 2009 07:03:44 -0700 Subject: [Rubygems-developers] Add a Gem::Specification#licenses attribute? Message-ID: <495CCD40.7090703@gmail.com> Hi, Inspired by RF patch #11041, I've added a simple patch to allow license(s) to be specified in the gem spec. --- specification.orig 2009-01-01 06:36:29.000000000 -0700 +++ specification.rb 2009-01-01 06:42:50.000000000 -0700 @@ -302,6 +302,7 @@ @homepage, @has_rdoc, @new_platform, + @licenses, ] end @@ -346,6 +347,7 @@ spec.instance_variable_set :@has_rdoc, array[15] spec.instance_variable_set :@new_platform, array[16] spec.instance_variable_set :@platform, array[16].to_s + spec.instance_variable_set :@license, array[17] spec.instance_variable_set :@loaded, false spec @@ -1066,6 +1068,11 @@ array_attribute :authors ## + # The license(s) for the the library + + array_attribute :licenses + + ## # Files included in this gem array_attribute :files @@ -1122,6 +1129,10 @@ attribute_alias_singular :author, :authors ## + # Singular accessor for licenses + attribute_alias_singular :license, :licenses + + ## # Singular accessor for require_paths attribute_alias_singular :require_path, :require_paths As you can see, it's a straightforward accessor that, like author(s), can be used in singular or plural form (in case you want to specify more than one license). It does _not_ attempt to do any "license enforcement", nor do I even set a default license. I know licensing issues are a touchy subject, but this simple accessor seems like a reasonable minimum to me. What do you think? Regards, Dan PS - I also added and updated a couple tests, and everything still passes. From drbrain at segment7.net Fri Jan 2 17:59:31 2009 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 2 Jan 2009 14:59:31 -0800 Subject: [Rubygems-developers] Add a Gem::Specification#licenses attribute? In-Reply-To: <495CCD40.7090703@gmail.com> References: <495CCD40.7090703@gmail.com> Message-ID: On Jan 1, 2009, at 06:03 AM, Daniel Berger wrote: > Hi, > > Inspired by RF patch #11041, I've added a simple patch to allow > license(s) to be specified in the gem spec. > > --- specification.orig 2009-01-01 06:36:29.000000000 -0700 > +++ specification.rb 2009-01-01 06:42:50.000000000 -0700 > @@ -302,6 +302,7 @@ > @homepage, > @has_rdoc, > @new_platform, > + @licenses, > ] > end > > @@ -346,6 +347,7 @@ > spec.instance_variable_set :@has_rdoc, > array[15] > spec.instance_variable_set :@new_platform, > array[16] > spec.instance_variable_set :@platform, array[16].to_s > + spec.instance_variable_set :@license, > array[17] > spec.instance_variable_set :@loaded, false > > spec What's the purpose of adding them to the Marshal output? Would this information be displayed in gem list -d? What would be in this field, just the license name, or the full text? If just the name, we should add something to #validate to make sure that somebody doesn't paste in the entire GPL as this could incur a heavy bandwidth cost. If it's the full text it probably shouldn't go in the Marshal output. From Daniel.Berger at qwest.com Fri Jan 2 18:11:27 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 2 Jan 2009 17:11:27 -0600 Subject: [Rubygems-developers] Add a Gem::Specification#licensesattribute? In-Reply-To: References: <495CCD40.7090703@gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514F38@ITOMAE2KM01.AD.QINTRA.COM> Hi, > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Eric Hodel > Sent: Friday, January 02, 2009 4:00 PM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] Add a > Gem::Specification#licensesattribute? > > On Jan 1, 2009, at 06:03 AM, Daniel Berger wrote: > > Hi, > > > > Inspired by RF patch #11041, I've added a simple patch to allow > > license(s) to be specified in the gem spec. > > > > --- specification.orig 2009-01-01 06:36:29.000000000 -0700 > > +++ specification.rb 2009-01-01 06:42:50.000000000 -0700 > > @@ -302,6 +302,7 @@ > > @homepage, > > @has_rdoc, > > @new_platform, > > + @licenses, > > ] > > end > > > > @@ -346,6 +347,7 @@ > > spec.instance_variable_set :@has_rdoc, > > array[15] > > spec.instance_variable_set :@new_platform, > > array[16] > > spec.instance_variable_set :@platform, array[16].to_s > > + spec.instance_variable_set :@license, > > array[17] > > spec.instance_variable_set :@loaded, false > > > > spec > > What's the purpose of adding them to the Marshal output? I thought it was necessary for -d. No? > Would this information be displayed in gem list -d? I think it should if present, yes. > What would be in this field, just the license name, or the full text? Just the license name. > If just the name, we should add something to #validate to > make sure that somebody doesn't paste in the entire GPL as > this could incur a heavy bandwidth cost. If it's the full > text it probably shouldn't go in the Marshal output. I agree that it should only be the name and not the full text. People can lookup the full text on their own. I say limit it to, say, 64 characters, unless someone can think of a popular license with a longer name. Maybe less, even, as most of the longer license names have abbreviations. Seem reasonable? 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 ryand-ruby at zenspider.com Sat Jan 3 15:04:44 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Sat, 3 Jan 2009 12:04:44 -0800 Subject: [Rubygems-developers] Flaying rubygems In-Reply-To: <495B9BB6.3020503@qwest.com> References: <495B9BB6.3020503@qwest.com> Message-ID: <4D9767BA-2989-4075-A2A5-9F9A03290119@zenspider.com> On Dec 31, 2008, at 08:20 , Daniel Berger wrote: > Just for kicks I ran Ryan's flay against the rubygems files. Here > were the results for anyone interested. I haven't investigated > further to see how many of these warrant refactoring. Just to tease you, here is what the next version of flay can do for you (I took out #2 to reduce noise): 1) Similar code found in :defn (mass = 156) A: lib/rubygems/config_file.rb:251 B: lib/rubygems/package/tar_header.rb:178 C: lib/rubygems/source_info_cache_entry.rb:49 def ==(other) A: (self.class.===(other) and ((@backtrace == other.backtrace) and ((@benchmark == other.benchmark) and ((@bulk_threshold == other.bulk_threshold) and ((@verbose == other.verbose) and ((@update_sources == other.update_sources) and (@hash == other.hash))))))) B: (self.class.===(other) and ((@checksum == other.checksum) and ((@devmajor == other.devmajor) and ((@devminor == other.devminor) and ((@gid == other.gid) and ((@gname == other.gname) and ((@linkname == other.linkname) and ((@magic == other.magic) and ((@mode == other.mode) and ((@mtime == other.mtime) and ((@name == other.name) and ((@prefix == other.prefix) and ((@size == other.size) and ((@typeflag == other.typeflag) and ((@uid == other.uid) and ((@uname == other.uname) and (@version == other.version))))))))))))))))) C: (self.class.===(other) and ((@size == other.size) and (@source_index == other.source_index))) end 3) IDENTICAL code found in :block (mass*2 = 100) A: lib/rubygems/indexer.rb:234 B: lib/rubygems/indexer.rb:250 platform = spec.original_platform platform = Gem::Platform::RUBY if (platform.nil? or platform.empty?) [spec.name, spec.version, platform] 4) Similar code found in :if (mass = 98) A: lib/rubygems/security.rb:696 B: lib/rubygems/security.rb:708 A: if opt[:save_key] then B: if opt[:save_cert] then A: path[:key] = (opt[:save_key_path] or (opt[:output_fmt] % "private_key")) B: path[:cert] = (opt[:save_cert_path] or (opt[:output_fmt] % "public_cert")) A: File.open(path[:key], "wb") do |file| B: File.open(path[:cert], "wb") do |file| A: file.chmod(opt[:perms][:signing_key]) B: file.chmod(opt[:perms][:signing_cert]) A: file.write(key.to_pem) B: file.write(cert.to_pem) end end From djberg96 at gmail.com Sat Jan 3 22:00:51 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 03 Jan 2009 20:00:51 -0700 Subject: [Rubygems-developers] Flaying rubygems In-Reply-To: <4D9767BA-2989-4075-A2A5-9F9A03290119@zenspider.com> References: <495B9BB6.3020503@qwest.com> <4D9767BA-2989-4075-A2A5-9F9A03290119@zenspider.com> Message-ID: <49602663.2070505@gmail.com> Ryan Davis wrote: > > On Dec 31, 2008, at 08:20 , Daniel Berger wrote: > >> Just for kicks I ran Ryan's flay against the rubygems files. Here were >> the results for anyone interested. I haven't investigated further to >> see how many of these warrant refactoring. > > Just to tease you, here is what the next version of flay can do for you > (I took out #2 to reduce noise): > > 1) Similar code found in :defn (mass = 156) > A: lib/rubygems/config_file.rb:251 > B: lib/rubygems/package/tar_header.rb:178 > C: lib/rubygems/source_info_cache_entry.rb:49 > > def ==(other) > A: (self.class.===(other) and ((@backtrace == other.backtrace) and > ((@benchmark == other.benchmark) and ((@bulk_threshold == > other.bulk_threshold) and ((@verbose == other.verbose) and > ((@update_sources == other.update_sources) and (@hash == other.hash))))))) > B: (self.class.===(other) and ((@checksum == other.checksum) and > ((@devmajor == other.devmajor) and ((@devminor == other.devminor) and > ((@gid == other.gid) and ((@gname == other.gname) and ((@linkname == > other.linkname) and ((@magic == other.magic) and ((@mode == other.mode) > and ((@mtime == other.mtime) and ((@name == other.name) and ((@prefix == > other.prefix) and ((@size == other.size) and ((@typeflag == > other.typeflag) and ((@uid == other.uid) and ((@uname == other.uname) > and (@version == other.version))))))))))))))))) > C: (self.class.===(other) and ((@size == other.size) and > (@source_index == other.source_index))) > end > > 3) IDENTICAL code found in :block (mass*2 = 100) > A: lib/rubygems/indexer.rb:234 > B: lib/rubygems/indexer.rb:250 > > platform = spec.original_platform > platform = Gem::Platform::RUBY if (platform.nil? or platform.empty?) > [spec.name, spec.version, platform] > > 4) Similar code found in :if (mass = 98) > A: lib/rubygems/security.rb:696 > B: lib/rubygems/security.rb:708 > > A: if opt[:save_key] then > B: if opt[:save_cert] then > A: path[:key] = (opt[:save_key_path] or (opt[:output_fmt] % > "private_key")) > B: path[:cert] = (opt[:save_cert_path] or (opt[:output_fmt] % > "public_cert")) > A: File.open(path[:key], "wb") do |file| > B: File.open(path[:cert], "wb") do |file| > A: file.chmod(opt[:perms][:signing_key]) > B: file.chmod(opt[:perms][:signing_cert]) > A: file.write(key.to_pem) > B: file.write(cert.to_pem) > end > end That definitely looks nicer Ryan. I look forward to the next version. :) Regards, Dan PS - Have you flayed MRI yet? From thewoolleyman at gmail.com Mon Jan 5 04:46:09 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 5 Jan 2009 02:46:09 -0700 Subject: [Rubygems-developers] rubygems passing ARGV to extension builders breaks usage via API In-Reply-To: References: <1F7BEA82-7506-47F4-A046-179BFFF93301@segment7.net> Message-ID: On Fri, Dec 12, 2008 at 6:12 PM, Chad Woolley wrote: > On Thu, Sep 18, 2008 at 4:45 PM, Eric Hodel wrote: >> I like this proposal. Gem::Command could handle this, and have an accessor >> for something like "extra argv". I don't want to try to put this in for the >> next release though. > > Bug opened: > > http://rubyforge.org/tracker/index.php?func=detail&aid=23210&group_id=126&atid=575 I just committed a fix for this in revision 1987. -- Chad From djberg96 at gmail.com Mon Jan 5 06:28:02 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Mon, 05 Jan 2009 04:28:02 -0700 Subject: [Rubygems-developers] rubygems passing ARGV to extension builders breaks usage via API In-Reply-To: References: <1F7BEA82-7506-47F4-A046-179BFFF93301@segment7.net> Message-ID: <4961EEC2.50909@gmail.com> Chad Woolley wrote: > On Fri, Dec 12, 2008 at 6:12 PM, Chad Woolley wrote: >> On Thu, Sep 18, 2008 at 4:45 PM, Eric Hodel wrote: >>> I like this proposal. Gem::Command could handle this, and have an accessor >>> for something like "extra argv". I don't want to try to put this in for the >>> next release though. >> Bug opened: >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=23210&group_id=126&atid=575 > > I just committed a fix for this in revision 1987. Excellent! However, I'm getting extremely concerned about the seriously outdated documentation on rubygems.org, as changes like this may end up confusing the end users. In fact, I think rubygems.org is nearing the 'actively harmful' stage it's so old. To wit: it still has the old 'require_gem' method out there. I would even go so far as to say that we shouldn't put out another version of rubygems until we get access to rubygems.org and do some serious updating. I'm still waiting to hear back from Chad Fowler on getting access to the box. Regards, Dan From Daniel.Berger at qwest.com Wed Jan 14 16:17:58 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 14 Jan 2009 15:17:58 -0600 Subject: [Rubygems-developers] The deprecation of autorequire Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> Hi, I'm curious as to why Gem#gem doesn't autorequire the library: require 'rubygems' gem 'ptools' require 'ptools' # Must I do this? p File.which('ruby') If I leave out the 'require' on line 3 it doesn't work. I checked rubygems.rb and the $LOAD_PATH definitely includes the path where the gems are stored, but as far as I can tell the Gem.activate method does _not_ automatically call require (or gem_original_require) on the gem specified. Why not? I realize in most cases you can just use reqular 'require', but that doesn't work in all cases. For example, if I want to use Test::Unit 2.x instead of the one that ships with the stdlib, I must use the above approach. This isn't a major deal. It's just a minor nuisance really, but I was curious. 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 Daniel.Berger at qwest.com Wed Jan 14 16:36:12 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 14 Jan 2009 15:36:12 -0600 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514F86@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Berger, Daniel > Sent: Wednesday, January 14, 2009 2:18 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] The deprecation of autorequire > > Hi, > > I'm curious as to why Gem#gem doesn't autorequire the library: > > require 'rubygems' > gem 'ptools' > require 'ptools' # Must I do this? > p File.which('ruby') > > If I leave out the 'require' on line 3 it doesn't work. > > I checked rubygems.rb and the $LOAD_PATH definitely includes > the path where the gems are stored, but as far as I can tell > the Gem.activate method does _not_ automatically call require > (or gem_original_require) on the gem specified. > > Why not? > > I realize in most cases you can just use reqular 'require', > but that doesn't work in all cases. For example, if I want to > use Test::Unit 2.x instead of the one that ships with the > stdlib, I must use the above approach. > > This isn't a major deal. It's just a minor nuisance really, > but I was curious. Here's a couple of approaches we could take: The first one does a simple require if the autorequire spec is defined: --- rubygems.orig Wed Jan 14 13:52:14 2009 +++ rubygems.rb Wed Jan 14 14:32:42 2009 @@ -202,6 +202,8 @@ $LOAD_PATH.unshift(*require_paths) end + require spec.autorequire if spec.autorequire + return true end The second one attempts to require the gem, but handles a load failure by issuing a warning and moving on: --- rubygems.orig Wed Jan 14 13:52:14 2009 +++ rubygems.rb Wed Jan 14 14:30:22 2009 @@ -202,6 +202,12 @@ $LOAD_PATH.unshift(*require_paths) end + begin + require spec.autorequire if spec.autorequire + rescue LoadError + warn "autorequire for #{gem.name} failed - ignoring" + end + return true end What do you think? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From luislavena at gmail.com Wed Jan 14 20:29:54 2009 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 14 Jan 2009 23:29:54 -0200 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> On Wed, Jan 14, 2009 at 7:17 PM, Berger, Daniel wrote: > Hi, > > I'm curious as to why Gem#gem doesn't autorequire the library: > > require 'rubygems' > gem 'ptools' > require 'ptools' # Must I do this? > p File.which('ruby') > > If I leave out the 'require' on line 3 it doesn't work. > > I checked rubygems.rb and the $LOAD_PATH definitely includes the path > where the gems are stored, but as far as I can tell the Gem.activate > method does _not_ automatically call require (or gem_original_require) > on the gem specified. > > Why not? > > I realize in most cases you can just use reqular 'require', but that > doesn't work in all cases. For example, if I want to use Test::Unit 2.x > instead of the one that ships with the stdlib, I must use the above > approach. > > This isn't a major deal. It's just a minor nuisance really, but I was > curious. > > Regards, > > Dan > AFAIK autorequire has been deprecated. A good reason will be that under certain circumstances you don't want to load the whole library of a gem. gem 'rspec', '~> 1.1.10' # allow me to have a code locked to a specific mayor.minor safe versions require 'spec/expectations' with autorequire, the above example would have included 'spec' which is big and offer way more stuff that I wanted to integrate (I only wanted the expectations). As you mention, you need to call #gem to indicate you want the gem version over the bundled one. The same will apply to Rake, which is bundled with 1.9: require 'rubygems' gem 'rake' require 'rake' unless the stdlib cases, you can simply everything to just: require 'rubygems' require 'ptools' And will work, no need to indicate the gem activation at all. Did I miss something? -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From djberg96 at gmail.com Wed Jan 14 20:35:32 2009 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 14 Jan 2009 18:35:32 -0700 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> Message-ID: <496E92E4.2030400@gmail.com> Luis Lavena wrote: > AFAIK autorequire has been deprecated. > > A good reason will be that under certain circumstances you don't want > to load the whole library of a gem. > > gem 'rspec', '~> 1.1.10' # allow me to have a code locked to a > specific mayor.minor safe versions > require 'spec/expectations' > > with autorequire, the above example would have included 'spec' which > is big and offer way more stuff that I wanted to integrate (I only > wanted the expectations). > > As you mention, you need to call #gem to indicate you want the gem > version over the bundled one. > > The same will apply to Rake, which is bundled with 1.9: > > require 'rubygems' > gem 'rake' > require 'rake' > > unless the stdlib cases, you can simply everything to just: > > require 'rubygems' > require 'ptools' > > And will work, no need to indicate the gem activation at all. > > Did I miss something? No, for that example you're correct. I just thought that, as more of the stdlib is bundled separately as a gem it may become more of a hassle to have to do 'gem' + 'require'. I thought it would still be useful for those authors, but it seems to cause more confusion than it's worth. It can always be revisited/revived again at a later day if necessary. Regards, Dan From jim.weirich at gmail.com Thu Jan 15 00:08:37 2009 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 15 Jan 2009 00:08:37 -0500 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <496E92E4.2030400@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> <496E92E4.2030400@gmail.com> Message-ID: <716A9EBC-0BA8-44C5-8B47-8313A4795943@gmail.com> On Jan 14, 2009, at 8:35 PM, Daniel Berger wrote: > No, for that example you're correct. > > I just thought that, as more of the stdlib is bundled separately as > a gem it may become more of a hassle to have to do 'gem' + > 'require'. I thought it would still be useful for those authors, but > it seems to cause more confusion than it's worth. > > It can always be revisited/revived again at a later day if necessary. The rule of thumb is: Always use a 'require' command. Ideally, each file requiring the functionality should independently do the require (or require a file that does all the common requires). A result of this is that require commands are often spread throughout the program. Only use a 'gem' command if you want something other than the latest installed version of a gem. You application should arrange to invoke the gem command early in the program, after 'rubygems' has been required, but before any other requires have run. Autorequire could cause subtle bugs where files get auto-required and loaded before a subsequent 'gem' command has a chance to specify what version of a gem should be used. It was because of these (very real, but subtle) problems that autorequire was deprecated.[1] -- -- Jim Weirich -- jim.weirich at gmail.com [1] Autorequire also had the harmless but annoying feature that it could cause require to return false even when the file was actually loaded. Nobody EVER checks the return value of require in a program, but the return value is displayed in irb, causing a number of people to panic (thinking that their file wasn't loaded). From thewoolleyman at gmail.com Thu Jan 15 00:17:17 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 14 Jan 2009 22:17:17 -0700 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <716A9EBC-0BA8-44C5-8B47-8313A4795943@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> <496E92E4.2030400@gmail.com> <716A9EBC-0BA8-44C5-8B47-8313A4795943@gmail.com> Message-ID: On Wed, Jan 14, 2009 at 10:08 PM, Jim Weirich wrote: > Only use a 'gem' command if you want something other than the latest > installed version of a gem. You application should arrange to invoke the > gem command early in the program, after 'rubygems' has been required, but > before any other requires have run. We use GemInstaller's 'autogem' function to accomplish this via /config/preinitializer.rb in all our Rails apps: http://geminstaller.rubyforge.org/documentation/tutorials.html#using_the_autogem_option_to_automatically_require_gems This works very well for us, and I believe Rails' config.gems can do the same thing (except for Rails itself, would cause the universe to implode) -- Chad From halostatue at gmail.com Thu Jan 15 09:31:32 2009 From: halostatue at gmail.com (Austin Ziegler) Date: Thu, 15 Jan 2009 09:31:32 -0500 Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> <496E92E4.2030400@gmail.com> <716A9EBC-0BA8-44C5-8B47-8313A4795943@gmail.com> Message-ID: <9e7db9110901150631u4745bfb6l2a82888042fb3cf0@mail.gmail.com> On Thu, Jan 15, 2009 at 12:17 AM, Chad Woolley wrote: > On Wed, Jan 14, 2009 at 10:08 PM, Jim Weirich wrote: >> Only use a 'gem' command if you want something other than the latest >> installed version of a gem. You application should arrange to invoke the >> gem command early in the program, after 'rubygems' has been required, but >> before any other requires have run. > > We use GemInstaller's 'autogem' function to accomplish this via > /config/preinitializer.rb in all our Rails apps: > http://geminstaller.rubyforge.org/documentation/tutorials.html#using_the_autogem_option_to_automatically_require_gems > > This works very well for us, and I believe Rails' config.gems can do > the same thing (except for Rails itself, would cause the universe to > implode) Some of this might be helped if RubyGems provided a "default require" piece of metadata that could be queried about a gem. One of the complaints that I've heard?and don't really have a fix for?is that the names of gems and what you require are different. When I was working on PDF::Writer, for example, it was: gem 'pdf-writer', '=1.1.8' require 'pdf/writer' Now, those two are close enough, but it wasn't "require 'pdf-writer'", which is what some people apparently expect. (I'm not sure why; maybe it was the early autorequire.) If we had a way of querying a gem for it's "full require" or "default require", it might help at least with exploration of a gem. One way that we could do this is to make it so that the "gem" command returns a read-only copy of the spec: pdf_writer = gem 'pdf-writer', '=1.1.8' require pdf_writer.default_require Or something like that. -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 hgs at dmu.ac.uk Thu Jan 15 10:37:41 2009 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 15 Jan 2009 15:37:41 +0000 (GMT) Subject: [Rubygems-developers] The deprecation of autorequire In-Reply-To: <9e7db9110901150631u4745bfb6l2a82888042fb3cf0@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514F84@ITOMAE2KM01.AD.QINTRA.COM> <71166b3b0901141729g8e5bd11u7ba09a346dbb11c2@mail.gmail.com> <496E92E4.2030400@gmail.com> <716A9EBC-0BA8-44C5-8B47-8313A4795943@gmail.com> <9e7db9110901150631u4745bfb6l2a82888042fb3cf0@mail.gmail.com> Message-ID: On Thu, 15 Jan 2009, Austin Ziegler wrote: > On Thu, Jan 15, 2009 at 12:17 AM, Chad Woolley wrote: > Some of this might be helped if RubyGems provided a "default require" > piece of metadata that could be queried about a gem. One of the > complaints that I've heard?and don't really have a fix for?is that the > names of gems and what you require are different. When I was working > on PDF::Writer, for example, it was: > > gem 'pdf-writer', '=1.1.8' > require 'pdf/writer' > [...] > If we had a way of querying a gem for it's "full require" or "default > require", it might help at least with exploration of a gem. One way > that we could do this is to make it so that the "gem" command returns > a read-only copy of the spec: > > pdf_writer = gem 'pdf-writer', '=1.1.8' > require pdf_writer.default_require > > Or something like that. Agreed. I was about to write "why not make that gem command do the require?", but there are times when you only want parts of a package distributed as a gem: Facets had core parts, etc. So maybe this metadata should be a hash, one key being :complete, and the values being things it would make sense to pass to require, by design. Thus it would help further with exploration of a gem, the "software archeology". > -austin Hugh From han.holl at tietoenator.com Mon Jan 19 10:47:32 2009 From: han.holl at tietoenator.com (Han Holl) Date: Mon, 19 Jan 2009 16:47:32 +0100 Subject: [Rubygems-developers] How to rebuild a gem Message-ID: <200901191647.32629.han.holl@tietoenator.com> Hi, I want to install a gem, but it doesn't build on my platform. I fix the C-source, and submit a patch to the owner. But I want to go on, and not wait for the maintainer to apply my patch. How can I rebuild the gem, and install. I tried to untar the original gem, untar data.tar.gz, drop in my .c file, and tar it up again, but this doesn't work. I get an error message the some directory already exists. I rm -rf'ed everything in the gem directory tree that belonged to this gem, but still the same error. Is there a way to do this ? Cheers, Han Holl PS It may be relevant that I try this on a ruby-1.9.1 in /usr/local/bin, with ruby-1.8.6 in /usr/bin. From jftucker at gmail.com Mon Jan 19 11:24:20 2009 From: jftucker at gmail.com (James Tucker) Date: Mon, 19 Jan 2009 16:24:20 +0000 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901191647.32629.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> Message-ID: <950686B1-20A0-4D44-A4D3-25068FC9245A@gmail.com> I built a horrible tool called gem repackager, which works well for this on win32. On *nix it often requires root to run, but that depends on the permission of your gem tree. It needs a lot of love, but it worked great for the time when I needed it for win32, and should work on *nix systems too. I'm accepting patches / improvements as they come about, it's really had very little time put into it, and is now very old. Later this month, I should get around to putting it into a git repo, giving it some tests, and a new set of rake tasks, and push it as a gem to the libraggi project, which is where most of this toy / util stuff is gunna live. http://gem-repackager.rubyforge.org/svn/ Finally, feel free to ping me off the list with any questions you have, if you feel it's appropriate. HTH On 19 Jan 2009, at 15:47, Han Holl wrote: > > Hi, > > I want to install a gem, but it doesn't build on my platform. > I fix the C-source, and submit a patch to the owner. > > But I want to go on, and not wait for the maintainer to apply my > patch. > How can I rebuild the gem, and install. > > I tried to untar the original gem, untar data.tar.gz, drop in my .c > file, and > tar it up again, but this doesn't work. I get an error message the > some > directory already exists. I rm -rf'ed everything in the gem > directory tree > that belonged to this gem, but still the same error. > > Is there a way to do this ? > > Cheers, > > Han Holl > > PS It may be relevant that I try this on a ruby-1.9.1 in /usr/local/ > bin, with > ruby-1.8.6 in /usr/bin. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From ryand-ruby at zenspider.com Mon Jan 19 15:44:14 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Mon, 19 Jan 2009 12:44:14 -0800 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901191647.32629.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> Message-ID: <703E528C-F8B9-4075-93DC-E43AAB082B9E@zenspider.com> On Jan 19, 2009, at 07:47 , Han Holl wrote: > I want to install a gem, but it doesn't build on my platform. > I fix the C-source, and submit a patch to the owner. > > But I want to go on, and not wait for the maintainer to apply my > patch. > How can I rebuild the gem, and install. > > I tried to untar the original gem, untar data.tar.gz, drop in my .c > file, and > tar it up again, but this doesn't work. I get an error message the > some > directory already exists. I rm -rf'ed everything in the gem > directory tree > that belonged to this gem, but still the same error. > > Is there a way to do this ? generally a blown build just sits there with a build log file so you can diagnose the problem. Do a regular install, let it blow up, cd into the gem dir, add your files/patches needed, and finish the build (make/rake as appropriate, depending on how the gem extension is packaged up). It builds in the same location it is going to run from, so you should be good. From han.holl at tietoenator.com Tue Jan 20 05:26:45 2009 From: han.holl at tietoenator.com (Han Holl) Date: Tue, 20 Jan 2009 11:26:45 +0100 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <703E528C-F8B9-4075-93DC-E43AAB082B9E@zenspider.com> References: <200901191647.32629.han.holl@tietoenator.com> <703E528C-F8B9-4075-93DC-E43AAB082B9E@zenspider.com> Message-ID: <200901201126.45291.han.holl@tietoenator.com> On Monday 19 January 2009, Ryan Davis wrote: > generally a blown build just sits there with a build log file so you > can diagnose the problem. Do a regular install, let it blow up, cd > into the gem dir, add your files/patches needed, and finish the build > (make/rake as appropriate, depending on how the gem extension is > packaged up). It builds in the same location it is going to run from, > so you should be good. Yes, I can continue with make (in the ext directory), but after that I won't have an installed gem. That's what I need for dependencies, maybe for installed binaries etc. I need to patch/rebuild/repackage the original gem somehow. Cheers, Han Holl From thewoolleyman at gmail.com Tue Jan 20 10:24:01 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 20 Jan 2009 08:24:01 -0700 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901201126.45291.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <703E528C-F8B9-4075-93DC-E43AAB082B9E@zenspider.com> <200901201126.45291.han.holl@tietoenator.com> Message-ID: On Tue, Jan 20, 2009 at 3:26 AM, Han Holl wrote: > Yes, I can continue with make (in the ext directory), but after that I won't > have an installed gem. That's what I need for dependencies, maybe for > installed binaries etc. > I need to patch/rebuild/repackage the original gem somehow. You can figure out the dependencies with 'gem dependencies'. Here is also a way to automatically install missing dependencies: http://geminstaller.rubyforge.org/documentation/documentation.html#fix_dependencies_config_property -- Chad From ryand-ruby at zenspider.com Tue Jan 20 20:48:25 2009 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 20 Jan 2009 17:48:25 -0800 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901201126.45291.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <703E528C-F8B9-4075-93DC-E43AAB082B9E@zenspider.com> <200901201126.45291.han.holl@tietoenator.com> Message-ID: <8B558314-0D2C-4F92-A9E4-2BFE30B31983@zenspider.com> On Jan 20, 2009, at 02:26 , Han Holl wrote: > On Monday 19 January 2009, Ryan Davis wrote: > >> generally a blown build just sits there with a build log file so you >> can diagnose the problem. Do a regular install, let it blow up, cd >> into the gem dir, add your files/patches needed, and finish the build >> (make/rake as appropriate, depending on how the gem extension is >> packaged up). It builds in the same location it is going to run from, >> so you should be good. > > Yes, I can continue with make (in the ext directory), but after that > I won't > have an installed gem. That's what I need for dependencies, maybe for > installed binaries etc. no, you'll have an installed gem at that point. It is building IN the install location, so once it is built, it's good to go. > I need to patch/rebuild/repackage the original gem somehow. From han.holl at tietoenator.com Wed Jan 21 05:03:52 2009 From: han.holl at tietoenator.com (Han Holl) Date: Wed, 21 Jan 2009 11:03:52 +0100 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <8B558314-0D2C-4F92-A9E4-2BFE30B31983@zenspider.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901201126.45291.han.holl@tietoenator.com> <8B558314-0D2C-4F92-A9E4-2BFE30B31983@zenspider.com> Message-ID: <200901211103.53048.han.holl@tietoenator.com> On Wednesday 21 January 2009, Ryan Davis wrote: > > Yes, I can continue with make (in the ext directory), but after that > > I won't > > have an installed gem. That's what I need for dependencies, maybe for > > installed binaries etc. > > no, you'll have an installed gem at that point. It is building IN the > install location, so once it is built, it's good to go. > No. For instance, there is no .gemspec file in the specifications directory, and it's not easy to create one. Han From drbrain at segment7.net Wed Jan 21 17:50:28 2009 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 21 Jan 2009 14:50:28 -0800 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901191647.32629.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> Message-ID: <73E3854F-B52E-4A16-91BE-205326ECEE4C@segment7.net> On Jan 19, 2009, at 07:47 AM, Han Holl wrote: > I want to install a gem, but it doesn't build on my platform. > I fix the C-source, and submit a patch to the owner. > > But I want to go on, and not wait for the maintainer to apply my > patch. > How can I rebuild the gem, and install. > > I tried to untar the original gem, untar data.tar.gz, drop in my .c > file, and > tar it up again, but this doesn't work. I get an error message the > some > directory already exists. I rm -rf'ed everything in the gem > directory tree > that belonged to this gem, but still the same error. > > Is there a way to do this ? $ gem install thegem # => it fails and gives you a path to gem_make.out $ cd /to/the/path $ patch < /path/to/your/patch $ make # or whatever is appropriate for `gem spec thegem | grep -A2 extension` From drbrain at segment7.net Wed Jan 21 17:52:58 2009 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 21 Jan 2009 14:52:58 -0800 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901211103.53048.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901201126.45291.han.holl@tietoenator.com> <8B558314-0D2C-4F92-A9E4-2BFE30B31983@zenspider.com> <200901211103.53048.han.holl@tietoenator.com> Message-ID: On Jan 21, 2009, at 02:03 AM, Han Holl wrote: > On Wednesday 21 January 2009, Ryan Davis wrote: >>> Yes, I can continue with make (in the ext directory), but after that >>> I won't >>> have an installed gem. That's what I need for dependencies, maybe >>> for >>> installed binaries etc. >> >> no, you'll have an installed gem at that point. It is building IN the >> install location, so once it is built, it's good to go. >> > No. For instance, there is no .gemspec file in the specifications > directory, > and it's not easy to create one. You need to run `gem install` first. It'll put the files in all the right places. You didn't read Ryan's original mail where he explained this: On Jan 19, 2009, at 12:44 PM, Ryan Davis wrote: > generally a blown build just sits there with a build log file so you > can diagnose the problem. Do a regular install, let it blow up, cd > into the gem dir, add your files/patches needed, and finish the > build (make/rake as appropriate, depending on how the gem extension > is packaged up). It builds in the same location it is going to run > from, so you should be good. From han.holl at tietoenator.com Thu Jan 22 04:32:29 2009 From: han.holl at tietoenator.com (Han Holl) Date: Thu, 22 Jan 2009 10:32:29 +0100 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: References: <200901191647.32629.han.holl@tietoenator.com> <200901211103.53048.han.holl@tietoenator.com> Message-ID: <200901221032.29269.han.holl@tietoenator.com> On Wednesday 21 January 2009, Eric Hodel wrote: > > You need to run `gem install` first. It'll put the files in all the > right places. You didn't read Ryan's original mail where he explained > this: > I did read his mail, and yours, and thing just are different for me. Maybe there is something ont quite alright with the gem I'm trying to install ? Here's the complete history. New ruby-1.9.1 install in /usr/local/bin. zernez:/usr/local/lib/ruby/gems/1.9.1> find . . ./gems ./cache ./doc ./specifications zernez:/usr/local/lib/ruby/gems/1.9.1> gem install pg Building native extensions. This could take a while... ERROR: Error installing pg: ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb install pg checking for main() in -lpq... yes checking for libpq-fe.h... yes checking for libpq/libpq-fs.h... yes checking for PQconnectionUsedPassword()... no checking for PQisthreadsafe()... no checking for PQprepare()... yes checking for PQexecParams()... yes checking for PQescapeString()... yes checking for PQescapeStringConn()... yes checking for lo_create()... yes checking for pg_encoding_to_char()... yes checking for PQsetClientEncoding()... yes creating Makefile make gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o pg.o -c pg.c In file included from pg.h:6, from pg.c:15: /usr/local/include/ruby-1.9.1/ruby/backward/rubyio.h:2:2: warning: #warning use "ruby/io.h" instead of "rubyio.h" pg.c: In function ?parse_connect_args?: pg.c:233: warning: unused variable ?error? pg.c:231: warning: unused variable ?conn? pg.c: In function ?pgconn_exec?: pg.c:960: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_prepare?: pg.c:1065: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_exec_prepared?: pg.c:1151: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_send_query?: pg.c:1491: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_send_prepare?: pg.c:1595: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_send_query_prepared?: pg.c:1684: error: ?struct RArray? has no member named ?len? pg.c: In function ?pgconn_trace?: pg.c:2161: warning: implicit declaration of function ?dup? pg.c:2141: warning: unused variable ?fp? make: *** [pg.o] Error 1 Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/gems/pg-0.7.9.2008.10.13 for inspection. Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/pg-0.7.9.2008.10.13/ext/gem_make.out zsh: exit 1 gem install pg zernez:/usr/local/lib/ruby/gems/1.9.1> cd gems/pg-0.7.9.2008.10.13/ext zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> cp /home/han/pg.c . zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> make gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o pg.o -c pg.c In file included from pg.h:6, from pg.c:15: /usr/local/include/ruby-1.9.1/ruby/backward/rubyio.h:2:2: warning: #warning use "ruby/io.h" instead of "rubyio.h" pg.c: In function ?parse_connect_args?: pg.c:233: warning: unused variable ?error? pg.c:231: warning: unused variable ?conn? pg.c: In function ?pgconn_trace?: pg.c:2161: warning: implicit declaration of function ?dup? pg.c:2141: warning: unused variable ?fp? pg.c: At top level: pg.c:88: warning: ?value_as_cstring? defined but not used gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o compat.o -c compat.c gcc -shared -o pg.so pg.o compat.o -L. -L/usr/local/lib -Wl,-R/usr/local/lib -L/usr/lib64 -Wl,-R/usr/lib64 -L. -rdynamic -Wl,-export-dynamic -lpq -lpthread -lrt -ldl -lcrypt -lm -lc zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> cd ../../.. zernez:/usr/local/lib/ruby/gems/1.9.1> find . . ./gems ./gems/pg-0.7.9.2008.10.13 ./gems/pg-0.7.9.2008.10.13/sample ./gems/pg-0.7.9.2008.10.13/sample/test1.rb ./gems/pg-0.7.9.2008.10.13/sample/test4.rb ./gems/pg-0.7.9.2008.10.13/sample/test2.rb ./gems/pg-0.7.9.2008.10.13/sample/psqlHelp.rb ./gems/pg-0.7.9.2008.10.13/sample/losample.rb ./gems/pg-0.7.9.2008.10.13/sample/psql.rb ./gems/pg-0.7.9.2008.10.13/spec ./gems/pg-0.7.9.2008.10.13/spec/data ./gems/pg-0.7.9.2008.10.13/spec/data/expected_trace.out ./gems/pg-0.7.9.2008.10.13/spec/data/random_binary_data ./gems/pg-0.7.9.2008.10.13/spec/pgresult_spec.rb ./gems/pg-0.7.9.2008.10.13/spec/pgconn_spec.rb ./gems/pg-0.7.9.2008.10.13/doc ./gems/pg-0.7.9.2008.10.13/doc/postgres.jp.html ./gems/pg-0.7.9.2008.10.13/doc/postgres.html ./gems/pg-0.7.9.2008.10.13/ext ./gems/pg-0.7.9.2008.10.13/ext/gem_make.out ./gems/pg-0.7.9.2008.10.13/ext/compat.o ./gems/pg-0.7.9.2008.10.13/ext/extconf.rb ./gems/pg-0.7.9.2008.10.13/ext/mkmf.log ./gems/pg-0.7.9.2008.10.13/ext/pg.so ./gems/pg-0.7.9.2008.10.13/ext/Makefile ./gems/pg-0.7.9.2008.10.13/ext/pg.c ./gems/pg-0.7.9.2008.10.13/ext/mkrf_config.rb ./gems/pg-0.7.9.2008.10.13/ext/pg.h ./gems/pg-0.7.9.2008.10.13/ext/pg.o ./gems/pg-0.7.9.2008.10.13/ext/compat.c ./gems/pg-0.7.9.2008.10.13/ext/compat.h ./cache ./cache/pg-0.7.9.2008.10.13.gem ./doc ./specifications zernez:/usr/local/lib/ruby/gems/1.9.1> gem list *** LOCAL GEMS *** zernez:/usr/local/lib/ruby/gems/1.9.1> As you can see I end up with _no_ installed gems. Most critically, there is no .gemspec file in ./specification, and there isn't one in the the original archive either. Am I doing something wrong here ? Cheers, Han Holl PS I've attached the transcript as well, because mail programs may do nasty thing with some of the lines here. -------------- next part -------------- A non-text attachment was scrubbed... Name: transcript Type: application/octet-stream Size: 5841 bytes Desc: not available URL: From luislavena at gmail.com Thu Jan 22 06:23:08 2009 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 22 Jan 2009 09:23:08 -0200 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901221032.29269.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901211103.53048.han.holl@tietoenator.com> <200901221032.29269.han.holl@tietoenator.com> Message-ID: <71166b3b0901220323m2ea26980l1b12ca357b387712@mail.gmail.com> On Thu, Jan 22, 2009 at 7:32 AM, Han Holl wrote: > On Wednesday 21 January 2009, Eric Hodel wrote: >> >> You need to run `gem install` first. It'll put the files in all the >> right places. You didn't read Ryan's original mail where he explained >> this: >> > I did read his mail, and yours, and thing just are different for me. Maybe > there is something ont quite alright with the gem I'm trying to install ? > Here's the complete history. New ruby-1.9.1 install in /usr/local/bin. > > zernez:/usr/local/lib/ruby/gems/1.9.1> find . > . > ./gems > ./cache > ./doc > ./specifications > zernez:/usr/local/lib/ruby/gems/1.9.1> gem install pg > Building native extensions. This could take a while... > ERROR: Error installing pg: > ERROR: Failed to build gem native extension. > > /usr/local/bin/ruby extconf.rb install pg > checking for main() in -lpq... yes > checking for libpq-fe.h... yes > checking for libpq/libpq-fs.h... yes > checking for PQconnectionUsedPassword()... no > checking for PQisthreadsafe()... no > checking for PQprepare()... yes > checking for PQexecParams()... yes > checking for PQescapeString()... yes > checking for PQescapeStringConn()... yes > checking for lo_create()... yes > checking for pg_encoding_to_char()... yes > checking for PQsetClientEncoding()... yes > creating Makefile > > make > gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o > pg.o -c pg.c > In file included from pg.h:6, > from pg.c:15: > /usr/local/include/ruby-1.9.1/ruby/backward/rubyio.h:2:2: warning: #warning > use "ruby/io.h" instead of "rubyio.h" > pg.c: In function 'parse_connect_args': > pg.c:233: warning: unused variable 'error' > pg.c:231: warning: unused variable 'conn' > pg.c: In function 'pgconn_exec': > pg.c:960: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_prepare': > pg.c:1065: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_exec_prepared': > pg.c:1151: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_send_query': > pg.c:1491: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_send_prepare': > pg.c:1595: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_send_query_prepared': > pg.c:1684: error: 'struct RArray' has no member named 'len' > pg.c: In function 'pgconn_trace': > pg.c:2161: warning: implicit declaration of function 'dup' > pg.c:2141: warning: unused variable 'fp' > make: *** [pg.o] Error 1 > > > Gem files will remain installed > in /usr/local/lib/ruby/gems/1.9.1/gems/pg-0.7.9.2008.10.13 for inspection. > Results logged > to /usr/local/lib/ruby/gems/1.9.1/gems/pg-0.7.9.2008.10.13/ext/gem_make.out > zsh: exit 1 gem install pg > zernez:/usr/local/lib/ruby/gems/1.9.1> cd gems/pg-0.7.9.2008.10.13/ext > zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> cp /home/han/pg.c . > zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> make > gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o > pg.o -c pg.c > In file included from pg.h:6, > from pg.c:15: > /usr/local/include/ruby-1.9.1/ruby/backward/rubyio.h:2:2: warning: #warning > use "ruby/io.h" instead of "rubyio.h" > pg.c: In function 'parse_connect_args': > pg.c:233: warning: unused variable 'error' > pg.c:231: warning: unused variable 'conn' > pg.c: In function 'pgconn_trace': > pg.c:2161: warning: implicit declaration of function 'dup' > pg.c:2141: warning: unused variable 'fp' > pg.c: At top level: > pg.c:88: warning: 'value_as_cstring' defined but not used > gcc -I. -I/usr/local/include/ruby-1.9.1/x86_64-linux -I/usr/local/include/ruby-1.9.1/ruby/backward -I/usr/local/include/ruby-1.9.1 -I. -DHAVE_LIBPQ_FE_H -DHAVE_LIBPQ_LIBPQ_FS_H -DHAVE_PQPREPARE -DHAVE_PQEXECPARAMS -DHAVE_PQESCAPESTRING -DHAVE_PQESCAPESTRINGCONN -DHAVE_LO_CREATE -DHAVE_PG_ENCODING_TO_CHAR -DHAVE_PQSETCLIENTENCODING -I/usr/include -fPIC -O2 -g -Wall -Wno-parentheses -o > compat.o -c compat.c > gcc -shared -o pg.so pg.o > compat.o -L. -L/usr/local/lib -Wl,-R/usr/local/lib -L/usr/lib64 -Wl,-R/usr/lib64 -L. -rdynamic -Wl,-export-dynamic -lpq -lpthread -lrt -ldl -lcrypt -lm -lc > zernez:.../1.9.1/gems/pg-0.7.9.2008.10.13/ext> cd ../../.. > zernez:/usr/local/lib/ruby/gems/1.9.1> find . > . > ./gems > ./gems/pg-0.7.9.2008.10.13 > ./gems/pg-0.7.9.2008.10.13/sample > ./gems/pg-0.7.9.2008.10.13/sample/test1.rb > ./gems/pg-0.7.9.2008.10.13/sample/test4.rb > ./gems/pg-0.7.9.2008.10.13/sample/test2.rb > ./gems/pg-0.7.9.2008.10.13/sample/psqlHelp.rb > ./gems/pg-0.7.9.2008.10.13/sample/losample.rb > ./gems/pg-0.7.9.2008.10.13/sample/psql.rb > ./gems/pg-0.7.9.2008.10.13/spec > ./gems/pg-0.7.9.2008.10.13/spec/data > ./gems/pg-0.7.9.2008.10.13/spec/data/expected_trace.out > ./gems/pg-0.7.9.2008.10.13/spec/data/random_binary_data > ./gems/pg-0.7.9.2008.10.13/spec/pgresult_spec.rb > ./gems/pg-0.7.9.2008.10.13/spec/pgconn_spec.rb > ./gems/pg-0.7.9.2008.10.13/doc > ./gems/pg-0.7.9.2008.10.13/doc/postgres.jp.html > ./gems/pg-0.7.9.2008.10.13/doc/postgres.html > ./gems/pg-0.7.9.2008.10.13/ext > ./gems/pg-0.7.9.2008.10.13/ext/gem_make.out > ./gems/pg-0.7.9.2008.10.13/ext/compat.o > ./gems/pg-0.7.9.2008.10.13/ext/extconf.rb > ./gems/pg-0.7.9.2008.10.13/ext/mkmf.log > ./gems/pg-0.7.9.2008.10.13/ext/pg.so > ./gems/pg-0.7.9.2008.10.13/ext/Makefile > ./gems/pg-0.7.9.2008.10.13/ext/pg.c > ./gems/pg-0.7.9.2008.10.13/ext/mkrf_config.rb > ./gems/pg-0.7.9.2008.10.13/ext/pg.h > ./gems/pg-0.7.9.2008.10.13/ext/pg.o > ./gems/pg-0.7.9.2008.10.13/ext/compat.c > ./gems/pg-0.7.9.2008.10.13/ext/compat.h > ./cache > ./cache/pg-0.7.9.2008.10.13.gem > ./doc > ./specifications > zernez:/usr/local/lib/ruby/gems/1.9.1> gem list > > *** LOCAL GEMS *** > > > zernez:/usr/local/lib/ruby/gems/1.9.1> > > As you can see I end up with _no_ installed gems. Most critically, there is > no .gemspec file in ./specification, and there isn't one in the the original > archive either. > Am I doing something wrong here ? You can generate it: gem spec pg > specifications/pg-0.7.9.2008.10.13.gemspec That's your last step to have the gem installed, I believe. > > Cheers, > > Han Holl > > PS I've attached the transcript as well, because mail programs may do nasty > thing with some of the lines here. > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From han.holl at tietoenator.com Fri Jan 23 03:45:30 2009 From: han.holl at tietoenator.com (Han Holl) Date: Fri, 23 Jan 2009 09:45:30 +0100 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <71166b3b0901220323m2ea26980l1b12ca357b387712@mail.gmail.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901221032.29269.han.holl@tietoenator.com> <71166b3b0901220323m2ea26980l1b12ca357b387712@mail.gmail.com> Message-ID: <200901230945.31028.han.holl@tietoenator.com> On Thursday 22 January 2009, Luis Lavena wrote: > You can generate it: > > gem spec pg > specifications/pg-0.7.9.2008.10.13.gemspec > > That's your last step to have the gem installed, I believe. > Thanks Luis, that was what I was looking for. Unfortunately, it doesn't work. I tried in several directories, but each time got: ERROR: Unknown gem 'pg' It seems there is still something missing. Han Holl From luislavena at gmail.com Fri Jan 23 09:02:16 2009 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 23 Jan 2009 12:02:16 -0200 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901230945.31028.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901221032.29269.han.holl@tietoenator.com> <71166b3b0901220323m2ea26980l1b12ca357b387712@mail.gmail.com> <200901230945.31028.han.holl@tietoenator.com> Message-ID: <71166b3b0901230602s4dc89be1k9502c6e710d8cecb@mail.gmail.com> On Fri, Jan 23, 2009 at 6:45 AM, Han Holl wrote: > On Thursday 22 January 2009, Luis Lavena wrote: > >> You can generate it: >> >> gem spec pg > specifications/pg-0.7.9.2008.10.13.gemspec >> >> That's your last step to have the gem installed, I believe. >> > Thanks Luis, that was what I was looking for. > Unfortunately, it doesn't work. > I tried in several directories, but each time got: > > ERROR: Unknown gem 'pg' > > It seems there is still something missing. > Oh yeha, my fault: gem spec pg --version '0.7.9.2008.10.13' --remote > specifications/pg-0.7.9.2008.10.13.gemspec It was trying to query it locally :-P > Han Holl > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From luislavena at gmail.com Sat Jan 24 14:14:52 2009 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 24 Jan 2009 17:14:52 -0200 Subject: [Rubygems-developers] New errors crawled in trunk Message-ID: <71166b3b0901241114m3bd4a1caic12b544a864259ee@mail.gmail.com> Hey Guys, I'm checking latest trunk of the code, and noticed new errors crawled in that are shown only on Windows: http://pastie.org/369729 Those are for MinGW version of Ruby, while mswin (VC6) version only show the 4 skipped ones. I saw a lot of activity recently in the repo, but just now catching up. Any hint? -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From thewoolleyman at gmail.com Sat Jan 24 14:28:53 2009 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 24 Jan 2009 12:28:53 -0700 Subject: [Rubygems-developers] New errors crawled in trunk In-Reply-To: <71166b3b0901241114m3bd4a1caic12b544a864259ee@mail.gmail.com> References: <71166b3b0901241114m3bd4a1caic12b544a864259ee@mail.gmail.com> Message-ID: On Sat, Jan 24, 2009 at 12:14 PM, Luis Lavena wrote: > http://pastie.org/369729 Here's the only change I made: http://rubyforge.org/tracker/?func=detail&atid=575&aid=23210&group_id=126 Doesn't seem like it could have caused any of these errors... -- Chad From luislavena at gmail.com Sat Jan 24 14:36:17 2009 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 24 Jan 2009 17:36:17 -0200 Subject: [Rubygems-developers] New errors crawled in trunk In-Reply-To: References: <71166b3b0901241114m3bd4a1caic12b544a864259ee@mail.gmail.com> Message-ID: <71166b3b0901241136q6767b7ccy8cf7d15e5c31e181@mail.gmail.com> On Sat, Jan 24, 2009 at 5:28 PM, Chad Woolley wrote: > On Sat, Jan 24, 2009 at 12:14 PM, Luis Lavena wrote: >> http://pastie.org/369729 > > Here's the only change I made: > > http://rubyforge.org/tracker/?func=detail&atid=575&aid=23210&group_id=126 > > Doesn't seem like it could have caused any of these errors... Hello Chad, I saw that change, but is not the one raising failures. I've just reverted to 1918 (previous the commits related to pre-release gems) and it worked: 696 tests, 2149 assertions, 0 failures, 0 errors, 0 skips I'll move up until found the first one introducing these errors. What worries me is that it fails on MinGW, but not VC6 build of Ruby. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From luislavena at gmail.com Sat Jan 24 15:11:32 2009 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 24 Jan 2009 18:11:32 -0200 Subject: [Rubygems-developers] New errors crawled in trunk In-Reply-To: <71166b3b0901241136q6767b7ccy8cf7d15e5c31e181@mail.gmail.com> References: <71166b3b0901241114m3bd4a1caic12b544a864259ee@mail.gmail.com> <71166b3b0901241136q6767b7ccy8cf7d15e5c31e181@mail.gmail.com> Message-ID: <71166b3b0901241211m6ea2d74jb005818e101c325f@mail.gmail.com> On Sat, Jan 24, 2009 at 5:36 PM, Luis Lavena wrote: > On Sat, Jan 24, 2009 at 5:28 PM, Chad Woolley wrote: >> On Sat, Jan 24, 2009 at 12:14 PM, Luis Lavena wrote: >>> http://pastie.org/369729 >> >> Here's the only change I made: >> >> http://rubyforge.org/tracker/?func=detail&atid=575&aid=23210&group_id=126 >> >> Doesn't seem like it could have caused any of these errors... > > Hello Chad, I saw that change, but is not the one raising failures. > > I've just reverted to 1918 (previous the commits related to > pre-release gems) and it worked: > > 696 tests, 2149 assertions, 0 failures, 0 errors, 0 skips > > I'll move up until found the first one introducing these errors. > revision 1943 introduced the issues: Make Gem::Dependency#=~ to work with Gem::Specification > What worries me is that it fails on MinGW, but not VC6 build of Ruby. > http://pastie.org/369758 Again, the errors only show on MinGW. Will check linux and see what happens. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From han.holl at tietoenator.com Mon Jan 26 08:17:46 2009 From: han.holl at tietoenator.com (Han Holl) Date: Mon, 26 Jan 2009 14:17:46 +0100 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <71166b3b0901230602s4dc89be1k9502c6e710d8cecb@mail.gmail.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901230945.31028.han.holl@tietoenator.com> <71166b3b0901230602s4dc89be1k9502c6e710d8cecb@mail.gmail.com> Message-ID: <200901261417.46942.han.holl@tietoenator.com> On Friday 23 January 2009, Luis Lavena wrote: > > Oh yeha, my fault: > > gem spec pg --version '0.7.9.2008.10.13' --remote > > specifications/pg-0.7.9.2008.10.13.gemspec > Thanks Luis, we're getting closer and closer. Still, the output from the aboce command starts with: --- !ruby/object:Gem::Specification name: pg version: !ruby/object:Gem::Version version: 0.7.9.2008.10.13 platform: ruby authors: ... It looks like YAML. A .gemspec file is like: Gem::Specification.new do |s| s.name = %q{commandline} s.version = "0.7.10" s.specification_version = 1 if s.respond_to? :specification_version= ... end The missing link would appear to be a function that can dump a Gem::Specification object in .gemspec form. I found them, and can report that the following works fine: #!/usr/bin/env ruby require 'yaml' require 'rubygems' require 'rubygems/specification' require 'tempfile' require 'fileutils' gem = ARGV[0] raise 'give name (gem-version)' if gem.nil? out = "#{Gem::dir}/specifications/#{gem}.gemspec" raise "#{out} already exists" if test(?f, out) pkt, version = gem.split('-', 2) IO.popen("gem spec #{pkt} --version '#{version}' --remote") do |io| Tempfile.open('gem') do |temp| temp.puts Gem::Specification.from_yaml(io).to_ruby FileUtils.mv(temp.path, out) end end Thanks a lot for your help. Cheers, Han Holl From luislavena at gmail.com Mon Jan 26 08:24:10 2009 From: luislavena at gmail.com (Luis Lavena) Date: Mon, 26 Jan 2009 11:24:10 -0200 Subject: [Rubygems-developers] How to rebuild a gem In-Reply-To: <200901261417.46942.han.holl@tietoenator.com> References: <200901191647.32629.han.holl@tietoenator.com> <200901230945.31028.han.holl@tietoenator.com> <71166b3b0901230602s4dc89be1k9502c6e710d8cecb@mail.gmail.com> <200901261417.46942.han.holl@tietoenator.com> Message-ID: <71166b3b0901260524o736e486dk9f363c217f5123e4@mail.gmail.com> On Mon, Jan 26, 2009 at 11:17 AM, Han Holl wrote: > On Friday 23 January 2009, Luis Lavena wrote: > >> >> Oh yeha, my fault: >> >> gem spec pg --version '0.7.9.2008.10.13' --remote > >> specifications/pg-0.7.9.2008.10.13.gemspec >> > Thanks Luis, we're getting closer and closer. > Still, the output from the aboce command starts with: > --- !ruby/object:Gem::Specification > name: pg > version: !ruby/object:Gem::Version > version: 0.7.9.2008.10.13 > platform: ruby > authors: > ... > > It looks like YAML. > A .gemspec file is like: > Gem::Specification.new do |s| > s.name = %q{commandline} > s.version = "0.7.10" > > s.specification_version = 1 if s.respond_to? :specification_version= > ... > end > > The missing link would appear to be a function that can dump a > Gem::Specification object in .gemspec form. Hmn, never noticed that, you're correct. I've always used yaml gemspec in my gems to avoid eval'ing them. > I found them, and can report that the following works fine: > #!/usr/bin/env ruby > > require 'yaml' > require 'rubygems' > require 'rubygems/specification' > require 'tempfile' > require 'fileutils' > > gem = ARGV[0] > raise 'give name (gem-version)' if gem.nil? > out = "#{Gem::dir}/specifications/#{gem}.gemspec" > raise "#{out} already exists" if test(?f, out) > pkt, version = gem.split('-', 2) > > IO.popen("gem spec #{pkt} --version '#{version}' --remote") do |io| > Tempfile.open('gem') do |temp| > temp.puts Gem::Specification.from_yaml(io).to_ruby > FileUtils.mv(temp.path, out) > end > end > > Thanks a lot for your help. > > Cheers, > > Han Holl > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From Daniel.Berger at qwest.com Tue Jan 27 10:50:55 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 27 Jan 2009 09:50:55 -0600 Subject: [Rubygems-developers] Gem location and site arch directory Message-ID: Hi, What do people think about RF Bug #14943. http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 If I read it correctly, C extensions should be installed as "lib/i386-msvcr80/foo.so" instead of "lib/foo.so" (on Windows/VC8, for example). It seems reasonable to me, but I wanted to see what other people thought, and if there were any pitfalls to watch out for (beyond needing to modify the search path). Regards, Dan From luislavena at gmail.com Tue Jan 27 12:06:03 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 27 Jan 2009 15:06:03 -0200 Subject: [Rubygems-developers] Gem location and site arch directory In-Reply-To: References: Message-ID: <71166b3b0901270906v6deb2e39q64847d5a1c2be912@mail.gmail.com> On Tue, Jan 27, 2009 at 1:50 PM, Berger, Daniel wrote: > Hi, > > What do people think about RF Bug #14943. > > http://rubyforge.org/tracker/index.php?func=detail&aid=14943&group_id=126&atid=575 > > If I read it correctly, C extensions should be installed as "lib/i386-msvcr80/foo.so" instead of "lib/foo.so" (on Windows/VC8, for example). > I believe it should be Gem::Platform.new(RUBY_PLATFORM).to_s or Gem::Platform.local to match the gem filename signature, platform and folder structure (is x86 instead of i386). > It seems reasonable to me, but I wanted to see what other people thought, and if there were any pitfalls to watch out for (beyond needing to modify the search path). > I just commented on the Ticket, I kind of like it. This will workaround the issues I'm having with rake-compiler for copy of binary .so file before packaging a new gem. Right now I don't see a problem in the long run with the proposed solution (or a backward issue neither). This should be affecting the $LOAD_PATH during Gem::activate, correct? (I'm not up to speed with RubyGems internals). > Regards, > > Dan > Thank you Dan for bumping this. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From Daniel.Berger at qwest.com Tue Jan 27 12:42:20 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 27 Jan 2009 11:42:20 -0600 Subject: [Rubygems-developers] Question on platform, x64 Message-ID: Hi, I released sys-proctable 0.8.0 last night. The Linux version has its own source file (pure Ruby), and the resulting gem is called "sys-proctable-0.8.0-x86-linux.gem". However, when I try to install it on a RHEL here at work, it tries to install an older version. I _think_ this is happening because I built it on a x32 Linux (Ubuntu) system at home, while the RHEL box here at work are x64. If I build the gem on the RHEL box, for example, I end up with "sys-proctable-0.8.0-x86_64-linux.gem". I tried installing using "--platform=linux", but that didn't seem to help. That a bug? Or did I miss something? Is there a spec option I can tweak to say "Any Linux Platform"? Thanks, Dan From luislavena at gmail.com Tue Jan 27 12:58:23 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 27 Jan 2009 15:58:23 -0200 Subject: [Rubygems-developers] Question on platform, x64 In-Reply-To: References: Message-ID: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> On Tue, Jan 27, 2009 at 3:42 PM, Berger, Daniel wrote: > Hi, > > I released sys-proctable 0.8.0 last night. The Linux version has its own source file (pure Ruby), and the resulting gem is called "sys-proctable-0.8.0-x86-linux.gem". However, when I try to install it on a RHEL here at work, it tries to install an older version. > Is this a gem with a extension? Or is just pure-ruby code? > I _think_ this is happening because I built it on a x32 Linux (Ubuntu) system at home, while the RHEL box here at work are x64. If I build the gem on the RHEL box, for example, I end up with "sys-proctable-0.8.0-x86_64-linux.gem". > > I tried installing using "--platform=linux", but that didn't seem to help. > "--platform=x86-linux" should work, the same for "x86-mingw32" or "x86-mswin32-60" under Windows. > That a bug? Or did I miss something? Is there a spec option I can tweak to say "Any Linux Platform"? Originally the platforms are indications of binaries being carried and bundled in the gem, not under which platform the gem should work. As example, the "session" gem is marked as "ruby", but it only works on POSIX OS. Because of that, developer will need to release one gem for x86-linux, x86_64-linux, x86-darwin and ppc-darwin. I guess that a condition in the library will be enough. > > Thanks, > > Dan > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From Daniel.Berger at qwest.com Tue Jan 27 13:42:37 2009 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 27 Jan 2009 12:42:37 -0600 Subject: [Rubygems-developers] Question on platform, x64 In-Reply-To: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> References: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> Message-ID: Hi, > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Luis Lavena > Sent: Tuesday, January 27, 2009 10:58 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] Question on platform, x64 > > On Tue, Jan 27, 2009 at 3:42 PM, Berger, Daniel > wrote: > > Hi, > > > > I released sys-proctable 0.8.0 last night. The Linux > version has its own source file (pure Ruby), and the > resulting gem is called "sys-proctable-0.8.0-x86-linux.gem". > However, when I try to install it on a RHEL here at work, it > tries to install an older version. > > > > Is this a gem with a extension? Or is just pure-ruby code? Depends on the platform. For Linux, Windows and Solaris it's pure Ruby. For FreeBSD, HP-UX, OS X and other BSD flavors it's a C extension. > > I _think_ this is happening because I built it on a x32 > Linux (Ubuntu) system at home, while the RHEL box here at > work are x64. If I build the gem on the RHEL box, for > example, I end up with "sys-proctable-0.8.0-x86_64-linux.gem". > > > > I tried installing using "--platform=linux", but that > didn't seem to help. > > > > "--platform=x86-linux" should work, the same for > "x86-mingw32" or "x86-mswin32-60" under Windows. Thanks, that worked. For Windows it seems that specifying "--platform=mswin32" was enough to install the VC 6 version on my VC 8 Ruby. > > That a bug? Or did I miss something? Is there a spec option > I can tweak to say "Any Linux Platform"? > > Originally the platforms are indications of binaries being > carried and bundled in the gem, not under which platform the > gem should work. Well, I'm kind of stuck then. I have pure Ruby versions that will work on a particular operating system, but aren't tied to any particular runtime, bit-ness, etc. If there isn't any way to specify that with the Gem::Specification, I would argue that we need some way to do so. Or am I the only person in the world hitting this particular issue? Thanks, Dan PS - Yes, I know I've brought this up before, so sorry if I'm beating the issue to death. If you want to see what I'm dealing with, take a look at the sys-proctable source and tell me how _you_ would bundle the gems. From luislavena at gmail.com Tue Jan 27 14:01:39 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 27 Jan 2009 17:01:39 -0200 Subject: [Rubygems-developers] Question on platform, x64 In-Reply-To: References: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> Message-ID: <71166b3b0901271101ta8bf350sa07909649d10a747@mail.gmail.com> On Tue, Jan 27, 2009 at 4:42 PM, Berger, Daniel wrote: > Hi, > >> -----Original Message----- >> From: rubygems-developers-bounces at rubyforge.org >> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf >> Of Luis Lavena >> Sent: Tuesday, January 27, 2009 10:58 AM >> To: rubygems-developers at rubyforge.org >> Subject: Re: [Rubygems-developers] Question on platform, x64 >> >> On Tue, Jan 27, 2009 at 3:42 PM, Berger, Daniel >> wrote: >> > Hi, >> > >> > I released sys-proctable 0.8.0 last night. The Linux >> version has its own source file (pure Ruby), and the >> resulting gem is called "sys-proctable-0.8.0-x86-linux.gem". >> However, when I try to install it on a RHEL here at work, it >> tries to install an older version. >> > >> >> Is this a gem with a extension? Or is just pure-ruby code? > > Depends on the platform. For Linux, Windows and Solaris it's pure Ruby. For FreeBSD, HP-UX, OS X and other BSD flavors it's a C extension. Oh, I see. > >> > I _think_ this is happening because I built it on a x32 >> Linux (Ubuntu) system at home, while the RHEL box here at >> work are x64. If I build the gem on the RHEL box, for >> example, I end up with "sys-proctable-0.8.0-x86_64-linux.gem". >> > >> > I tried installing using "--platform=linux", but that >> didn't seem to help. >> > >> >> "--platform=x86-linux" should work, the same for >> "x86-mingw32" or "x86-mswin32-60" under Windows. > > Thanks, that worked. For Windows it seems that specifying "--platform=mswin32" was enough to install the VC 6 version on my VC 8 Ruby. Watch out for CRT memory allocation and freeing. If your extension (MSVCRT linked) alloc memory your ruby version (MSVCR80) cannot free it. >> > That a bug? Or did I miss something? Is there a spec option >> I can tweak to say "Any Linux Platform"? >> >> Originally the platforms are indications of binaries being >> carried and bundled in the gem, not under which platform the >> gem should work. > > Well, I'm kind of stuck then. I have pure Ruby versions that will work on a particular operating system, but aren't tied to any particular runtime, bit-ness, etc. > I see the issue, and I see a simple condition around the RUBY_PLATFORM and CONFIG['host_os'] will not work for you. There is no way to conditionally tell rubygems that "under this platform, please build this extension". > If there isn't any way to specify that with the Gem::Specification, I would argue that we need some way to do so. Or am I the only person in the world hitting this particular issue? > You're not alone, this imposes a problem for other gems too. As example, there is a json gem. The json gem take advantage of a C extension to parse json output faster, but it also works without it with a slower pure-ruby version. They faced this same problem, and created two gems: json, which forces the compilation of the extension and json_pure, which doesn't bundle the extension. > Thanks, > > Dan > > PS - Yes, I know I've brought this up before, so sorry if I'm beating the issue to death. If you want to see what I'm dealing with, take a look at the sys-proctable source and tell me how _you_ would bundle the gems. Beating these issues until death is something good, you've really exposed another quirk of RubyGems as package manager that needs to be handled to ensure better cross platform integration. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry From hgs at dmu.ac.uk Tue Jan 27 14:27:38 2009 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 27 Jan 2009 19:27:38 +0000 (GMT) Subject: [Rubygems-developers] Question on platform, x64 In-Reply-To: <71166b3b0901271101ta8bf350sa07909649d10a747@mail.gmail.com> References: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> <71166b3b0901271101ta8bf350sa07909649d10a747@mail.gmail.com> Message-ID: On Tue, 27 Jan 2009, Luis Lavena wrote: > There is no way to conditionally tell rubygems that "under this > platform, please build this extension". Would any build command be platform dependent? I'm thinking (out loud) that for some platforms the build command could be `true;` or some other NO-OP which is successful. The un module doesn't have true or anything else NO-OP-like. http://www.ruby-doc.org/stdlib/libdoc/un/rdoc/files/un_rb.html Then you always build, but for some platforms nothing happens. [Not sure how to frame a query to see if this has been thought of already, as I'm sure this is likely, but...] Hugh From luislavena at gmail.com Tue Jan 27 16:43:32 2009 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 27 Jan 2009 19:43:32 -0200 Subject: [Rubygems-developers] Question on platform, x64 In-Reply-To: References: <71166b3b0901270958w4e35ba85qd97af1d4f0628ebc@mail.gmail.com> <71166b3b0901271101ta8bf350sa07909649d10a747@mail.gmail.com> Message-ID: <71166b3b0901271343s123458k8ace9b4fd8e5aa99@mail.gmail.com> On Tue, Jan 27, 2009 at 5:27 PM, Hugh Sasse wrote: > On Tue, 27 Jan 2009, Luis Lavena wrote: >> There is no way to conditionally tell rubygems that "under this >> platform, please build this extension". > > Would any build command be platform dependent? I'm thinking (out > loud) that for some platforms the build command could be `true;` or > some other NO-OP which is successful. The un module doesn't have > true or anything else NO-OP-like. > > http://www.ruby-doc.org/stdlib/libdoc/un/rdoc/files/un_rb.html > I believe this is not the case, but good finding about un... I didn't know about it, and been using Ruby since 2002 :-P > Then you always build, but for some platforms nothing happens. > The problem with RubyGems is that it tries to build the extensions and execute the generated make file. On platforms with compiler that's not a issue, since the default and the install tasks can be empty. On Windows, on default VC6 build (One-Click Installer) you're required to have VC tools (cl and nmake). > [Not sure how to frame a query to see if this has been thought of > already, as I'm sure this is likely, but...] > > Hugh > -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exup?ry