From drbrain at segment7.net Mon Sep 1 01:01:05 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 31 Aug 2008 22:01:05 -0700 Subject: [Rubygems-developers] gem search dies ungracefully In-Reply-To: References: Message-ID: On Aug 23, 2008, at 19:22 PM, michael greenly wrote: > Github is returning 503 'service temporarily unavailable' errors and > 'gem search foo -r' dies ungacefully on it. > > *** REMOTE GEMS *** > > ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) > bad response Service Temporarily Unavailable 503 (http://gems.github.com/latest_specs.4.8 > ) How much more graceful than 2 lines should it be? From Amanda.Waite at Sun.COM Mon Sep 1 05:18:31 2008 From: Amanda.Waite at Sun.COM (Amanda Waite) Date: Mon, 01 Sep 2008 10:18:31 +0100 Subject: [Rubygems-developers] /etc/gemrc and GEM_PATH behaviour Message-ID: <48BBB367.6050108@sun.com> Hi there, I've been working on OS level packaging of some Ruby Gems on OpenSolaris. I had hoped to be able to use /etc/gemrc to specify the gem search path, but I've found that setting gempath in /etc/gemrc only affects the running of the gem command and not the running/loading of gems themselves. I've worked through the code as best I can and it seems to come down to the GemRunner class creating a Gem::ConfigFile instance which then reads the /etc/gemrc file. The gempath and gemhome values are then pushed into the Gem.path via the use_paths method in rubygems.rb. This code path is only used when running the gem command. For running Gems (like rails) or loading gems in scripts, the value for default_path is used unless GEM_PATH is set. In this case the ConfigFile is never loaded. Is there any documentation that describes the intended behaviour of /etc/gemrc? I've looked around but most of what I've found relates to .gemrc and much of that is anecdotal. Cheers Amanda From thewoolleyman at gmail.com Mon Sep 1 17:14:59 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 1 Sep 2008 14:14:59 -0700 Subject: [Rubygems-developers] /etc/gemrc and GEM_PATH behaviour In-Reply-To: <48BBB367.6050108@sun.com> References: <48BBB367.6050108@sun.com> Message-ID: On Mon, Sep 1, 2008 at 2:18 AM, Amanda Waite wrote: > Hi there, > > I've been working on OS level packaging of some Ruby Gems on OpenSolaris. I > had hoped to be able to use /etc/gemrc to specify the gem search path, but > I've found that setting gempath in /etc/gemrc only affects the running of > the gem command and not the running/loading of gems themselves. I've worked > through the code as best I can and it seems to come down to the GemRunner > class creating a Gem::ConfigFile instance which then reads the /etc/gemrc > file. The gempath and gemhome values are then pushed into the Gem.path via > the use_paths method in rubygems.rb. This code path is only used when > running the gem command. For running Gems (like rails) or loading gems in > scripts, the value for default_path is used unless GEM_PATH is set. In this > case the ConfigFile is never loaded. Hi Amanda, There are definitely some bugs in this area. Sounds like you've tracked it down further than anyone else, at least anyone who has posted their findings to the list. Good job. If you can open a bug report with a fully reproducible scenario, that would be a great step forward in fixing the problems. For example: exact contents of gemrc, exact steps to reproduce the error (either via command line or via API in IRB), and detailed description of expected vs. actual results. -- Chad From drbrain at segment7.net Tue Sep 2 23:13:02 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 2 Sep 2008 20:13:02 -0700 Subject: [Rubygems-developers] mysql 2.7.3 is there but not installable? In-Reply-To: References: Message-ID: <47FAA9DC-30AE-4A96-A11C-E9DCDC9DD698@segment7.net> On Aug 24, 2008, at 05:39 AM, Chad Woolley wrote: > Bad mirror or cache? > > chadmac:rails woolley$ gem list mysql -r > > *** REMOTE GEMS *** > > mysql (2.7.3, 2.7) > mysql_replication_adapter (0.4.0) > mysql_retry_lost_connection (0.0.1) > > chadmac:rails woolley$ gem install mysql --version=2.7.3 > ERROR: could not find gem mysql locally or in a repository > > chadmac:rails woolley$ sudo gem install mysql --version=2.7 > Building native extensions. This could take a while... No, 2.7.3 is only for mswin32, AFAIK. Wilson did some work in this area that should have helped. From thewoolleyman at gmail.com Wed Sep 3 01:17:39 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 2 Sep 2008 22:17:39 -0700 Subject: [Rubygems-developers] mysql 2.7.3 is there but not installable? In-Reply-To: <47FAA9DC-30AE-4A96-A11C-E9DCDC9DD698@segment7.net> References: <47FAA9DC-30AE-4A96-A11C-E9DCDC9DD698@segment7.net> Message-ID: On Tue, Sep 2, 2008 at 8:13 PM, Eric Hodel wrote: > No, 2.7.3 is only for mswin32, AFAIK. Wilson did some work in this area > that should have helped. OK. Seems like it should not be found by list if it is not found by install. Are gems for other platforms handled differently by list vs. install? Is this some of the work Wilson did? From greg.hauptmann.ruby at gmail.com Sun Sep 7 20:05:25 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Mon, 8 Sep 2008 10:05:25 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) Message-ID: Hi, (I'm not sure if this is the appropriate forum to raise this?) I have been having stability issues with http://gems.rubyforge.org/ over the last week. Is this a known issue (i.e. trying work out if this is global or an issue at my end). For example I have been unsuccessful in getting "mysql" installed. I get a "RubyGems will revert to legacy indexes degrading performance" output. See below: ========================= Macintosh-2:myequity greg$ sudo gem install mysql Password: WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Updating metadata for 23 gems from http://gems.rubyforge.org/ ERROR: While executing gem ... (NoMethodError) undefined method `full_name' for # Macintosh-2:myequity greg$ Macintosh-2:myequity greg$ ========================= thanks in advance From greg.hauptmann.ruby at gmail.com Sun Sep 7 20:26:16 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Mon, 8 Sep 2008 10:26:16 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: Message-ID: PS. I also get this trying to update the system Macintosh-2:myequity greg$ sudo gem update --system Password: Updating RubyGems WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Updating metadata for 23 gems from http://gems.rubyforge.org/ ERROR: While executing gem ... (NoMethodError) undefined method `full_name' for # Macintosh-2:myequity greg$ Other info: Macintosh-2:myequity greg$ gem -v 1.2.0 Macintosh-2:myequity greg$ ruby -v ruby 1.8.6 (2007-09-23 patchlevel 110) [i686-darwin9.3.0] With --debug enabled: ------------------------------------ Macintosh-2:myequity greg$ sudo gem update --system --debug Exception `NameError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::UpdateCommand Updating RubyGems Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/latest_specs.4.8.gz) WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Net::HTTPBadResponse' at /opt/local/lib/ruby/1.8/net/http.rb:2019 - wrong status line: "\037\213\b\000gh\304H\000\003t\275[\214$Yv\030\346\316\031vWe\275_\375\234\331%\333\\\214H8{\273\262\252_+\017T3\3233\275\263\234\356\031v\365>HJ" Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/quick/latest_index.rz) Updating metadata for 23 gems from http://gems.rubyforge.org/ Exception `TypeError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:488 - incompatible marshal file format (can't be read) format version 4.8 required; 65.78 given Exception `NoMethodError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172 - undefined method `full_name' for # ERROR: While executing gem ... (NoMethodError) undefined method `full_name' for # /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172:in `add_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:523:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:355:in `update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:42:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:249:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:41:in `cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:86:in `search_with_source' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:147:in `which_to_update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:242:in `warn_legacy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:142:in `which_to_update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:132:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:132:in `which_to_update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/update_command.rb:68:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' /opt/local/bin/gem:24 Macintosh-2:myequity greg$ ------------------------------ On Mon, Sep 8, 2008 at 10:05 AM, Greg Hauptmann wrote: > Hi, (I'm not sure if this is the appropriate forum to raise this?) > > I have been having stability issues with http://gems.rubyforge.org/ > over the last week. Is this a known issue (i.e. trying work out if > this is global or an issue at my end). > > For example I have been unsuccessful in getting "mysql" installed. I > get a "RubyGems will revert to legacy indexes degrading performance" > output. See below: > > ========================= > Macintosh-2:myequity greg$ sudo gem install mysql > Password: > WARNING: RubyGems 1.2+ index not found for: > RubyGems will revert to legacy indexes degrading performance. > Updating metadata for 23 gems from http://gems.rubyforge.org/ > ERROR: While executing gem ... (NoMethodError) > undefined method `full_name' for # > Macintosh-2:myequity greg$ > Macintosh-2:myequity greg$ > ========================= > > thanks in advance > From Amanda.Waite at Sun.COM Mon Sep 8 05:22:13 2008 From: Amanda.Waite at Sun.COM (Amanda Waite) Date: Mon, 08 Sep 2008 10:22:13 +0100 Subject: [Rubygems-developers] /etc/gemrc and GEM_PATH behaviour Message-ID: <48C4EEC5.8070408@sun.com> Sorry for not threading this, I was in digest mode and didn't get the other emails in the thread. I raised a big for this issue: [#21853] /etc/gemrc settings not honored when loading gems through the #gem or #require methods Thanks Amanda From drbrain at segment7.net Wed Sep 10 15:22:31 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 10 Sep 2008 12:22:31 -0700 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: Message-ID: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> On Sep 7, 2008, at 17:05 PM, Greg Hauptmann wrote: > Hi, (I'm not sure if this is the appropriate forum to raise this?) > > I have been having stability issues with http://gems.rubyforge.org/ > over the last week. Is this a known issue (i.e. trying work out if > this is global or an issue at my end). > > For example I have been unsuccessful in getting "mysql" installed. I > get a "RubyGems will revert to legacy indexes degrading performance" > output. See below: > > ========================= > Macintosh-2:myequity greg$ sudo gem install mysql > Password: > WARNING: RubyGems 1.2+ index not found for: > RubyGems will revert to legacy indexes degrading performance. > Updating metadata for 23 gems from http://gems.rubyforge.org/ > ERROR: While executing gem ... (NoMethodError) > undefined method `full_name' for # > Macintosh-2:myequity greg$ > Macintosh-2:myequity greg$ > ========================= I've not heard of anybody else with this problem on IRC or on the ruby- talk mailing list. I suspect that you're behind a proxy, as the file RubyGems is looking for is most certainly there. From greg.hauptmann.ruby at gmail.com Thu Sep 11 23:49:32 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Fri, 12 Sep 2008 13:49:32 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: Tks Eric, so does this mean I'm really up for a manual install...can one do manual gem installs? do you think I should raise an issue with my ISP, however I'm not exactly sure how I'd phase the support request? Greg On Thu, Sep 11, 2008 at 5:22 AM, Eric Hodel wrote: > On Sep 7, 2008, at 17:05 PM, Greg Hauptmann wrote: > >> Hi, (I'm not sure if this is the appropriate forum to raise this?) >> >> I have been having stability issues with http://gems.rubyforge.org/ >> over the last week. Is this a known issue (i.e. trying work out if >> this is global or an issue at my end). >> >> For example I have been unsuccessful in getting "mysql" installed. I >> get a "RubyGems will revert to legacy indexes degrading performance" >> output. See below: >> >> ========================= >> Macintosh-2:myequity greg$ sudo gem install mysql >> Password: >> WARNING: RubyGems 1.2+ index not found for: >> RubyGems will revert to legacy indexes degrading performance. >> Updating metadata for 23 gems from http://gems.rubyforge.org/ >> ERROR: While executing gem ... (NoMethodError) >> undefined method `full_name' for # >> Macintosh-2:myequity greg$ >> Macintosh-2:myequity greg$ >> ========================= > > I've not heard of anybody else with this problem on IRC or on the ruby-talk > mailing list. I suspect that you're behind a proxy, as the file RubyGems is > looking for is most certainly there. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From greg.hauptmann.ruby at gmail.com Fri Sep 12 04:24:24 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Fri, 12 Sep 2008 18:24:24 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: actually I've done a " sudo gem sources -r http://gems.rubyonrails.org/" and I think this has fixed things. I'm now getting the following which I think means the gem stuff worked: ============================ Macintosh-2:myequity greg$ sudo gem install mysql Building native extensions. This could take a while... ERROR: Error installing mysql: ERROR: Failed to build gem native extension. /opt/local/bin/ruby extconf.rb install mysql checking for mysql_query() in -lmysqlclient... no checking for main() in -lm... yes checking for mysql_query() in -lmysqlclient... no checking for main() in -lz... yes checking for mysql_query() in -lmysqlclient... no checking for main() in -lsocket... no checking for mysql_query() in -lmysqlclient... no checking for main() in -lnsl... no checking for mysql_query() in -lmysqlclient... no Gem files will remain installed in /opt/local/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection. Results logged to /opt/local/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out ============================ On Fri, Sep 12, 2008 at 1:49 PM, Greg Hauptmann wrote: > Tks Eric, so does this mean I'm really up for a manual install...can > one do manual gem installs? do you think I should raise an issue with > my ISP, however I'm not exactly sure how I'd phase the support > request? > Greg > > > > On Thu, Sep 11, 2008 at 5:22 AM, Eric Hodel wrote: >> On Sep 7, 2008, at 17:05 PM, Greg Hauptmann wrote: >> >>> Hi, (I'm not sure if this is the appropriate forum to raise this?) >>> >>> I have been having stability issues with http://gems.rubyforge.org/ >>> over the last week. Is this a known issue (i.e. trying work out if >>> this is global or an issue at my end). >>> >>> For example I have been unsuccessful in getting "mysql" installed. I >>> get a "RubyGems will revert to legacy indexes degrading performance" >>> output. See below: >>> >>> ========================= >>> Macintosh-2:myequity greg$ sudo gem install mysql >>> Password: >>> WARNING: RubyGems 1.2+ index not found for: >>> RubyGems will revert to legacy indexes degrading performance. >>> Updating metadata for 23 gems from http://gems.rubyforge.org/ >>> ERROR: While executing gem ... (NoMethodError) >>> undefined method `full_name' for # >>> Macintosh-2:myequity greg$ >>> Macintosh-2:myequity greg$ >>> ========================= >> >> I've not heard of anybody else with this problem on IRC or on the ruby-talk >> mailing list. I suspect that you're behind a proxy, as the file RubyGems is >> looking for is most certainly there. >> _______________________________________________ >> Rubygems-developers mailing list >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > From drbrain at segment7.net Fri Sep 12 16:42:16 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Sep 2008 13:42:16 -0700 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: On Sep 11, 2008, at 20:49 PM, Greg Hauptmann wrote: > Tks Eric, so does this mean I'm really up for a manual install...can > one do manual gem installs? do you think I should raise an issue with > my ISP, however I'm not exactly sure how I'd phase the support > request? You could try: gem install -V some_gem It should print out what RubyGems tried to fetch and what response was received, then use something like curl -I URL to see if RubyGems is insane or not. From drbrain at segment7.net Fri Sep 12 17:27:26 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Sep 2008 14:27:26 -0700 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir In-Reply-To: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> References: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> Message-ID: <7CEE971C-56E9-4471-9D92-931901092C77@segment7.net> On Aug 27, 2008, at 06:05 AM, Caspar Florian Ebeling wrote: > This seems to be a bug: > > $ mkdir gem_stage/ > $ gem install --install-dir gem_stage --local externals-1.0.0.gem > Successfully installed externals-1.0.0 > 1 gem installed > Installing ri documentation for externals-1.0.0... > Installing RDoc documentation for externals-1.0.0... > $ gem uninstall externals --install-dir gem_stage > ERROR: While executing gem ... (Gem::InstallError) > Unknown gem externals >= 0 > > Basically, --install-dir seems to be ignored on uninstall. This seems to work on trunk. $ ruby -Ilib bin/gem ins rubyforge -i ~/tmp/gems Successfully installed rubyforge-1.0.0 1 gem installed Installing ri documentation for rubyforge-1.0.0... Installing RDoc documentation for rubyforge-1.0.0... $ ruby -Ilib bin/gem unin rubyforge -i ~/tmp/gems Remove executables: rubyforge in addition to the gem? [Yn] y Removing rubyforge Successfully uninstalled rubyforge-1.0.0 $ From drbrain at segment7.net Fri Sep 12 18:20:28 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Sep 2008 15:20:28 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: On Aug 17, 2008, at 17:49 PM, Chad Woolley wrote: > On Sun, Aug 17, 2008 at 4:08 PM, Eric Hodel > wrote: >> Please test out RubyGems trunk. > > All of the GemInstaller integration/regression tests are passing. > Looks good there.. > >> Current Release notes for 1.3.0: > > Um, you mean 1.2.0, right? That's what rubygems_version.rb says in > trunk, anyway. Wait, I already have that installed! Can you _please_ > start bumping the version as soon as you release? In other words, > after this release, bump to 1.4.0 in trunk, and bump to 1.4.1 again > right before release. Multiple people have asked for this to make > their lives easier when integrating against trunk versions of > rubygems. It's necessary if you need to put backward-compatibility > version-conditional logic when calling the RubyGems API. If you > don't, I have to manually edit the version in whenever I integrate or > install from trunk. It doesn't hurt anything for the public releases > not to end in zero. It's the right thing to do. NOT to do so sets a > bad example for other gems. rake install isn't enough? Is there some other thing you could write with generate_rubygems_version (in Rakefile)? >> * RubyGems now installs into ~/.gem if GEM_HOME is not writable. Use >> --no-user-install command-line switch to disable this behavior. > > This sounds awesome, but there doesn't seem to be an easy way to > change to this approach if you already have rubygems installed as root > (in the standard system location). This is for installing gems, not RubyGems software itself. I will fix the release notes to remove potential confusion. > Finally, I'm not sure how to test this fully on my local box. First, > running "rake gem" fails because I don't have > /.gem/gem-private_key.pem. Even if I had the gem, how would I force > gem update --system --user-install to use a non-released local update > gem, rather than the latest one on rubyforge? I've fixed `rake gem` to warn if you don't have a key or certificate. From drbrain at segment7.net Fri Sep 12 19:23:05 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Sep 2008 16:23:05 -0700 Subject: [Rubygems-developers] Overriding default directories In-Reply-To: <50d9f33a0808171508m42eb561cu118ee201880a558d@mail.gmail.com> References: <50d9f33a0808171508m42eb561cu118ee201880a558d@mail.gmail.com> Message-ID: On Aug 17, 2008, at 15:08 PM, Neil Wilson wrote: > Using the 'operating_system.rb' I have been unable to find a simple > way of changing the default directories by altering a single setting. > > For ubuntu, gems needs to go in /var/lib/gems/1.8 and the binaries in > /var/lib/gems/1.8/bin. > > With every other setting I keep getting the standard /usr/lib showing > up somewhere, either on the gem path or the binary path depending how > things are changed. Essentially there doesn't appear to be one place > with gems gets the path and the binary path from. RubyGems doesn't get this information all from one place. The default Gem.bindir comes directly from rbconfig.rb, but the default Gem.dir is composed of several pieces, etc. > The best I've come up with is: > > # Set the default gem installation directories and paths to the Debian > # defaults by poking the correct values into the ENV hash. > ENV['GEM_HOME'] = > File.join('','var','lib','gems',ConfigMap[:ruby_version]) > # I don't want to see 'default_dir' ever. > ENV['GEM_PATH'] = user_dir Does adding a Gem.clear_paths at the bottom of operating_system.rb fix the problem? You shouldn't touch ENV in operating_system.rb. Can you attach your operating_system.rb? > Is there a better way? From drbrain at segment7.net Fri Sep 12 19:45:37 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 12 Sep 2008 16:45:37 -0700 Subject: [Rubygems-developers] Hook required for update --system In-Reply-To: <50d9f33a0808171501v5a63dcf9y9ed1234af4fd3626@mail.gmail.com> References: <50d9f33a0808171501v5a63dcf9y9ed1234af4fd3626@mail.gmail.com> Message-ID: <402C36B4-DD4C-46F8-967A-76E36E267E71@segment7.net> On Aug 17, 2008, at 15:01 PM, Neil Wilson wrote: > As you know I've been working on some new packaging for Ubuntu using > the new operating_system.rb facilities. > > One of the things I want to do is override the 'update --system' > facility so that it calls the native package manager rather than > trying to do it via gems. An update via gems always goes into the > wrong directory, and it would upset the native package manager anyway. > > I couldn't see an easy way of changing the facility so I had to patch > the update command so that it simply execs the correct package manager > command. > > Would it be possible to factor out the default behaviour of adding > 'rubygems-update' to the list of gems to update so that it can be > overridden in 'operating_system.rb'? Right now this is all in Gem::Commands::UpdateCommand#do_rubygems_update I'm trying to think of a solution that would make it easy to define your own, but I've not arrived at one. Opening the class and defining it ahead of time could cause the rest of UpdateCommand not to load. Requiring the file first causes lots of extra stuff you don't want to load. From thewoolleyman at gmail.com Fri Sep 12 19:54:20 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 12 Sep 2008 16:54:20 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: On Fri, Sep 12, 2008 at 3:20 PM, Eric Hodel wrote: > On Aug 17, 2008, at 17:49 PM, Chad Woolley wrote: >> Um, you mean 1.2.0, right? That's what rubygems_version.rb says in >> trunk, anyway. Wait, I already have that installed! Can you _please_ >> start bumping the version as soon as you release? In other words, >> after this release, bump to 1.4.0 in trunk, and bump to 1.4.1 again >> right before release. Multiple people have asked for this to make >> their lives easier when integrating against trunk versions of >> rubygems. It's necessary if you need to put backward-compatibility >> version-conditional logic when calling the RubyGems API. If you >> don't, I have to manually edit the version in whenever I integrate or >> install from trunk. It doesn't hurt anything for the public releases >> not to end in zero. It's the right thing to do. NOT to do so sets a >> bad example for other gems. > > rake install isn't enough? Is there some other thing you could write with > generate_rubygems_version (in Rakefile)? This has nothing to do with rake install or the rakefile. I'm saying to increment RubyGemsVersion in rubygems_version.rb in trunk to be 1.4.0 as soon as you release 1.3.0. Then, when you make the 1.4 release, make it 1.4.1 (or 1.4.0.1, but 1.4.1 seems better). This will allow people who write against the RubyGems API to use a RubyGemsVersion check to make decisions about which API to go against - the 1.3 API (released gem) or the 1.4 API (in trunk). It makes sense. As soon as you release 1.3, the trunk IS 1.4. Unless you decide it will be 2.0 (now or later), which is still fine, because people should be doing >= in the API version checks anyway. BTW, Koz just emailed me and this is what Rails is going to do for 2.2. -- Chad P.S. You'll still give a week warning before you release right? I still need to do a release to be compatible with 1.3... From neil at brightbox.co.uk Sat Sep 13 01:12:50 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Sat, 13 Sep 2008 06:12:50 +0100 Subject: [Rubygems-developers] Overriding default directories In-Reply-To: References: <50d9f33a0808171508m42eb561cu118ee201880a558d@mail.gmail.com> Message-ID: <50d9f33a0809122212v7915dd7cud0c1b47c631a37fd@mail.gmail.com> On 13/09/2008, Eric Hodel wrote: > Does adding a Gem.clear_paths at the bottom of operating_system.rb fix the > problem? You shouldn't touch ENV in operating_system.rb. Can you attach > your operating_system.rb? I'll check that, but the last time I looked the code only checked ENV before issuing the /usr/lib directory. The operating_system.rb is here. http://github.com/NeilW/deb-rubygems/tree/master/debian/operating_system.rb -- Neil Wilson From florian.ebeling at gmail.com Sun Sep 14 10:35:34 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Sun, 14 Sep 2008 16:35:34 +0200 Subject: [Rubygems-developers] Bug in fetch? Message-ID: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> Hi, when I try to use the fetch separately, then gem fails with an error indicating missing privileges. This should not happend because fetch is documented as saving the gem archive to the current directory. flomac:vendor febeling$ rubygems-svn/bin/gem fetch hpricot --source http://code.whytheluckystiff.net ERROR: While executing gem ... (Errno::EACCES) Permission denied - /opt/local/lib/ruby/gems/1.8/cache/hpricot-0.6.gem flomac:vendor febeling$ pwd /Users/febeling/vendor The error references the regular location of gems, and not the local directory. Seems wrong to me. This test happend from the trunk version as of today (r1868). Do I miss something or is this a bug? Florian -- Florian Ebeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Sun Sep 14 15:31:32 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Sun, 14 Sep 2008 21:31:32 +0200 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir In-Reply-To: <7CEE971C-56E9-4471-9D92-931901092C77@segment7.net> References: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> <7CEE971C-56E9-4471-9D92-931901092C77@segment7.net> Message-ID: <5cbbe4ae0809141231s3882339eh5c4958ddd1932f4d@mail.gmail.com> On Fri, Sep 12, 2008 at 11:27 PM, Eric Hodel wrote: > On Aug 27, 2008, at 06:05 AM, Caspar Florian Ebeling wrote: >> This seems to be a bug: >> $ mkdir gem_stage/ >> $ gem install --install-dir gem_stage --local externals-1.0.0.gem >> Successfully installed externals-1.0.0 >> 1 gem installed >> Installing ri documentation for externals-1.0.0... >> Installing RDoc documentation for externals-1.0.0... >> $ gem uninstall externals --install-dir gem_stage >> ERROR: While executing gem ... (Gem::InstallError) >> Unknown gem externals >= 0 >> >> Basically, --install-dir seems to be ignored on uninstall. > > This seems to work on trunk. To me it still looks broken, unfortunately: flomac:vendor febeling$ rubygems-svn/bin/gem install activesupport -i tmptrunk/ Successfully installed activesupport-2.1.1 1 gem installed Installing ri documentation for activesupport-2.1.1... Installing RDoc documentation for activesupport-2.1.1... flomac:vendor febeling$ rubygems-svn/bin/gem uninstall activesupport -i tmptrunk/ Select gem to uninstall: 1. activesupport-1.4.2 2. activesupport-2.1.0 3. All versions > ^CERROR: Interrupted Please note that it does not offer the newly installed version 2.1.1 for uninstallment, only my real one, 2.1.0. This is the trunk (r1868) version. Florian -- Florian Ebeling florian.ebeling at gmail.com From transfire at gmail.com Tue Sep 16 08:35:40 2008 From: transfire at gmail.com (Trans) Date: Tue, 16 Sep 2008 05:35:40 -0700 (PDT) Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: On Aug 17, 7:08?pm, Eric Hodel wrote: > Please test out RubyGems trunk. ?The best way to install it and make ? > sure you can still update to 1.3.0 on the official release is: > > $ svn up > $ sudo rake install > > Current Release notes for 1.3.0: > > = Announce: RubyGems Release 1.3.0 > > Release 1.3.0 adds new features and fixes some bugs. > > New features: > > * RubyGems doesn't print LOCAL/REMOTE titles for `gem query` and ? > friends if > stdout is not a TTY, except with --both. > * Added Gem.find_files, allows a gem to discover features provided by ? > other > gems. > * Added pre/post (un)install hooks for packagers of RubyGems. ?(Not ? > for gems > themselves). > * RubyGems now installs into ~/.gem if GEM_HOME is not writable. ?Use > --no-user-install command-line switch to disable this behavior. > * Fetching specs for update now uses If-Modified-Since requests. May I ask that you please use XDG standard. T. From technomancy at gmail.com Wed Sep 17 12:22:22 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Wed, 17 Sep 2008 09:22:22 -0700 Subject: [Rubygems-developers] /etc/gemrc and GEM_PATH behaviour References: <48C4EEC5.8070408@sun.com> Message-ID: <87hc8espxd.fsf@hagelb.org> Amanda Waite writes: > Sorry for not threading this, I was in digest mode and didn't get the > other emails in the thread. > > I raised a big for this issue: > > [#21853] /etc/gemrc settings not honored when loading gems through the > #gem or #require methods Thanks for catching this. I've just committed a fix for this problem. -Phil From technomancy at gmail.com Wed Sep 17 14:10:02 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Wed, 17 Sep 2008 11:10:02 -0700 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> (Caspar Florian Ebeling's message of "Sun, 14 Sep 2008 16:35:34 +0200") References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> Message-ID: <87d4j2skxx.fsf@hagelb.org> "Caspar Florian Ebeling" writes: > flomac:vendor febeling$ rubygems-svn/bin/gem fetch hpricot --source > http://code.whytheluckystiff.net > ERROR: While executing gem ... (Errno::EACCES) > Permission denied - /opt/local/lib/ruby/gems/1.8/cache/hpricot-0.6.gem > flomac:vendor febeling$ pwd > /Users/febeling/vendor > > The error references the regular location of gems, and not the local directory. > Seems wrong to me. This test happend from the trunk version as > of today (r1868). > > Do I miss something or is this a bug? I can't reproduce this on trunk. Can you give us the value of Gem.dir and Gem.user_dir from IRB? It looks like you may be using the "gem" executable from the bin directory with the system-installed "lib" files. Try this instead: $ cd rubygems-svn $ ruby -I:lib bin/gem fetch hpricot --source=http://code.whytheluckystiff.net That will ensure that you are using the lib directory from the checkout. It's a bit confusing if you're used to bin files that set the load path explicitly with File.dirname(__FILE__) as is common. -Phil From drbrain at segment7.net Wed Sep 17 14:57:27 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Sep 2008 11:57:27 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: On Sep 16, 2008, at 05:35 AM, Trans wrote: > May I ask that you please use XDG standard. No. It is not cross-platform. From hongli at phusion.nl Wed Sep 17 16:55:49 2008 From: hongli at phusion.nl (Hongli Lai) Date: Wed, 17 Sep 2008 22:55:49 +0200 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: <48D16ED5.3000205@phusion.nl> Eric Hodel wrote: > No. It is not cross-platform. Could you elaborate on this? As far as I know, there is no true cross-platform standard on where to install user-specific files. Installing to ~/.local as per the XDG standard doesn't violate any existing standards, but does follow the standards which many Unix desktop software is already following. Installing to ~/.local doesn't break anything. Besides, installing to ~/.local makes the user's home folder less messy. -- Phusion | The Computer Science Company Web: http://www.phusion.nl/ E-mail: info at phusion.nl Chamber of commerce no: 08173483 (The Netherlands) From technomancy at gmail.com Wed Sep 17 17:17:33 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Wed, 17 Sep 2008 14:17:33 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: <48D16ED5.3000205@phusion.nl> (Hongli Lai's message of "Wed, 17 Sep 2008 22:55:49 +0200") References: <48D16ED5.3000205@phusion.nl> Message-ID: <878wtqsc9e.fsf@hagelb.org> Hongli Lai writes: > Installing to ~/.local as per the XDG standard doesn't violate any > existing standards, but does follow the standards which many Unix > desktop software is already following. Installing to ~/.local doesn't > break anything. > > Besides, installing to ~/.local makes the user's home folder less messy. Users are pretty used to seeing lots and lots of dotfiles in their home directory. Right now I have 102 such items, and it's never bothered me; there's a reason these are hidden by default. I think it would be pretty annoying to have to traverse two extra levels of directory nesting to find my gems though. There's already three levels due to splitting out by ruby version number and implementation; why add to this? It seems like the other things kept in .local in my box are very end-user-desktop-specific. Rubygems is meant to run on all kinds of machines, so I don't see why this freedesktop.org standard is relevant here. Perhaps if you could point to the relevant sections of the standard? -Phil From thewoolleyman at gmail.com Wed Sep 17 19:07:57 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 17 Sep 2008 16:07:57 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: <878wtqsc9e.fsf@hagelb.org> References: <48D16ED5.3000205@phusion.nl> <878wtqsc9e.fsf@hagelb.org> Message-ID: On Wed, Sep 17, 2008 at 2:17 PM, Phil Hagelberg wrote: > I think it would be pretty annoying to have to traverse two extra levels > of directory nesting to find my gems though. There's already three > levels due to splitting out by ruby version number and implementation; > why add to this? I agree. If there are no real standards, why not just use .gem? Most people will probably be navigating there via the command line anyway, so having it in the root of the home dir is less work for from the command line. If you are clicking through a GUI file browser, like Phil said, you probably already have to deal with tons of dot files - and a probably not a power user, which is another reason to make it very easy to find as something named "gem" in the root of the home dir. From jftucker at gmail.com Wed Sep 17 19:33:25 2008 From: jftucker at gmail.com (James Tucker) Date: Thu, 18 Sep 2008 00:33:25 +0100 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> Message-ID: On 14 Sep 2008, at 15:35, Caspar Florian Ebeling wrote: > Hi, > > when I try to use the fetch separately, then gem fails with an error > indicating missing privileges. This should not happend because > fetch is documented as saving the gem archive to the current > directory. > > flomac:vendor febeling$ rubygems-svn/bin/gem fetch hpricot --source > http://code.whytheluckystiff.net > ERROR: While executing gem ... (Errno::EACCES) > Permission denied - /opt/local/lib/ruby/gems/1.8/cache/ > hpricot-0.6.gem > flomac:vendor febeling$ pwd > /Users/febeling/vendor > > The error references the regular location of gems, and not the local > directory. > Seems wrong to me. This test happend from the trunk version as > of today (r1868). It's been this way for a long time, maybe forever. rubygems seems to want to cache the file in the main cache before copying it out to the local directory. > > > Do I miss something or is this a bug? > > Florian > > > -- > Florian Ebeling > florian.ebeling at gmail.com > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From luislavena at gmail.com Wed Sep 17 19:40:11 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 17 Sep 2008 20:40:11 -0300 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> Message-ID: <71166b3b0809171640lb1945cfwcff2fff40fab9ab7@mail.gmail.com> On Wed, Sep 17, 2008 at 8:33 PM, James Tucker wrote: > > On 14 Sep 2008, at 15:35, Caspar Florian Ebeling wrote: > >> Hi, >> >> when I try to use the fetch separately, then gem fails with an error >> indicating missing privileges. This should not happend because >> fetch is documented as saving the gem archive to the current >> directory. >> >> flomac:vendor febeling$ rubygems-svn/bin/gem fetch hpricot --source >> http://code.whytheluckystiff.net >> ERROR: While executing gem ... (Errno::EACCES) >> Permission denied - /opt/local/lib/ruby/gems/1.8/cache/hpricot-0.6.gem >> flomac:vendor febeling$ pwd >> /Users/febeling/vendor >> >> The error references the regular location of gems, and not the local >> directory. >> Seems wrong to me. This test happend from the trunk version as >> of today (r1868). > > It's been this way for a long time, maybe forever. rubygems seems to want to > cache the file in the main cache before copying it out to the local > directory. > Yes, the same happened to me under Windows (user don't have write access to C:/Ruby/lib/ruby/1.8/gems/**) Eric: what about using TMP for fetch actions? Is feasible? -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From technomancy at gmail.com Wed Sep 17 19:51:31 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Wed, 17 Sep 2008 16:51:31 -0700 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <71166b3b0809171640lb1945cfwcff2fff40fab9ab7@mail.gmail.com> (Luis Lavena's message of "Wed, 17 Sep 2008 20:40:11 -0300") References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> <71166b3b0809171640lb1945cfwcff2fff40fab9ab7@mail.gmail.com> Message-ID: <871vzis54s.fsf@hagelb.org> "Luis Lavena" writes: > Yes, the same happened to me under Windows (user don't have write > access to C:/Ruby/lib/ruby/1.8/gems/**) > > Eric: what about using TMP for fetch actions? Is feasible? In trunk, this should fall back to "#{Gem.user_dir}/cache" if "#{Gem.dir}/cache" isn't writable. Are you seeing this in recent versions? -Phil From luislavena at gmail.com Wed Sep 17 20:31:35 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 17 Sep 2008 21:31:35 -0300 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <871vzis54s.fsf@hagelb.org> References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> <71166b3b0809171640lb1945cfwcff2fff40fab9ab7@mail.gmail.com> <871vzis54s.fsf@hagelb.org> Message-ID: <71166b3b0809171731j44d367f4u5d2e11cd349b8a62@mail.gmail.com> On Wed, Sep 17, 2008 at 8:51 PM, Phil Hagelberg wrote: > "Luis Lavena" writes: > >> Yes, the same happened to me under Windows (user don't have write >> access to C:/Ruby/lib/ruby/1.8/gems/**) >> >> Eric: what about using TMP for fetch actions? Is feasible? > > In trunk, this should fall back to "#{Gem.user_dir}/cache" if > "#{Gem.dir}/cache" isn't writable. Are you seeing this in recent > versions? > No, I didn't push rubygems trunk to this production server so couldn't confirm and to be able to replicate the scenario require several ACLs changes. So I will trust the nice tests of RubyGems (btw, need to checkout latest and see if is working on both mswin32 and mingw32). Regards, -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From drbrain at segment7.net Wed Sep 17 21:44:44 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Sep 2008 18:44:44 -0700 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir In-Reply-To: <5cbbe4ae0809141231s3882339eh5c4958ddd1932f4d@mail.gmail.com> References: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> <7CEE971C-56E9-4471-9D92-931901092C77@segment7.net> <5cbbe4ae0809141231s3882339eh5c4958ddd1932f4d@mail.gmail.com> Message-ID: On Sep 14, 2008, at 12:31 PM, Caspar Florian Ebeling wrote: > On Fri, Sep 12, 2008 at 11:27 PM, Eric Hodel > wrote: >> On Aug 27, 2008, at 06:05 AM, Caspar Florian Ebeling wrote: >>> This seems to be a bug: >>> $ mkdir gem_stage/ >>> $ gem install --install-dir gem_stage --local externals-1.0.0.gem >>> Successfully installed externals-1.0.0 >>> 1 gem installed >>> Installing ri documentation for externals-1.0.0... >>> Installing RDoc documentation for externals-1.0.0... >>> $ gem uninstall externals --install-dir gem_stage >>> ERROR: While executing gem ... (Gem::InstallError) >>> Unknown gem externals >= 0 >>> >>> Basically, --install-dir seems to be ignored on uninstall. >> >> This seems to work on trunk. > > To me it still looks broken, unfortunately: > > flomac:vendor febeling$ rubygems-svn/bin/gem install activesupport - > i tmptrunk/ This command uses the installed rubygems, not the one in rubygems- svn. You need to use -Irubygems-svn/lib. From drbrain at segment7.net Wed Sep 17 22:16:48 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Sep 2008 19:16:48 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: <48D16ED5.3000205@phusion.nl> References: <48D16ED5.3000205@phusion.nl> Message-ID: On Sep 17, 2008, at 13:55 PM, Hongli Lai wrote: > Eric Hodel wrote: >> No. It is not cross-platform. > > Could you elaborate on this? As far as I know, there is no true > cross-platform standard on where to install user-specific files. > > Installing to ~/.local as per the XDG standard doesn't violate any > existing standards, but does follow the standards which many Unix > desktop software is already following. Installing to ~/.local > doesn't break anything. RubyGems already does sensible things to your home directory. There's no reason to change RubyGems (and thus reeducate all its users) just because there happens to be a standard out there that's popular this month/year/decade. > Besides, installing to ~/.local makes the user's home folder less > messy. RubyGems already uses dotfiles (.gem and .gemrc), so the only benefit I see is that I the user gets a ton of files or directories in ~/.local that they don't normally see instead of ~/. It would take a very large change to do this the right way, breaking up the various things RubyGems stores in ~/.gem between data, config and cache. Furthermore, XDG says nothing about what to do with libraries. From drbrain at segment7.net Wed Sep 17 22:19:08 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Sep 2008 19:19:08 -0700 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> Message-ID: On Sep 14, 2008, at 07:35 AM, Caspar Florian Ebeling wrote: > when I try to use the fetch separately, then gem fails with an error > indicating missing privileges. This should not happend because > fetch is documented as saving the gem archive to the current > directory. > > flomac:vendor febeling$ rubygems-svn/bin/gem fetch hpricot --source > http://code.whytheluckystiff.net > ERROR: While executing gem ... (Errno::EACCES) > Permission denied - /opt/local/lib/ruby/gems/1.8/cache/ > hpricot-0.6.gem > flomac:vendor febeling$ pwd > /Users/febeling/vendor > > The error references the regular location of gems, and not the local > directory. > Seems wrong to me. This test happend from the trunk version as > of today (r1868). $ ruby -Ilib bin/gem list memcache-client *** LOCAL GEMS *** $ ruby -Ilib bin/gem env path /Users/drbrain/.gem/ruby/1.8:/Library/Ruby/Gems/1.8:/System/Library/ Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 $ ruby -Ilib bin/gem fetch memcache-client Downloaded memcache-client-1.5.0 $ svnversion 1880 Don't forget -I From drbrain at segment7.net Wed Sep 17 22:21:06 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 17 Sep 2008 19:21:06 -0700 Subject: [Rubygems-developers] /etc/gemrc and GEM_PATH behaviour In-Reply-To: <48BBB367.6050108@sun.com> References: <48BBB367.6050108@sun.com> Message-ID: <4F9C690C-D773-45A7-A518-36AC421ADCB2@segment7.net> On Sep 1, 2008, at 02:18 AM, Amanda Waite wrote: > I've been working on OS level packaging of some Ruby Gems on > OpenSolaris. I had hoped to be able to use /etc/gemrc to specify the > gem search path, but I've found that setting gempath in /etc/gemrc > only affects the running of the gem command and not the running/ > loading of gems themselves. I've worked through the code as best I > can and it seems to come down to the GemRunner class creating a > Gem::ConfigFile instance which then reads the /etc/gemrc file. The > gempath and gemhome values are then pushed into the Gem.path via the > use_paths method in rubygems.rb. This code path is only used when > running the gem command. For running Gems (like rails) or loading > gems in scripts, the value for default_path is used unless GEM_PATH > is set. In this case the ConfigFile is never loaded. > > Is there any documentation that describes the intended behaviour of / > etc/gemrc? I've looked around but most of what I've found relates > to .gemrc and much of that is anecdotal. The best way to do this is to write a lib/rubygems/defaults/ operating_system.rb that overrides settings from lib/rubygems/ defaults.rb and include it with the OpenSolaris package. From florian.ebeling at gmail.com Thu Sep 18 03:10:34 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Thu, 18 Sep 2008 09:10:34 +0200 Subject: [Rubygems-developers] Bug in fetch? In-Reply-To: <87d4j2skxx.fsf@hagelb.org> References: <5cbbe4ae0809140735ufb7223areea008a293f2865e@mail.gmail.com> <87d4j2skxx.fsf@hagelb.org> Message-ID: <5cbbe4ae0809180010y72fb72c1y76993da9a17a5084@mail.gmail.com> > It looks like you may be using the "gem" executable from the bin > directory with the system-installed "lib" files. Try this instead: > > $ cd rubygems-svn > $ ruby -I:lib bin/gem fetch hpricot --source=http://code.whytheluckystiff.net > > That will ensure that you are using the lib directory from the > checkout. It's a bit confusing if you're used to bin files that set the > load path explicitly with File.dirname(__FILE__) as is common. ok, I can confirm that this solves the problem. Thanks. Florian -- Florian Ebeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Thu Sep 18 03:17:32 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Thu, 18 Sep 2008 09:17:32 +0200 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir In-Reply-To: References: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> <7CEE971C-56E9-4471-9D92-931901092C77@segment7.net> <5cbbe4ae0809141231s3882339eh5c4958ddd1932f4d@mail.gmail.com> Message-ID: <5cbbe4ae0809180017j222a74ecg5e05fdfc6d0ba976@mail.gmail.com> >>>> Basically, --install-dir seems to be ignored on uninstall. >>> >>> This seems to work on trunk. >> >> To me it still looks broken, unfortunately: >> >> flomac:vendor febeling$ rubygems-svn/bin/gem install activesupport -i >> tmptrunk/ > > This command uses the installed rubygems, not the one in rubygems-svn. You > need to use -Irubygems-svn/lib. Yes, I confirm that it works when I point onto the lib directory. Thanks! Florian -- Florian Ebeling florian.ebeling at gmail.com From nate at natemurray.com Thu Sep 18 14:02:54 2008 From: nate at natemurray.com (Nate Murray) Date: Thu, 18 Sep 2008 11:02:54 -0700 Subject: [Rubygems-developers] check gem version before gem installation? (or: how to add rubygem version dependencies now that there is no 'rubygems' gem?) Message-ID: <9c1993f20809181102l16b17674uca91cf8fbd5998ed@mail.gmail.com> Hey all, I've just created a new gem. I'm using hoe 1.7.0 and it uses the rubygems method "add_development_dependency" which was added approx rubygems 1.2.0. In order for my gem to install correctly it needs to run a rake task to finish installation. If one installs the gem with rubygems version < 1.2.0. Then 1) the gem will "install" (place files in the gems home) but 2) the rake task fails because it cannot find the method "add_development_dependency" and installation does not complete. As I understand it, I cannot just add a requirement of rubygems >= 1.2.0 because there is no longer a rubygem gem. (is this accurate?) I have the following method which will check the rubygems version: def check_rubygems_version min_version = '1.2.0' local_version = %x[gem --version].chomp unless local_version >= min_version puts "You need to update the RubyGems utility to #{min_version} using the following" puts "" puts " sudo gem update --system" exit end end check_rubygems_version My problem is this: how do I get this method to run *before* installation. For instance, when someone does "gem install natesgem" how do I have this method run and say "You need to update RubyGems ..." etc. ? The gem requirements dont seem to take a lambda, as far as I can tell. The gem specification manual comes up short as well. Any thoughts? Nate From drbrain at segment7.net Thu Sep 18 15:14:20 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 18 Sep 2008 12:14:20 -0700 Subject: [Rubygems-developers] check gem version before gem installation? (or: how to add rubygem version dependencies now that there is no 'rubygems' gem?) In-Reply-To: <9c1993f20809181102l16b17674uca91cf8fbd5998ed@mail.gmail.com> References: <9c1993f20809181102l16b17674uca91cf8fbd5998ed@mail.gmail.com> Message-ID: <9E7B1B79-1219-4F07-8CDB-80114796C5C7@segment7.net> On Sep 18, 2008, at 11:02 AM, Nate Murray wrote: > Hey all, > I've just created a new gem. I'm using hoe 1.7.0 and it uses the > rubygems method "add_development_dependency" which was added approx > rubygems 1.2.0. I don't see what this has to do with your gem. There is a bug in RubyGems 1.2 with respect to development dependencies, but gems packaged with RubyGems 1.2 are backwards compatible with older RubyGems versions. > In order for my gem to install correctly it needs to run a rake task > to finish installation. You cannot run custom code upon installation of a gem. > If one installs the gem with rubygems version > < 1.2.0. Then 1) the gem will "install" (place files in the gems home) > but 2) the rake task fails because it cannot find the method > "add_development_dependency" and installation does not complete. If the user needs to run a task after installation via the Rakefile then you need a runtime dependency on hoe. If hoe isn't backwards compatible, then you need to file a bug against hoe. > As I understand it, I cannot just add a requirement of rubygems >= > 1.2.0 because there is no longer a rubygem gem. (is this accurate?) There never was a rubygems gem you could depend on. Use Gem::Specification#required_rubygems_version=. From nate at natemurray.com Thu Sep 18 15:33:45 2008 From: nate at natemurray.com (Nate Murray) Date: Thu, 18 Sep 2008 12:33:45 -0700 Subject: [Rubygems-developers] check gem version before gem installation? (or: how to add rubygem version dependencies now that there is no 'rubygems' gem?) In-Reply-To: <9E7B1B79-1219-4F07-8CDB-80114796C5C7@segment7.net> References: <9c1993f20809181102l16b17674uca91cf8fbd5998ed@mail.gmail.com> <9E7B1B79-1219-4F07-8CDB-80114796C5C7@segment7.net> Message-ID: <9c1993f20809181233j3e058109w5dbd9ee931403b69@mail.gmail.com> Hey Eric, thanks for the quick reply. Maybe I can rephrase my question: Is it possible to 1) require the user to have a particular version of rubygems installed before they can install my gem? 2) give them a message on how to upgrade the rubygems system if they do not meet the required version Thanks, Nate On Thu, Sep 18, 2008 at 12:14 PM, Eric Hodel wrote: > On Sep 18, 2008, at 11:02 AM, Nate Murray wrote: > >> Hey all, >> I've just created a new gem. I'm using hoe 1.7.0 and it uses the >> rubygems method "add_development_dependency" which was added approx >> rubygems 1.2.0. > > I don't see what this has to do with your gem. There is a bug in RubyGems > 1.2 with respect to development dependencies, but gems packaged with > RubyGems 1.2 are backwards compatible with older RubyGems versions. > >> In order for my gem to install correctly it needs to run a rake task >> to finish installation. > > You cannot run custom code upon installation of a gem. > >> If one installs the gem with rubygems version >> < 1.2.0. Then 1) the gem will "install" (place files in the gems home) >> but 2) the rake task fails because it cannot find the method >> "add_development_dependency" and installation does not complete. > > If the user needs to run a task after installation via the Rakefile then you > need a runtime dependency on hoe. > > If hoe isn't backwards compatible, then you need to file a bug against hoe. > >> As I understand it, I cannot just add a requirement of rubygems >= >> 1.2.0 because there is no longer a rubygem gem. (is this accurate?) > > There never was a rubygems gem you could depend on. Use > Gem::Specification#required_rubygems_version=. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From thewoolleyman at gmail.com Thu Sep 18 19:23:36 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 18 Sep 2008 16:23:36 -0700 Subject: [Rubygems-developers] rubygems passing ARGV to extension builders breaks usage via API Message-ID: Hi, When building native gems, Rubygems does this: * in the gem binary, if there is a '--' arg, it clones ARGV to preserve the options * Eventually, the extension builders like ext/ext_conf_builder.rb and ext/rake_builder.rb passes the unmodified ARGV in. This causes problems when RubyGems is invoked via the GemRunner API (which happens after the binary), because there is no way to set ARGV (and you shouldn't have to anyway). I believe the right way to fix this would be to: 1. move the code to stash all args after '--' into GemRunner 2. Make it stash the args somewhere and eventually pass it down to the ext builders 3. make the ext builders use these args instead of using ARGV directly This is a problem for my project, and I believe it will be a problem for Rails too - when they remove the built-in mysql support in the near future and require the mysql gem to be used, there will be no way for config.gems to programatically pass options to the mysql gem build, which is usually required. Thanks, -- Chad From drbrain at segment7.net Thu Sep 18 19:45:50 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 18 Sep 2008 16:45:50 -0700 Subject: [Rubygems-developers] rubygems passing ARGV to extension builders breaks usage via API In-Reply-To: References: Message-ID: <1F7BEA82-7506-47F4-A046-179BFFF93301@segment7.net> On Sep 18, 2008, at 16:23 PM, Chad Woolley wrote: > When building native gems, Rubygems does this: > > * in the gem binary, if there is a '--' arg, it clones ARGV to > preserve the options > * Eventually, the extension builders like ext/ext_conf_builder.rb and > ext/rake_builder.rb passes the unmodified ARGV in. > > This causes problems when RubyGems is invoked via the GemRunner API > (which happens after the binary), because there is no way to set ARGV > (and you shouldn't have to anyway). You can set ARGV, but you shouldn't have to. $ ruby -e 'p ARGV; ARGV.replace %w[1 2 3]; p ARGV' -- a b c ["a", "b", "c"] ["1", "2", "3"] > I believe the right way to fix this would be to: > > 1. move the code to stash all args after '--' into GemRunner > 2. Make it stash the args somewhere and eventually pass it down to the > ext builders > 3. make the ext builders use these args instead of using ARGV directly 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. > This is a problem for my project, and I believe it will be a problem > for Rails too - when they remove the built-in mysql support in the > near future and require the mysql gem to be used, there will be no way > for config.gems to programatically pass options to the mysql gem > build, which is usually required. From drbrain at segment7.net Thu Sep 18 21:10:27 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 18 Sep 2008 18:10:27 -0700 Subject: [Rubygems-developers] Overriding default directories In-Reply-To: <50d9f33a0809122212v7915dd7cud0c1b47c631a37fd@mail.gmail.com> References: <50d9f33a0808171508m42eb561cu118ee201880a558d@mail.gmail.com> <50d9f33a0809122212v7915dd7cud0c1b47c631a37fd@mail.gmail.com> Message-ID: <6CCF15B1-1AFB-4362-BCA8-7465B9E83B6C@segment7.net> On Sep 12, 2008, at 22:12 PM, Neil Wilson wrote: > On 13/09/2008, Eric Hodel wrote: >> Does adding a Gem.clear_paths at the bottom of operating_system.rb >> fix the >> problem? You shouldn't touch ENV in operating_system.rb. Can you >> attach >> your operating_system.rb? > > > I'll check that, but the last time I looked the code only checked ENV > before issuing the /usr/lib directory. > > The operating_system.rb is here. > > http://github.com/NeilW/deb-rubygems/tree/master/debian/operating_system.rb I think this does what you want: -------------- next part -------------- A non-text attachment was scrubbed... Name: operating_system.rb.diff Type: application/octet-stream Size: 993 bytes Desc: not available URL: -------------- next part -------------- From drbrain at segment7.net Fri Sep 19 15:15:34 2008 From: drbrain at segment7.net (Segment 7) Date: Fri, 19 Sep 2008 12:15:34 -0700 Subject: [Rubygems-developers] Open issues for 1.3? Message-ID: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> I don't see any ctritical bugs remaining in the tracker. Is there anything else outstanding? From luislavena at gmail.com Fri Sep 19 18:46:48 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 19 Sep 2008 19:46:48 -0300 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> Message-ID: <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> On Fri, Sep 19, 2008 at 4:15 PM, Segment 7 wrote: > > I don't see any ctritical bugs remaining in the tracker. Is there anything > else outstanding? > I'm checking out latest changes and see if they work or raise errors under Windows (mswin32 and mingw32). So far, two new errors has been introduced: http://pastie.org/private/96wifrwcnzatkfqetada 1) Error: test_self_clear_paths(TestGem): NoMethodError: undefined method `uid' for nil:NilClass D:/Users/Luis/projects/oss/rubygems/trunk/test/../lib/rubygems.rb:713:in `set_paths' It's important to mention that rely on Etc to determine owner is unreliable across platforms. I cannot suggest we use File::writable? instead since under Windows, ACLs can deny you access to a specified folder and still show up as writable, as I reported to RubySpec http://groups.google.com/group/rubyspec/browse_thread/thread/2e2b21b73aca5fcc# I'll have some free time tomorrow to work on this if required. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From drbrain at segment7.net Fri Sep 19 19:02:45 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 19 Sep 2008 16:02:45 -0700 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> Message-ID: On Sep 19, 2008, at 15:46 PM, Luis Lavena wrote: > On Fri, Sep 19, 2008 at 4:15 PM, Segment 7 > wrote: >> >> I don't see any ctritical bugs remaining in the tracker. Is there >> anything >> else outstanding? > > I'm checking out latest changes and see if they work or raise errors > under Windows (mswin32 and mingw32). > > So far, two new errors has been introduced: > > http://pastie.org/private/96wifrwcnzatkfqetada > > 1) Error: > test_self_clear_paths(TestGem): > NoMethodError: undefined method `uid' for nil:NilClass > D:/Users/Luis/projects/oss/rubygems/trunk/test/../lib/rubygems.rb: > 713:in > `set_paths' > > It's important to mention that rely on Etc to determine owner is > unreliable across platforms. > > I cannot suggest we use File::writable? instead since under Windows, > ACLs can deny you access to a specified folder and still show up as > writable, as I reported to RubySpec > > http://groups.google.com/group/rubyspec/browse_thread/thread/2e2b21b73aca5fcc# > > I'll have some free time tomorrow to work on this if required. Please do. In this case, writable is not a good enough test for unix. I don't want root to create a directory in a non-root user's home directory (in case of sudo gem whatever). From djberg96 at gmail.com Fri Sep 19 19:02:51 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Fri, 19 Sep 2008 17:02:51 -0600 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> Message-ID: <6037b70c0809191602k28e3a1dbgb2d9cbd0c4258285@mail.gmail.com> On Fri, Sep 19, 2008 at 4:46 PM, Luis Lavena wrote: > On Fri, Sep 19, 2008 at 4:15 PM, Segment 7 wrote: >> >> I don't see any ctritical bugs remaining in the tracker. Is there anything >> else outstanding? >> > > I'm checking out latest changes and see if they work or raise errors > under Windows (mswin32 and mingw32). > > So far, two new errors has been introduced: > > http://pastie.org/private/96wifrwcnzatkfqetada > > 1) Error: > test_self_clear_paths(TestGem): > NoMethodError: undefined method `uid' for nil:NilClass > D:/Users/Luis/projects/oss/rubygems/trunk/test/../lib/rubygems.rb:713:in > `set_paths' > > It's important to mention that rely on Etc to determine owner is > unreliable across platforms. > > I cannot suggest we use File::writable? instead since under Windows, > ACLs can deny you access to a specified folder and still show up as > writable, as I reported to RubySpec > > http://groups.google.com/group/rubyspec/browse_thread/thread/2e2b21b73aca5fcc# We could add ACL based implementations for owned?, readable?, writeable? and executable? in win32-file if you're interested. Also keep in mind that, technically, other platforms implement ACL as well, which could be problematic. Regards, Dan From luislavena at gmail.com Fri Sep 19 19:13:34 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 19 Sep 2008 20:13:34 -0300 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <6037b70c0809191602k28e3a1dbgb2d9cbd0c4258285@mail.gmail.com> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> <6037b70c0809191602k28e3a1dbgb2d9cbd0c4258285@mail.gmail.com> Message-ID: <71166b3b0809191613u18e2f899waab002e9563e6e85@mail.gmail.com> On Fri, Sep 19, 2008 at 8:02 PM, Daniel Berger wrote: > On Fri, Sep 19, 2008 at 4:46 PM, Luis Lavena wrote: >> On Fri, Sep 19, 2008 at 4:15 PM, Segment 7 wrote: >>> >>> I don't see any ctritical bugs remaining in the tracker. Is there anything >>> else outstanding? >>> >> >> I'm checking out latest changes and see if they work or raise errors >> under Windows (mswin32 and mingw32). >> >> So far, two new errors has been introduced: >> >> http://pastie.org/private/96wifrwcnzatkfqetada >> >> 1) Error: >> test_self_clear_paths(TestGem): >> NoMethodError: undefined method `uid' for nil:NilClass >> D:/Users/Luis/projects/oss/rubygems/trunk/test/../lib/rubygems.rb:713:in >> `set_paths' >> >> It's important to mention that rely on Etc to determine owner is >> unreliable across platforms. >> >> I cannot suggest we use File::writable? instead since under Windows, >> ACLs can deny you access to a specified folder and still show up as >> writable, as I reported to RubySpec >> >> http://groups.google.com/group/rubyspec/browse_thread/thread/2e2b21b73aca5fcc# > > We could add ACL based implementations for owned?, readable?, > writeable? and executable? in win32-file if you're interested. > That's a chicken-egg situation: verify if the home folder is writable to be able to install a gem will depend on a gem to do the job :-) > Also keep in mind that, technically, other platforms implement ACL as > well, which could be problematic. > Exactly my point, we are doing a platform-specific stuff there (uid comparison) is something that shouldn't be. > Regards, > > Dan Thanks for the offer Daniel, and I think adding those to win32-file will be great since ruby under Windows is blind in relation to ACLs. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From thewoolleyman at gmail.com Sat Sep 20 04:01:11 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 20 Sep 2008 01:01:11 -0700 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> Message-ID: On Fri, Sep 19, 2008 at 12:15 PM, Segment 7 wrote: > > I don't see any ctritical bugs remaining in the tracker. Is there anything > else outstanding? My tests are green... From djberg96 at gmail.com Sat Sep 20 09:06:00 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Sat, 20 Sep 2008 07:06:00 -0600 Subject: [Rubygems-developers] Open issues for 1.3? In-Reply-To: <71166b3b0809191613u18e2f899waab002e9563e6e85@mail.gmail.com> References: <9FF49A1E-96C2-42D1-B062-F2AC2A035930@segment7.net> <71166b3b0809191546l1e799e53tcd5e99be8352d6b6@mail.gmail.com> <6037b70c0809191602k28e3a1dbgb2d9cbd0c4258285@mail.gmail.com> <71166b3b0809191613u18e2f899waab002e9563e6e85@mail.gmail.com> Message-ID: <48D4F538.10905@gmail.com> Luis Lavena wrote: >>> I cannot suggest we use File::writable? instead since under Windows, >>> ACLs can deny you access to a specified folder and still show up as >>> writable, as I reported to RubySpec >>> >>> http://groups.google.com/group/rubyspec/browse_thread/thread/2e2b21b73aca5fcc# >> We could add ACL based implementations for owned?, readable?, >> writeable? and executable? in win32-file if you're interested. >> > > That's a chicken-egg situation: verify if the home folder is writable > to be able to install a gem will depend on a gem to do the job :-) Except that you ship the one-click with win32-file, right? So, we're starting with chicken. :) >> Also keep in mind that, technically, other platforms implement ACL as >> well, which could be problematic. >> > > Exactly my point, we are doing a platform-specific stuff there (uid > comparison) is something that shouldn't be. Ok. > Thanks for the offer Daniel, and I think adding those to win32-file > will be great since ruby under Windows is blind in relation to ACLs. I don't think we'll get them done in time for 1.3.0, though, so don't let it hold up this release. Something to consider for the next release perhaps. Regards, Dan From jeremy at hinegardner.org Mon Sep 22 13:01:51 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Mon, 22 Sep 2008 11:01:51 -0600 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? Message-ID: <20080922170151.GU804@hinegardner.org> Hi all, I was doing some investigation on gem repositories and I discovered something on the gems.rubyforge.org repository. It appears that any gem that is not a Gem::Platform::RUBY has different platform values between the Marshal.4.8 file and the specs.4.8 file. For instance in the hpricot gem: Marshal non-RUBY gems hpricot-0.4-x86-mswin32 hpricot-0.5-x86-mswin32 hpricot-0.6-java hpricot-0.6-x86-mswin32 hpricot-0.6.161-java Specs non-RUBY gems hpricot-0.4-mswin32 hpricot-0.5-mswin32 hpricot-0.6-jruby hpricot-0.6-mswin32 hpricot-0.6.161-jruby The fun part here is that the none of the Marshal named gems exist at the source_uri/gems/full_name.gem path, only those that are in Specs exist Is this the correct behavior? Is the Marshal.4.8.Z file to not be used to determine the path to gems? Should I only access the specs.4.8 and latest_specs.4.8 ? Here's the sample program I was using: http://p.ramaze.net/2017 enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From drbrain at segment7.net Mon Sep 22 15:28:15 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 22 Sep 2008 12:28:15 -0700 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? In-Reply-To: <20080922170151.GU804@hinegardner.org> References: <20080922170151.GU804@hinegardner.org> Message-ID: <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> On Sep 22, 2008, at 10:01 AM, Jeremy Hinegardner wrote: > Hi all, > > I was doing some investigation on gem repositories and I discovered > something on the gems.rubyforge.org repository. > > It appears that any gem that is not a Gem::Platform::RUBY has > different > platform values between the Marshal.4.8 file and the specs.4.8 file. > > For instance in the hpricot gem: > > Marshal non-RUBY gems > hpricot-0.4-x86-mswin32 > hpricot-0.5-x86-mswin32 > hpricot-0.6-java > hpricot-0.6-x86-mswin32 > hpricot-0.6.161-java > > Specs non-RUBY gems > hpricot-0.4-mswin32 > hpricot-0.5-mswin32 > hpricot-0.6-jruby > hpricot-0.6-mswin32 > hpricot-0.6.161-jruby > > > The fun part here is that the none of the Marshal named gems exist > at the > source_uri/gems/full_name.gem path, only those that are in Specs exist > > Is this the correct behavior? The Marshal file has both platform and original_platform. original_platform is used to find the file to download since legacy gems haven't been renamed (on disk) to be found properly. specs has only original_platform so it can be as lightweight as possible. Combining name, version and platform gives you the name of a .gemspec file to download that will give you a Gem::Specification with all the information. RubyGems knows how to turn original_platform into platform in order to match up with the figure-out-your-platform code (at least, for gems released before the figure-it-out code was written). > Is the Marshal.4.8.Z file to not be used to determine the path to > gems? Use Gem::Specification#original_platform instead of #platform if you have a Gem::Specification. Best is to use #full_name. > Should I only access the specs.4.8 and latest_specs.4.8 ? You should use Gem::SpecFetcher which handles caching for you and is easiest on bandwidth. Don't use Gem::SourceInfoCache as it is deprecated and eventually will be removed. (Code to do a bulk fetch of the Marshal file will stick around, since it is useful for doing things with the entire repository. I'm not sure if I've put in an interface to that separate from SourceInfoCache.) From jeremy at hinegardner.org Mon Sep 22 15:58:46 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Mon, 22 Sep 2008 13:58:46 -0600 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? In-Reply-To: <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> References: <20080922170151.GU804@hinegardner.org> <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> Message-ID: <20080922195846.GW804@hinegardner.org> On Mon, Sep 22, 2008 at 12:28:15PM -0700, Eric Hodel wrote: > On Sep 22, 2008, at 10:01 AM, Jeremy Hinegardner wrote: >> Hi all, >> >> The fun part here is that the none of the Marshal named gems exist at the >> source_uri/gems/full_name.gem path, only those that are in Specs exist >> >> Is this the correct behavior? > > The Marshal file has both platform and original_platform. > original_platform is used to find the file to download since legacy gems > haven't been renamed (on disk) to be found properly. > > specs has only original_platform so it can be as lightweight as possible. > Combining name, version and platform gives you the name of a .gemspec file > to download that will give you a Gem::Specification with all the > information. > > RubyGems knows how to turn original_platform into platform in order to > match up with the figure-out-your-platform code (at least, for gems > released before the figure-it-out code was written). knowing the difference between original_platform and platform would be the issue I was having. Thank you. >> Is the Marshal.4.8.Z file to not be used to determine the path to gems? > > Use Gem::Specification#original_platform instead of #platform if you have a > Gem::Specification. Best is to use #full_name. > >> Should I only access the specs.4.8 and latest_specs.4.8 ? > > You should use Gem::SpecFetcher which handles caching for you and is > easiest on bandwidth. Don't use Gem::SourceInfoCache as it is deprecated > and eventually will be removed. (Code to do a bulk fetch of the Marshal > file will stick around, since it is useful for doing things with the entire > repository. I'm not sure if I've put in an interface to that separate from > SourceInfoCache.) Thanks for all the info Eric, and all the work on rubygems. I'm working on a project that merges multiple gem repositories ( public and private ) into a single repository for use as an internal gem distribution server. It is akin to 'gem mirror' with the ability to restrict to a certain set of gems and specific versions of those gems. I should have a release here in the next few days. For those interested: http://github.com/copiousfreetime/stickler/tree/master If any of what I'm doing would be useful to incorporate back into 'gem mirror' I'm happy to contribute. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From drbrain at segment7.net Mon Sep 22 22:42:04 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 22 Sep 2008 19:42:04 -0700 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? In-Reply-To: <20080922195846.GW804@hinegardner.org> References: <20080922170151.GU804@hinegardner.org> <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> <20080922195846.GW804@hinegardner.org> Message-ID: On Sep 22, 2008, at 12:58 PM, Jeremy Hinegardner wrote: > If any of what I'm doing would be useful to incorporate back into 'gem > mirror' I'm happy to contribute. I'd really like to nuke gem mirror. Rsync is much better, at least for rubyforge.org. If there was a viable project outside RubyGems that did it I wouldn't mind removing the feature. From jeremy at hinegardner.org Tue Sep 23 03:00:54 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Tue, 23 Sep 2008 01:00:54 -0600 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? In-Reply-To: References: <20080922170151.GU804@hinegardner.org> <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> <20080922195846.GW804@hinegardner.org> Message-ID: <20080923070054.GZ804@hinegardner.org> On Mon, Sep 22, 2008 at 07:42:04PM -0700, Eric Hodel wrote: > > On Sep 22, 2008, at 12:58 PM, Jeremy Hinegardner wrote: > >> If any of what I'm doing would be useful to incorporate back into 'gem >> mirror' I'm happy to contribute. > > I'd really like to nuke gem mirror. Rsync is much better, at least for > rubyforge.org. If there was a viable project outside RubyGems that did it > I wouldn't mind removing the feature. I'll announce here when stickler has a viable release, and we can all discuss. Shouldn't be too long. I agree, rsync is a much better tool for wholesale mirroring. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From thewoolleyman at gmail.com Tue Sep 23 04:29:24 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 23 Sep 2008 01:29:24 -0700 Subject: [Rubygems-developers] differing platforms values between Marshal.4.8 and spec.4.8 ? In-Reply-To: References: <20080922170151.GU804@hinegardner.org> <71BDF2FA-DFB1-43F0-B9C1-9447B10A1D8C@segment7.net> <20080922195846.GW804@hinegardner.org> Message-ID: On Mon, Sep 22, 2008 at 7:42 PM, Eric Hodel wrote: > I'd really like to nuke gem mirror. Rsync is much better, at least for > rubyforge.org. If there was a viable project outside RubyGems that did it I > wouldn't mind removing the feature. Off topic, but is there any tool which does good bi-directional mirroring? I used Unison once, but it seemed overly complicated... From greg.hauptmann.ruby at gmail.com Tue Sep 23 08:17:27 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Tue, 23 Sep 2008 22:17:27 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: still having problems here - latest example is when I've tried to install hobo - any suggestions would be great ------- Macintosh-2:gems greg$ sudo gem install hobo --debug Exception `NameError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem::Commands::InstallCommand Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/latest_specs.4.8.gz) WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Net::HTTPBadResponse' at /opt/local/lib/ruby/1.8/net/http.rb:2019 - wrong status line: "\037\213\b\000bw\330H\000\003t\275[\214dIv\030\246\316\231\235\251G\326\273\252\237\263K\262\305E\233\024\262\267+\253\372\265\326\200\325\323=\3233\313\351\236aW\357,\265\244\234\270y\357\315\314\250\274\257\276qoee\211\322J\346\032\246L\020X\031\342\227\370c\211\260\260?\262E\2024\0264\r\202\206-\2004`\303\302B\006lQ\004l\200?\006\210\305\332\373aC\262\3179q\316\211\310\352Y\314tw\306\211\270q\343\306\343\304y\2377\227~\251\363\335\365_Z\272\331}\364\374\345\a\217^<\373\372W\267\236\246\371W\277\372YZ[S\026\277\364\326\315\225;\267\373\267\357\334\\\256\333\341\034\032\336x\0247\3464}b\3524n\312z\376AY\277\200\232\257\377\373\177\305\265\335\277\375\340h\025\332]v\355^\244qY'\275\257=y\357\261k\262t\347\366]j\260\r\r\354#\373\276\215\243*M\364yx\eU_u\325\037D\266y\236\332&M\216\323&x\311]n\224$uj\355{e9\375(\257\312\272Ik\327h\025{\332?\240V\327\037%\271)\214m\352\b\373\211\243\321\250\314\3027\356S\263\235GIException `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/quick/latest_index.rz) Updating metadata for 96 gems from http://gems.rubyforge.org/ Exception `TypeError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:488 - incompatible marshal file format (can't be read) format version 4.8 required; 65.78 given Exception `NoMethodError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172 - undefined method `full_name' for # ERROR: While executing gem ... (NoMethodError) undefined method `full_name' for # /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172:in `add_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:523:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:355:in `update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:42:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:249:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:41:in `cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:86:in `search_with_source' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:72:in `fetch' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:242:in `warn_legacy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:69:in `fetch' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:94:in `find_gems_with_sources' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:187:in `find_spec_by_name_and_version' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:208:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:73:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' /opt/local/bin/gem:24 Macintosh-2:gems greg$ ------ On Sat, Sep 13, 2008 at 6:42 AM, Eric Hodel wrote: > On Sep 11, 2008, at 20:49 PM, Greg Hauptmann wrote: > >> Tks Eric, so does this mean I'm really up for a manual install...can >> one do manual gem installs? do you think I should raise an issue with >> my ISP, however I'm not exactly sure how I'd phase the support >> request? > > You could try: > > gem install -V some_gem > > It should print out what RubyGems tried to fetch and what response was > received, then use something like curl -I URL to see if RubyGems is insane > or not. > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From greg.hauptmann.ruby at gmail.com Tue Sep 23 17:56:02 2008 From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann) Date: Wed, 24 Sep 2008 07:56:02 +1000 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: PSS. another example: Macintosh-2:myequity greg$ sudo gem install hobo --debug Password: Exception `NameError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:134 - uninitialized constant Gem: :Commands::InstallCommand Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/latest_specs.4.8.gz) WARNING: RubyGems 1.2+ index not found for: RubyGems will revert to legacy indexes degrading performance. Exception `Net::HTTPBadResponse' at /opt/local/lib/ruby/1.8/net/http.rb:2019 - wrong status line: "\037\213\b\000\236X\331H\000\003t\275[\214dIv\030\246\316\231\235\251G\326\273\252\237\263Kn\213\213\026idoWV\365k\355\001\253\247{\246g\226\323=\303\256\336\035\212\244\234\270y\357\315\314\250\274\257\276qoee\221\366\222\342~P\022\b\254\f\361K\004\f\233\004\204\375\260(\311 \215\005M\203\240a\v \r\330\220\274\260\rC\024\r\177\b\376\"\026\v\257\r\030\262}\316\211sNDV\317b\246\2733N\304\215\e7\036'\316\373\274\271\364K\235\357\256\377\322\322\315\356\243\347/?x\364\342\3317\276\266\3654\315\277\366\265o\246\2655e\361Ko\335\\\271s\273\177\373\316\315\345\272\035\316\241\341\215GqcN\323'\246N\343\246\254\347\037\224\365\v\250\371\306\277\373\327\\\333\375\333\017\216V\241\335e\327\356E\032\227u\322\373\372\223\367\036\273&Kwn\337\245\006\333\320\300>\262\357\3338\252\322D\237\207\267Q\365UW\375Ad\233\347\251m\322\3448m\202\227\334\345FIR\247\326\276W\226\323\217\362\252\254\233\264v\215V\261\247\375\003ju\375Q\22Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution expired Exception `Gem::RemoteFetcher::FetchError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - timed out (http://gems.rubyforge.org/quick/latest_index.rz) Updating metadata for 98 gems from http://gems.rubyforge.org/ Exception `TypeError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:488 - incompatible marshal file format (can't be read) format version 4.8 required; 65.78 given Exception `NoMethodError' at /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172 - undefined method `full_name' for # ERROR: While executing gem ... (NoMethodError) undefined method `full_name' for # /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172:in `add_spec' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:523:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `update_with_missing' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:355:in `update' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:42:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:249:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in `refresh' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:41:in `cache' /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:86:in `search_with_source' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:72:in `fetch' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:242:in `warn_legacy' /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:69:in `fetch' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:94:in `find_gems_with_sources' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:187:in `find_spec_by_name_and_version' /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:208:in `install' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:73:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in `each' /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in `execute' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in `process_args' /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in `run' /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' /opt/local/bin/gem:24 Macintosh-2:myequity greg$ On Tue, Sep 23, 2008 at 10:17 PM, Greg Hauptmann wrote: > still having problems here - latest example is when I've tried to > install hobo - any suggestions would be great > > ------- > Macintosh-2:gems greg$ sudo gem install hobo --debug > Exception `NameError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:134 - > uninitialized constant Gem::Commands::InstallCommand > Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - > execution expired > Exception `Gem::RemoteFetcher::FetchError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - > timed out (http://gems.rubyforge.org/latest_specs.4.8.gz) > WARNING: RubyGems 1.2+ index not found for: > > > RubyGems will revert to legacy indexes degrading performance. > Exception `Net::HTTPBadResponse' at > /opt/local/lib/ruby/1.8/net/http.rb:2019 - wrong status line: > "\037\213\b\000bw\330H\000\003t\275[\214dIv\030\246\316\231\235\251G\326\273\252\237\263K\262\305E\233\024\262\267+\253\372\265\326\200\325\323=\3233\313\351\236aW\357,\265\244\234\270y\357\315\314\250\274\257\276qoee\211\322J\346\032\246L\020X\031\342\227\370c\211\260\260?\262E\2024\0264\r\202\206-\2004`\303\302B\006lQ\004l\200?\006\210\305\332\373aC\262\3179q\316\211\310\352Y\314tw\306\211\270q\343\306\343\304y\2377\227~\251\363\335\365_Z\272\331}\364\374\345\a\217^<\373\372W\267\236\246\371W\277\372YZ[S\026\277\364\326\315\225;\267\373\267\357\334\\\256\333\341\034\032\336x\0247\3464}b\3524n\312z\376AY\277\200\232\257\377\373\177\305\265\335\277\375\340h\025\332]v\355^\244qY'\275\257=y\357\261k\262t\347\366]j\260\r\r\354#\373\276\215\243*M\364yx\eU_u\325\037D\266y\236\332&M\216\323&x\311]n\224$uj\355{e9\375(\257\312\272Ik\327h\025{\332?\240V\327\037%\271)\214m\352\b\373\211\243\321\250\314\3027\356S\263\235GIException > `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - execution > expired > Exception `Gem::RemoteFetcher::FetchError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - > timed out (http://gems.rubyforge.org/quick/latest_index.rz) > Updating metadata for 96 gems from http://gems.rubyforge.org/ > Exception `TypeError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:488 - > incompatible marshal file format (can't be read) > format version 4.8 required; 65.78 given > Exception `NoMethodError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172 - > undefined method `full_name' for # > ERROR: While executing gem ... (NoMethodError) > undefined method `full_name' for # > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:172:in > `add_spec' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:523:in > `update_with_missing' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in `each' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:517:in > `update_with_missing' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:355:in > `update' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache_entry.rb:42:in > `refresh' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:249:in > `refresh' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in > `each' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:242:in > `refresh' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:41:in > `cache' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:86:in > `search_with_source' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:72:in `fetch' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:242:in > `warn_legacy' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/spec_fetcher.rb:69:in `fetch' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:94:in > `find_gems_with_sources' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:187:in > `find_spec_by_name_and_version' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/dependency_installer.rb:208:in > `install' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:73:in > `execute' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in > `each' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/commands/install_command.rb:70:in > `execute' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:136:in `invoke' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:105:in > `process_args' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:75:in > `run' > /opt/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:39:in `run' > /opt/local/bin/gem:24 > Macintosh-2:gems greg$ > > ------ > > On Sat, Sep 13, 2008 at 6:42 AM, Eric Hodel wrote: >> On Sep 11, 2008, at 20:49 PM, Greg Hauptmann wrote: >> >>> Tks Eric, so does this mean I'm really up for a manual install...can >>> one do manual gem installs? do you think I should raise an issue with >>> my ISP, however I'm not exactly sure how I'd phase the support >>> request? >> >> You could try: >> >> gem install -V some_gem >> >> It should print out what RubyGems tried to fetch and what response was >> received, then use something like curl -I URL to see if RubyGems is insane >> or not. >> _______________________________________________ >> Rubygems-developers mailing list >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > From drbrain at segment7.net Wed Sep 24 02:09:28 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 23 Sep 2008 23:09:28 -0700 Subject: [Rubygems-developers] rubygems / http://gems.rubyforge.org/ stability (RubyGems will revert to legacy indexes degrading performance) In-Reply-To: References: <24150376-775B-4460-BC83-8034A5CF8023@segment7.net> Message-ID: On Sep 23, 2008, at 05:17 AM, Greg Hauptmann wrote: > Macintosh-2:gems greg$ sudo gem install hobo --debug > Exception `NameError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:134 - > uninitialized constant Gem::Commands::InstallCommand > Exception `Timeout::Error' at /opt/local/lib/ruby/1.8/timeout.rb:54 - > execution expired > Exception `Gem::RemoteFetcher::FetchError' at > /opt/local/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb:142 - > timed out (http://gems.rubyforge.org/latest_specs.4.8.gz) > WARNING: RubyGems 1.2+ index not found for: > > > RubyGems will revert to legacy indexes degrading performance. > Exception `Net::HTTPBadResponse' at > /opt/local/lib/ruby/1.8/net/http.rb:2019 - wrong status line: > "\037\213\b\000bw\330H This exposed a bug where RubyGems needs to close the socket for timed- out requests (in case data arrives after the timeout, like the gzip data shown here). Asside from that, how long does it take to get the WARNING message? Can you run like: gem install hobo --debug -V I'd like to see if there's a particular host you're having a problem with. From luislavena at gmail.com Fri Sep 26 15:49:54 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 26 Sep 2008 16:49:54 -0300 Subject: [Rubygems-developers] Rails warnings after update to 1.3.0 Message-ID: <71166b3b0809261249m54dcd837n62119281a1befe0c@mail.gmail.com> It seems Rails boot.rb will need to be updated before the new release since 1.3.0 is warning about it: Gem::SourceIndex#search support for String patterns is deprecated ./script/../config/boot.rb:25 is outdated Maybe this should be forward to Rails LightHouse? Tried to find in rails source code about it, without any chance to find if it was changed in github. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From luislavena at gmail.com Fri Sep 26 15:58:55 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 26 Sep 2008 16:58:55 -0300 Subject: [Rubygems-developers] Rails warnings after update to 1.3.0 In-Reply-To: <71166b3b0809261249m54dcd837n62119281a1befe0c@mail.gmail.com> References: <71166b3b0809261249m54dcd837n62119281a1befe0c@mail.gmail.com> Message-ID: <71166b3b0809261258k333e1976qc8d4cfa743642ae6@mail.gmail.com> On Fri, Sep 26, 2008 at 4:49 PM, Luis Lavena wrote: > It seems Rails boot.rb will need to be updated before the new release > since 1.3.0 is warning about it: > > Gem::SourceIndex#search support for String patterns is deprecated > ./script/../config/boot.rb:25 is outdated > > Maybe this should be forward to Rails LightHouse? > > Tried to find in rails source code about it, without any chance to > find if it was changed in github. Disregard this warning. Looks like was long time since Rails for me... Since 2.1 finding raisl gem uses the gem command instead of cache.search -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From drbrain at segment7.net Fri Sep 26 17:00:32 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 26 Sep 2008 14:00:32 -0700 Subject: [Rubygems-developers] [ANN] RubyGems 1.3.0 Message-ID: <05035D93-33D5-4CAB-B196-0A96AA75EDED@segment7.net> Note! Some versions of RubyGems have a bug that will prevent automatic updates. If RubyGems says it has nothing to update, run: $ gem install rubygems-update $ update_rubygems = Announce: RubyGems Release 1.3.0 Release 1.3.0 adds new features and fixes some bugs. New features: * RubyGems doesn't print LOCAL/REMOTE titles for `gem query` and friends if stdout is not a TTY, except with --both. * Added Gem.find_files, allows a gem to discover features provided by other gems. * Added pre/post (un)install hooks for packagers of RubyGems. (Not for gems themselves). * RubyGems now installs gems into ~/.gem if GEM_HOME is not writable. Use --no-user-install command-line switch to disable this behavior. * Fetching specs for update now uses If-Modified-Since requests. * RubyGems now updates the ri cache when the rdoc gem is installed and documentation is generated. Deprecation Notices: * Gem::manage_gems now warns when called. It will be removed on or after March 2009. Bugs Fixed: * RubyGems 1.3.0+ now updates when no previous rubygems-update is installed. Bug #20775 by Hemant Kumar. * RubyGems now uses the regexp we already have for `gem list -- installed`. Bug #20876 by Nick Hoffman. * Platform is now forced to Gem::Platform::RUBY when nil or blank in the indexer. Fixes various uninstallable gems. * Handle EINVAL on seek. Based on patch in bug #20791 by Neil Wilson. * Fix HTTPS support. Patch #21072 by Alex Arnell. * RubyGems now loads all cache files even if latest has been loaded. Bug #20776 by Uwe Kubosch. * RubyGems checks for support of development dependencies for #to_ruby. Bug #20778 by Evan Weaver. * Now specifications from the future can be loaded. * Binary script uninstallation fixed. Bug #21234 by Neil Wilson. * Uninstallation with -i fixed. Bug #20812 by John Clayton. * Gem::Uninstaller#remove_all now calls Gem::Uninstaller#uninstall_gem so hooks get called. Bug #21242 by Neil Wilson. * Gem.ruby now properly escaped on windows. Fixes problem with extension compilation. * `gem lock --strict` works again. Patch #21814 by Sven Engelhardt. * Platform detection for Solaris was improved. Patch #21911 by Bob Remeika. Other Changes Include: * `gem help install` now describes _version_ argument to executable stubs * `gem help environment` describes environment variables and ~/.gemrc and /etc/gemrc * On-disk gemspecs are now read in UTF-8 and written with a UTF-8 magic comment * Rakefile * If the SETUP_OPTIONS environment variable is set, pass its contents as arguments to setup.rb * lib/rubygems/platform.rb * Remove deprecated constant warnings and really deprecate them. (WIN32, etc). * lib/rubygems/remote_fetcher.rb * Now uses ~/.gem/cache if the cache dir in GEM_HOME is not writable. * lib/rubygems/source_index.rb * Deprecate options to 'search' other than Gem::Dependency instances and issue warning until November 2008. * setup.rb * --destdir folder structure now built using Pathname, so it works for Windows platforms. * test/* * Fixes to run tests when under test/rubygems/. Patch by Yusuke ENDOH [ruby-core:17353]. * test/test_ext_configure_builder.rb * Locale-free patch by Yusuke Endoh [ruby-core:17444]. For a full list of changes to RubyGems and the contributor for each change, see the ChangeLog file. Special thanks to Chad Wooley for backwards compatibility testing and Luis Lavena for continuing windows support. == How can I get RubyGems? NOTE: If you have installed RubyGems using a package system you may want to install a new RubyGems through the same packaging system. If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is: $ gem update --system (you might need to be admin/root) NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no rubygems-update installed. You will need to follow the second set of update instructions if you see "Nothing to update". NOTE: You may have to run the command twice if you have any previosly installed rubygems-update gems. If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update (again, might need to be admin/root) $ update_rubygems (... here too) If you don't have any gems install, there is still the pre-gem approach to getting software ... doing it manually: 1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126 2. UNPACK INTO A DIRECTORY AND CD THERE 3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege) == To File Bugs The RubyGems bug tracker can be found on RubyForge at: 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`. == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From rubygems at freeze.org Tue Sep 30 15:14:58 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 14:14:58 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name Message-ID: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> Hi Some of the local ruby guys are starting to complain about the fact that they can't derive the require name from the gem name. Has this topic been brought up before? Are there opinions on how/if this can be solved? Eric, do you have an opinion on this? Thanks -- Jim Freeze From luislavena at gmail.com Tue Sep 30 15:47:24 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 30 Sep 2008 17:47:24 -0200 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> Message-ID: <71166b3b0809301247v48a01505veb84711e7659e282@mail.gmail.com> On Tue, Sep 30, 2008 at 5:14 PM, Jim Freeze wrote: > Hi > > Some of the local ruby guys are starting to complain about the fact > that they can't derive the require name from the gem name. > > Has this topic been brought up before? Are there opinions on how/if > this can be solved? > > Eric, do you have an opinion on this? > > Thanks I think that's a developer issue and not a RubyGems problem. This discussion is also raised in rspec-devel list, and the goal is change the top level module from 'spec' to 'rspec' to match the gem name. But that's a developer or team decision and RubyGems should not play magic for you and be transparent as possible. If you have 200 gems installed is very expensive just for RubyGems the first require to determine in which gem the file exist to be able to require it... Just my two cents. -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From Daniel.Berger at qwest.com Tue Sep 30 15:42:41 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 30 Sep 2008 14:42:41 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514D57@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Jim Freeze > Sent: Tuesday, September 30, 2008 1:15 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] Gem Names not correlated to > require name > > Hi > > Some of the local ruby guys are starting to complain about > the fact that they can't derive the require name from the gem name. > > Has this topic been brought up before? Are there opinions on > how/if this can be solved? I think it's really up to the gem authors to name their gems appropriately. I feel their pain, though. I know it drives me batty when I try to install "net-ldap", for example, and it fails because I forgot the gem name is "ruby-net-ldap". Good thing there's a "ruby" in the gem name - wouldn't want to accidentally install a Perl module, eh? ;) The only solution I have is to use "gem search --remote ldap", for example. You can usually figure out the "real" name from the resulting list. 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 halostatue at gmail.com Tue Sep 30 16:24:56 2008 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 30 Sep 2008 16:24:56 -0400 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514D57@ITOMAE2KM01.AD.QINTRA.COM> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <7524A45A1A5B264FA4809E2156496CFB04514D57@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <9e7db9110809301324v71abe084i11f4dc77cd3fc7c3@mail.gmail.com> On Tue, Sep 30, 2008 at 3:42 PM, Berger, Daniel wrote: > I feel their pain, though. I know it drives me batty when I try to > install "net-ldap", for example, and it fails because I forgot the gem > name is "ruby-net-ldap". Good thing there's a "ruby" in the gem name - > wouldn't want to accidentally install a Perl module, eh? ;) For that, post a bug on the Net::LDAP tracker. We'll change it with the next release and keep ruby-net-ldap around as something that just depends on 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 transfire at gmail.com Tue Sep 30 16:45:09 2008 From: transfire at gmail.com (Trans) Date: Tue, 30 Sep 2008 13:45:09 -0700 (PDT) Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> Message-ID: <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> On Sep 30, 3:14?pm, "Jim Freeze" wrote: > Hi > > Some of the local ruby guys are starting to complain about the fact > that they can't derive the require name from the gem name. > > Has this topic been brought up before? Are there opinions on how/if > this can be solved? This is more of an issue with the Ruby require system itself. There is no necessary correlation between package name, load name or module name. It's annoying in some respects. I especially find it bothersome that one package can override another because they used the same lib path (ie. load space). That's kind of dangerous, but in practice the problem doesn't really arise b/c we developers know better and more or less manually correspond our package names and lib names. It's something developers really need to police themselves about unless they have a specific reason not to. One such reason could be for "plugins" --eg. say I want to make a template for rdoc. I could add rdoc/generators/template/html/mytemplate.rb to my package's load space and it might work (depending on how Rdoc works). However, while that is a potential use, I'm not sure anyone is using it that way (Anyone?). Nor am I sure it's a good idea to do things that way regardless. And if that is the case, well, then arguably this lack of correspondence is just a useless danger. But getting rid of it would mean changing the way Ruby searches for libs. T. From rubygems at freeze.org Tue Sep 30 16:51:32 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 15:51:32 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> Message-ID: <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> One way (just one, mind you) is that if require_gem really required the gem. So, you would have require_gem 'gem_name_here' and the gem did the requiring of the files internal. Just a thought. -- Jim Freeze From halostatue at gmail.com Tue Sep 30 17:07:20 2008 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 30 Sep 2008 17:07:20 -0400 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> Message-ID: <9e7db9110809301407x2c1b17bdv8fe6f44f4eddae80@mail.gmail.com> On Tue, Sep 30, 2008 at 4:51 PM, Jim Freeze wrote: > One way (just one, mind you) is that if require_gem really required > the gem. So, you would have > > require_gem 'gem_name_here' > > and the gem did the requiring of the files internal. > > Just a thought. No, no no no no. That's what it used to do (with autoload). This is bad, bad, bad, bad, bad. (Which is why it was deprecated.) You shouldn't be using "require_gem" anyway; you should be using "gem" to activate particular gems/versions. I'd suggest that good practice would be including a dummy file that matches your gem name, if appropriate. That is, if I were to do this with PDF::Writer, I would make it so that you could "require 'pdf-writer'" (since that's the name of the gem), instead of "pdf/writer". Not sure if it matters enough, though. -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 rubygems at freeze.org Tue Sep 30 17:15:46 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 16:15:46 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <9e7db9110809301407x2c1b17bdv8fe6f44f4eddae80@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <9e7db9110809301407x2c1b17bdv8fe6f44f4eddae80@mail.gmail.com> Message-ID: <5cd596d60809301415s4a4b46cbsfee9bfabe791a76a@mail.gmail.com> On Tue, Sep 30, 2008 at 4:07 PM, Austin Ziegler wrote: > On Tue, Sep 30, 2008 at 4:51 PM, Jim Freeze wrote: >> One way (just one, mind you) is that if require_gem really required >> the gem. So, you would have >> >> require_gem 'gem_name_here' >> >> and the gem did the requiring of the files internal. >> >> Just a thought. > > No, no no no no. > > That's what it used to do (with autoload). > > This is bad, bad, bad, bad, bad. (Which is why it was deprecated.) Are you sure? I thought require_gem was the same as require, in that it required a file, but searched for it in the gem paths. I have never created a gem that one could load with require 'gem_name' because that would require my gem to have an init hook and that hook is where the real require would happen. Maybe I am getting old and forgetful, but I don't remember ever doing that for the gems that I have written. > You shouldn't be using "require_gem" anyway; you should be using "gem" > to activate particular gems/versions. > > I'd suggest that good practice would be including a dummy file that > matches your gem name, if appropriate. Yes, I have seen this with activesupport.rb and active_support.rb > That is, if I were to do this with PDF::Writer, I would make it so > that you could "require 'pdf-writer'" (since that's the name of the > gem), instead of "pdf/writer". > -- Jim Freeze From jim.weirich at gmail.com Tue Sep 30 18:42:07 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 30 Sep 2008 18:42:07 -0400 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> Message-ID: On Sep 30, 2008, at 4:51 PM, Jim Freeze wrote: > One way (just one, mind you) is that if require_gem really required > the gem. So, you would have > > require_gem 'gem_name_here' > > and the gem did the requiring of the files internal. NO! That way leads to madness. That was the function of the autorequire flag on older gemspecs. That lead to early loading of code before the complete gem version requirements were given. This could lead to incompatible version of the library being required. It was also the root cause of causing require "FILE" to return false instead of true. A bug the pragmatically effected absolutely no one (who checks the return value of require?), but caused no end of questions because people would do a require in irb and see the false and think the file wasn't loaded. The autorequire flag was also the root cause of several other issues which escape me at the moment. BTW, the only difference between the old require_gem and gem methods is that gem ignores the autorequire flag. -- -- Jim Weirich -- jim.weirich at gmail.com From drbrain at segment7.net Tue Sep 30 19:59:32 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 30 Sep 2008 16:59:32 -0700 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> Message-ID: <780C07C0-76A6-4FAD-938E-7D68B94CD046@segment7.net> On Sep 30, 2008, at 13:51 PM, Jim Freeze wrote: > One way (just one, mind you) is that if require_gem really required > the gem. So, you would have > > require_gem 'gem_name_here' > > and the gem did the requiring of the files internal. There is no require_gem (anymore). $ ruby -rubygems -e 'require_gem "ZenTest"' -e:1: undefined method `require_gem' for main:Object (NoMethodError) From rubygems at freeze.org Tue Sep 30 21:03:40 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 20:03:40 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> Message-ID: <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> On Tue, Sep 30, 2008 at 5:42 PM, Jim Weirich wrote: > > On Sep 30, 2008, at 4:51 PM, Jim Freeze wrote: > >> One way (just one, mind you) is that if require_gem really required >> the gem. So, you would have >> >> require_gem 'gem_name_here' >> >> and the gem did the requiring of the files internal. > > NO! That way leads to madness. > > That was the function of the autorequire flag on older gemspecs. That lead > to early loading of code before the complete gem version requirements were > given. This could lead to incompatible version of the library being > required. > > It was also the root cause of causing require "FILE" to return false instead > of true. A bug the pragmatically effected absolutely no one (who checks the > return value of require?), but caused no end of questions because people > would do a require in irb and see the false and think the file wasn't > loaded. > > The autorequire flag was also the root cause of several other issues which > escape me at the moment. > So, I did not realize that require_gem was such a loaded word. And somehow is sucked in autorequire. Who mentioned that? So, I am not surprised that there is no require_gem because there never was a require_gem 'gem_name'. So, to avoid any harmful effects of require_gem, I'm suggesting a new method. Let's call it bunny_foo_foo. That is surely a harmless method. This whole conversation started because I've been bombarded with complaints that rubygems is broken because there is no way to know what to require after installing a gem. In fact, these 'unnamed individuals' have identified the problem as two separate problems, 1) the naming of the gem and 2) the naming/path of the file to require. I really don't see a way around #1. I mean, how can you possibly know that the chunky_bacon gem is used for python comment parsing. But, the second issue is potentially solvable, but it will require an addition of an optional file (or possibly hook code) to a gem. So, a standard scenario would be this: sudo gem install bora_bora Then, in the ruby code we would have bunny_foo_foo 'bora_bora' Is that too abstract? Today, gem developers can solve this problem in the following manner: sudo gem install bora_bora .... require 'rubygems' require 'bora_bora' # look, no surprise here. where the bora_bora gem has included the file lib/bora_bora.rb with the contents require 'my/crazy/path/that/you/cant/guess' But, we can refactor these two lines into a single line require_gem 'bora_bora' I mean bunny_foo_foo 'bora_bora' # optional version follows So, here the file lib/bora_bora does not have to exist. It could possibly be lib/bootstrap.rb. This file will then require the correct files. You know, the mysterious ones that I've been getting complaints on. Also, notice there is no suggestion of autorequire here. This simply replaces the "require 'secret/path'". -- Jim Freeze From halostatue at gmail.com Tue Sep 30 21:53:50 2008 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 30 Sep 2008 21:53:50 -0400 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> Message-ID: <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> On Tue, Sep 30, 2008 at 9:03 PM, Jim Freeze wrote: > So, I did not realize that require_gem was such a loaded word. And > somehow is sucked in autorequire. Who mentioned that? You did, but you didn't realize it. #require_gem *was* a method that would work like this: require_gem 'pdf-writer', '= 1.1.8' Looks a lot like the #gem method, right? Well, it is almost exactly like the #gem method, except that it did one other thing: it looked at the autorequire field in the gem spec, and then loaded whatever file (or files?) were in there. This was removed just prior to the 1.0 release because it was realized that autorequire was a mistake. What you're asking for is the return of autorequire. It also means that certain programs are now forever going to be stuck with RubyGems, even if that's not how they're installed. If I install ParseTree (for example) with "apt-get ruby-parsetree", should I expect the ParseTree gem to be installed? Well, ideally, yes. But the Debian maintainers, in their infinite wisdom, don't like RubyGems and don't use it so far as I can tell. So, if I've got a script that runs on multiple platforms, including a Debian system, I have to make my program look something like this in a #bunny_foo_foo world: begin bunny_foo_foo 'ParseTree' rescue require 'ParseTree' end Which is just what you're already complaining about. Note that I put "" in there; I'm not quite sure what you'd have to rescue. It might be NoMethodError (because if you don't have RubyGems installed, you don't have #bunny_foo_foo); it might be LoadError; it might be Gem::ActivationError (which, if you don't have RubyGems installed...). > This whole conversation started because I've been bombarded with > complaints that rubygems is broken because there is no way to know > what to require after installing a gem. In fact, these 'unnamed > individuals' have identified the problem as two separate problems, 1) > the naming of the gem and 2) the naming/path of the file to require. This is a real problem, but it's the same problem that exists on any packaging system. You want the package names to be sensible, but a package may offer more than just one thing to load. Consider Facets. While I don't particularly like this library, it's an excellent example of the problem: it's a mega-library that contains a lot of different useful functionality that you don't always want to load all of it all of the time. Does Trans force people to install 25 gems to allow an autorequire mechanism to work on a fine-grained enough level (which means you now have to remember 25 different gem names...), or does he go with one gem that people choose "require 'facet/feature1'" and "require 'facet/feature2'" instead? And, if they want, he could offer a lib/facets.rb that includes all 25 features. > I really don't see a way around #1. I mean, how can you possibly know > that the chunky_bacon gem is used for python comment parsing. > But, the second issue is potentially solvable, but it will require an > addition of an optional file (or possibly hook code) to a gem. > > So, a standard scenario would be this: > > sudo gem install bora_bora > > Then, in the ruby code we would have > > bunny_foo_foo 'bora_bora' > Is that too abstract? It's not that it's too abstract: it's the wrong behaviour. > Today, gem developers can solve this problem in > the following manner: > > sudo gem install bora_bora > .... > require 'rubygems' > require 'bora_bora' # look, no surprise here. > > where the bora_bora gem has included the file lib/bora_bora.rb with the contents > > require 'my/crazy/path/that/you/cant/guess' > > But, we can refactor these two lines into a single line > > require_gem 'bora_bora' > > I mean > > bunny_foo_foo 'bora_bora' # optional version follows > > So, here the file lib/bora_bora does not have to exist. It could > possibly be lib/bootstrap.rb. This file will then require the correct > files. You know, the mysterious ones that I've been getting complaints > on. > > Also, notice there is no suggestion of autorequire here. This simply > replaces the "require 'secret/path'". It's still autorequire, even if bunny_foo_foo looks for lib/bootstrap.rb. Why? If I have five gems with lib/bootstrap.rb, what happens when I do: require 'bootstrap' One of them will be activated, but it may not be the one you expect. -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 rubygems at freeze.org Tue Sep 30 22:45:02 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 21:45:02 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> Message-ID: <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> On Tue, Sep 30, 2008 at 8:53 PM, Austin Ziegler wrote: > On Tue, Sep 30, 2008 at 9:03 PM, Jim Freeze wrote: >> So, I did not realize that require_gem was such a loaded word. And >> somehow is sucked in autorequire. Who mentioned that? > > You did, but you didn't realize it. No, I didn't. > #require_gem *was* a method that would work like this: > > require_gem 'pdf-writer', '= 1.1.8' > > Looks a lot like the #gem method, right? Well, it is almost exactly > like the #gem method, except that it did one other thing: it looked at > the autorequire field in the gem spec, and then loaded whatever file > (or files?) were in there. What I am suggesting will NOT use autorequire. Really. Not. Nada. > If I install ParseTree (for example) with "apt-get ruby-parsetree", > should I expect the ParseTree gem to be installed? Well, ideally, yes. > But the Debian maintainers, in their infinite wisdom, don't like > RubyGems and don't use it so far as I can tell. So, if I've got a > script that runs on multiple platforms, including a Debian system, I > have to make my program look something like this in a #bunny_foo_foo > world: > > begin > bunny_foo_foo 'ParseTree' > rescue > require 'ParseTree' > end Ok, now we are getting somewhere. The same applies today with rubygems. begin require 'some-lib' rescue LoadError require 'rubygems' require 'some-lib' end > Which is just what you're already complaining about. Note that I put No, it's not. And I'm not complaining. I am getting complaints. Man, doesn't anyone read. :/ > It might be NoMethodError (because if you don't have RubyGems > installed, you don't have #bunny_foo_foo); it might be LoadError; it Actually, bunny_foo_foo could be built in. > This is a real problem, but it's the same problem that exists on any > packaging system. You want the package names to be sensible, but a > package may offer more than just one thing to load. Consider Facets. > While I don't particularly like this library, it's an excellent > example of the problem: it's a mega-library that contains a lot of > different useful functionality that you don't always want to load all > of it all of the time. Yes, this suggestion won't work for multi-featured gems. Rails is a good example too. > Does Trans force people to install 25 gems to allow an autorequire > mechanism to work on a fine-grained enough level (which means you now > have to remember 25 different gem names...), or does he go with one > gem that people choose "require 'facet/feature1'" and "require > 'facet/feature2'" instead? And, if they want, he could offer a > lib/facets.rb that includes all 25 features. Again with that autorequire thing. Are all computer people so locked in to existing ideas they can't see alternatives. What if bunny_foo_foo took arguments. bunny_foo_foo 'facets', :feature_2459592 >> Today, gem developers can solve this problem in >> the following manner: >> >> sudo gem install bora_bora >> .... >> require 'rubygems' >> require 'bora_bora' # look, no surprise here. >> >> where the bora_bora gem has included the file lib/bora_bora.rb with the contents >> >> require 'my/crazy/path/that/you/cant/guess' >> >> But, we can refactor these two lines into a single line >> >> require_gem 'bora_bora' >> >> I mean >> >> bunny_foo_foo 'bora_bora' # optional version follows >> >> So, here the file lib/bora_bora does not have to exist. It could >> possibly be lib/bootstrap.rb. This file will then require the correct >> files. You know, the mysterious ones that I've been getting complaints >> on. >> >> Also, notice there is no suggestion of autorequire here. This simply >> replaces the "require 'secret/path'". > > It's still autorequire, even if bunny_foo_foo looks for lib/bootstrap.rb. > > Why? If I have five gems with lib/bootstrap.rb, what happens when I do: > > require 'bootstrap' > > One of them will be activated, but it may not be the one you expect. I expect the same thing I have today (that magically doesn't use autorequire). I have 5 versions of the sequel gem. What happens when I do: require 'rubygems' require 'sequel' It requires the latest version. What is so special about this that it doesn't use autorequire, but bunny_foo_foo does? -- Jim Freeze From luislavena at gmail.com Tue Sep 30 23:09:27 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 1 Oct 2008 01:09:27 -0200 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> Message-ID: <71166b3b0809302009r4fcd4312x3d1b8a1a6f45110@mail.gmail.com> On Wed, Oct 1, 2008 at 12:45 AM, Jim Freeze wrote: > On Tue, Sep 30, 2008 at 8:53 PM, Austin Ziegler wrote: >> On Tue, Sep 30, 2008 at 9:03 PM, Jim Freeze wrote: >>> So, I did not realize that require_gem was such a loaded word. And >>> somehow is sucked in autorequire. Who mentioned that? >> >> You did, but you didn't realize it. > > No, I didn't. > >> #require_gem *was* a method that would work like this: >> >> require_gem 'pdf-writer', '= 1.1.8' >> >> Looks a lot like the #gem method, right? Well, it is almost exactly >> like the #gem method, except that it did one other thing: it looked at >> the autorequire field in the gem spec, and then loaded whatever file >> (or files?) were in there. > > What I am suggesting will NOT use autorequire. Really. Not. Nada. > >> If I install ParseTree (for example) with "apt-get ruby-parsetree", >> should I expect the ParseTree gem to be installed? Well, ideally, yes. >> But the Debian maintainers, in their infinite wisdom, don't like >> RubyGems and don't use it so far as I can tell. So, if I've got a >> script that runs on multiple platforms, including a Debian system, I >> have to make my program look something like this in a #bunny_foo_foo >> world: >> >> begin >> bunny_foo_foo 'ParseTree' >> rescue >> require 'ParseTree' >> end > > Ok, now we are getting somewhere. The same applies today with rubygems. > > begin > require 'some-lib' > rescue LoadError > require 'rubygems' > require 'some-lib' > end > >> Which is just what you're already complaining about. Note that I put > > No, it's not. And I'm not complaining. I am getting complaints. Man, > doesn't anyone read. :/ > Ok, let forget about bunny_foo_foo, require_gem and all that, let's heard the complains. 1st: who are the users that are complaining to you? what is your role in the company or what? 2nd: users using these gems should at least know how to use the gems. 3th: even we implement bunny_foo_foo in RubyGems your users using Debian and installing "the debian way" or any other bizarre distro maybe will not depend on RubyGems. 4th: These non-standard or non-standarized "requires" should be forwarded to each gem author or teams and not being handled by RubyGems. 5th: If the projects are OSS (which most of the gems are), contribute, send patches or Fork (in case of a Git repository or even using GitHub). -- Luis Lavena AREA 17 - Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so. Douglas Adams From jim.weirich at gmail.com Tue Sep 30 23:26:00 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 30 Sep 2008 23:26:00 -0400 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> Message-ID: <50FBC892-2221-4328-86F4-FC85C95F7BA0@gmail.com> On Sep 30, 2008, at 10:45 PM, Jim Freeze wrote: > What I am suggesting will NOT use autorequire. Really. Not. Nada. I was in the midst of writing a longish reply suggesting that what you asked for is semantically equivalent to the original auto-requiring require_gem method, when it occurred to me to ask for clarification. Are you asking for this: def bunny_foo_foo(gem_name) gem gem_name require the_default_load_file_for_gem(gem_name) end or are you asking for: def bunny_foo_foo(gem_name) require the_default_load_file_for_gem(gem_name) end ? The former is essentially the original require_gem command that we were reacting to. The later is something different. Or did you have something entirely different in mind? -- -- Jim Weirich -- jim.weirich at gmail.com From rubygems at freeze.org Tue Sep 30 23:50:42 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 22:50:42 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <50FBC892-2221-4328-86F4-FC85C95F7BA0@gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> <50FBC892-2221-4328-86F4-FC85C95F7BA0@gmail.com> Message-ID: <5cd596d60809302050p45959419i46309fcef7df4853@mail.gmail.com> Hi Jim On Tue, Sep 30, 2008 at 10:26 PM, Jim Weirich wrote: > > Are you asking for this: > > def bunny_foo_foo(gem_name) > gem gem_name > require the_default_load_file_for_gem(gem_name) > end I am not up to speed with the exact nature of gem. Is it the same as: def bunny_foo_foo(gem_name) require 'rubygems' require the_default_load_file_for_gem(gem_name) end I'm assuming the gem bascially stages a gem for later requiring. > or are you asking for: > > def bunny_foo_foo(gem_name) > require the_default_load_file_for_gem(gem_name) > end One way to write this would be to def bunny_foo_foo(gem_name) require File.join(path_to(gem_name), "lib/bootstrap") end -- Jim Freeze From rubygems at freeze.org Tue Sep 30 23:58:56 2008 From: rubygems at freeze.org (Jim Freeze) Date: Tue, 30 Sep 2008 22:58:56 -0500 Subject: [Rubygems-developers] Gem Names not correlated to require name In-Reply-To: <71166b3b0809302009r4fcd4312x3d1b8a1a6f45110@mail.gmail.com> References: <5cd596d60809301214r182d15f8i1dfd7af1fc9abc41@mail.gmail.com> <67dd69ee-fa72-46ae-97f3-dd86b99a0efe@i76g2000hsf.googlegroups.com> <5cd596d60809301351j176a495cj1ea011046c03c71c@mail.gmail.com> <5cd596d60809301803l6dab4163h74dcd8b81eaa8b38@mail.gmail.com> <9e7db9110809301853n66e4f9a7w3b02bc559852499e@mail.gmail.com> <5cd596d60809301945y24cf023ev44818d601f536f21@mail.gmail.com> <71166b3b0809302009r4fcd4312x3d1b8a1a6f45110@mail.gmail.com> Message-ID: <5cd596d60809302058k562f73e2qa75b92a4a11bc7c5@mail.gmail.com> On Tue, Sep 30, 2008 at 10:09 PM, Luis Lavena wrote: > Ok, let forget about bunny_foo_foo, require_gem and all that, let's > heard the complains. The basic complaint is the require filename cannot be determined from the gem name. I have made most of the counter arguments to them as this group has to me. Many of the group have perl background, and so, compared to CPAN, they view rubygems as broken since rubygems does not have the equivalent ability of determining the load file from the module name. > 1st: who are the users that are complaining to you? what is your role > in the company or what? n/a > 2nd: users using these gems should at least know how to use the gems. I agree, to a point. I can usually find out what to include within 30 seconds. But it is annoying to have to re-look up require points. You'll understand as you get older. :) > 3th: even we implement bunny_foo_foo in RubyGems your users using > Debian and installing "the debian way" or any other bizarre distro > maybe will not depend on RubyGems. Well, not exactly. #bunny_foo_foo knows the gem name, hence it knows the path to the require file. > 4th: These non-standard or non-standarized "requires" should be > forwarded to each gem author or teams and not being handled by > RubyGems. Maybe. > 5th: If the projects are OSS (which most of the gems are), contribute, > send patches or Fork (in case of a Git repository or even using > GitHub). Premature. First diagnose. Second, prescribe. -- Jim Freeze