From thibaut.barrere at gmail.com Tue Nov 4 11:17:28 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 4 Nov 2008 17:17:28 +0100 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? Message-ID: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> Hello, not sure if it's the right place to ask this question, but I could not find a user list or anything else. Please tell me if it's the case! One of my servers is a joyent shared accelerator - basically a system where I can't sudo and where system gems are upgraded from time to time by an administrator. To insulate my apps (Rails, Merb,. ..) from these changes, I freeze the gems I use into version control. Some projects rely on gems that have native extensions, such as hpricot or do_sqlite3 for instance. Luckily these gems happen to be already available on the system but I'd like to protect my apps from any upgrade there too. Is there a way to install these gems without having sudo rights (ie: compiling into some specific folder, telling rubygems where to pick the binaries, or any other solution ?) I'd love to be able to find the same "freezed" behaviour for these gems and avoid to be bitten by a system upgrade. Any hint will be most welcome! thank you, Thibaut Barr?re -- [blog] http://evolvingworker.com - tools for a better day [blog] http://blog.logeek.fr - about writing software -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 4 13:36:41 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 4 Nov 2008 11:36:41 -0700 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> Message-ID: On Tue, Nov 4, 2008 at 9:17 AM, Thibaut Barr?re wrote: > Is there a way to install these gems without having sudo rights (ie: > compiling into some specific folder, telling rubygems where to pick the > binaries, or any other solution ?) > GemInstaller can help with this - not by freezing, but by ensuring you install/activate the correct versions. Check out http://geminstaller.rubyforge.org. Docs are a little out of date, but here's the relevant parts: 1. Use rails config/preinitializer.rb or merb config/init.rb to hook in GemInstaller.install (to install) and GemInstaller.autogem (to activate). This will install/activate the exact version you have in your geminstaller.yml. 2. Use standard RubyGems mechanisms to ensure that gems are installed/loaded from a non-root location, like ~/.gems. Currently you can do this by setting gemhome and gempath in ~/.gemrc and ensuring the ~/.gem/.../bin dir is on your path, but this capability may be removed in future rubygems versions. If it is removed, you can always override it with the corresponding RubyGems environment variables for gem home and path. Feel free to ask for help on the GemInstaller mailing list or lighthouse tickets if you have problems/questions, and this will also inspire me to update the docs (I just spent a ton of time getting them publishable again after webgen/redcloth upgrades, so I can actually add new content again). -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thibaut.barrere at gmail.com Tue Nov 4 17:05:36 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Tue, 4 Nov 2008 23:05:36 +0100 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> Message-ID: <4a68b8cf0811041405n7bae3ea5s75cd18e27dcc995a@mail.gmail.com> Hi Chad, thanks for all these tips! GemInstaller seems to be very useful. I'll give it a try and will open tickets if I meet issues. thank you! Thibaut Barr?re -- [blog] http://evolvingworker.com - tools for a better day [blog] http://blog.logeek.fr - about writing software On Tue, Nov 4, 2008 at 7:36 PM, Chad Woolley wrote: > On Tue, Nov 4, 2008 at 9:17 AM, Thibaut Barr?re > wrote: > >> Is there a way to install these gems without having sudo rights (ie: >> compiling into some specific folder, telling rubygems where to pick the >> binaries, or any other solution ?) >> > > GemInstaller can help with this - not by freezing, but by ensuring you > install/activate the correct versions. Check out > http://geminstaller.rubyforge.org. Docs are a little out of date, but > here's the relevant parts: > > 1. Use rails config/preinitializer.rb or merb config/init.rb to hook in > GemInstaller.install (to install) and GemInstaller.autogem (to activate). > This will install/activate the exact version you have in your > geminstaller.yml. > > 2. Use standard RubyGems mechanisms to ensure that gems are > installed/loaded from a non-root location, like ~/.gems. Currently you can > do this by setting gemhome and gempath in ~/.gemrc and ensuring the > ~/.gem/.../bin dir is on your path, but this capability may be removed in > future rubygems versions. If it is removed, you can always override it with > the corresponding RubyGems environment variables for gem home and path. > > Feel free to ask for help on the GemInstaller mailing list or lighthouse > tickets if you have problems/questions, and this will also inspire me to > update the docs (I just spent a ton of time getting them publishable again > after webgen/redcloth upgrades, so I can actually add new content again). > > -- Chad > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drbrain at segment7.net Tue Nov 4 19:34:04 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 4 Nov 2008 16:34:04 -0800 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> Message-ID: <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> On Nov 4, 2008, at 08:17 AM, Thibaut Barr?re wrote: > Is there a way to install [gems with native extensions like hpricot] > without having sudo rights (ie: compiling into some specific folder, > telling rubygems where to pick the binaries, or any other solution ?) The same way you install any other gem: $ gem install hpricot WARNING: Installing to ~/.gem since /Library/Ruby/Gems/1.8 and /usr/bin aren't both writable. WARNING: You don't have /Users/drbrain/.gem/ruby/1.8/bin in your PATH, gem executables will not run. Building native extensions. This could take a while... Successfully installed hpricot-0.6.164 1 gem installed [...] If a gem is set up to move files into site_lib, it is broken and you should file a bug with the author. From thibaut.barrere at gmail.com Tue Nov 4 19:54:59 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Wed, 5 Nov 2008 01:54:59 +0100 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> Message-ID: <4a68b8cf0811041654w62f572cbq7f92fd147f8d8b2d@mail.gmail.com> Hi Eric, > The same way you install any other gem: > > $ gem install hpricot > WARNING: Installing to ~/.gem since /Library/Ruby/Gems/1.8 and > /usr/bin aren't both writable. > WARNING: You don't have /Users/drbrain/.gem/ruby/1.8/bin in your PATH, > gem executables will not run. > Building native extensions. This could take a while... > Successfully installed hpricot-0.6.164 > 1 gem installed > [...] ok just got it. It works with 1.3.0 but not but 1.1.1: gem install hpricot-0.6.164.gem ERROR: While executing gem ... (Gem::FilePermissionError) You don't have write permissions into the /usr/local/lib/ruby/gems/1.8 directory. I guess I'll just wait for the shared upgrade to rubygems 1.3.0, or use GemInstaller. Thanks for the feedback guys, -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 4 20:02:04 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 4 Nov 2008 18:02:04 -0700 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> Message-ID: On Tue, Nov 4, 2008 at 5:34 PM, Eric Hodel wrote: > The same way you install any other gem: > > $ gem install hpricot > But, since he said the correct version is already installed on the system, this would be a no-op. He would still have to force a reinstall to ~/.gems to ensure his specific version is there in case the system version is ever upgraded in the future (and the old version removed). Or, just rely on a specific version activiation to make his app blow up on deploy if the specified version ever goes away from the system gems (forcing blow up via specific version passed to RubyGems gem() method, which is what GemInstaller.autogem() calls). -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 4 20:08:38 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 4 Nov 2008 18:08:38 -0700 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: <4a68b8cf0811041654w62f572cbq7f92fd147f8d8b2d@mail.gmail.com> References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> <4a68b8cf0811041654w62f572cbq7f92fd147f8d8b2d@mail.gmail.com> Message-ID: On Tue, Nov 4, 2008 at 5:54 PM, Thibaut Barr?re wrote: > > I guess I'll just wait for the shared upgrade to rubygems 1.3.0, or use > GemInstaller. > Not sure how the Joyent setup works, but if you locally install the correct version of rubygems (e.g. in ~/rubygems), you should be able to manipulate your ruby interpreter's load path before you require rubygems, and force it to use your local version. Something like this I think, you'd have to look at the rails/merb executable to know exactly what to do: "ruby -I #{rubygems_lib_dir}#{File::PATH_SEPARATOR}#{rubygems_bin_dir} path/to/run/rails/or/merb" Might be an easier way, but I don't know offhand... -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 4 20:13:27 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 4 Nov 2008 18:13:27 -0700 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> Message-ID: On Tue, Nov 4, 2008 at 6:02 PM, Chad Woolley wrote: > But, since he said the correct version is already installed on the system, > this would be a no-op. > Actually, I think I'm wrong, it will not be a no-op, it will attempt reinstall and failover to ~/.gem like Eric said. Does >=1.3.0 always check in ~/.gems by default, even if it isn't set in env or ~/.gemrc? If so, this means he doesn't have to set any env or .gemrc entries? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thibaut.barrere at gmail.com Tue Nov 4 20:25:13 2008 From: thibaut.barrere at gmail.com (=?ISO-8859-1?Q?Thibaut_Barr=E8re?=) Date: Wed, 5 Nov 2008 02:25:13 +0100 Subject: [Rubygems-developers] How to freeze gems that require native extension without sudo rights ? In-Reply-To: References: <4a68b8cf0811040817s28ab237dj6d93c34914a99588@mail.gmail.com> <4F64DB14-143F-4104-8272-6799771F2650@segment7.net> Message-ID: <4a68b8cf0811041725g4f5c8478y752ee79e6fe01b17@mail.gmail.com> I guess for the moment I'll just wait for the system upgrade to 1.3.0 as I'm in no hurry. It's not a blocker issue so far, I just have to follow upgrades carefully. But thanks anyway - I learned a couple of useful tricks that will probably be useful at some point! -- Thibaut -------------- next part -------------- An HTML attachment was scrubbed... URL: From rubygems at freeze.org Sun Nov 9 08:36:37 2008 From: rubygems at freeze.org (Jim Freeze) Date: Sun, 9 Nov 2008 07:36:37 -0600 Subject: [Rubygems-developers] Problems updating a system from 1.2 to 1.3.1 Message-ID: <5cd596d60811090536h41b0ebc5t5a6527237f5a139c@mail.gmail.com> Has anyone experienced this problem: jdf at host29 703 /Users/jdf/bin % gem -v 1.2.0 jdf at host29 704 /Users/jdf/bin % sudo gem update --system Password: Updating RubyGems Updating rubygems-update Successfully installed rubygems-update-1.3.1 ERROR: While executing gem ... (NameError) undefined local variable or method `remote_gemspecs' for # jdf at host29 705 /Users/jdf/bin % gem -v 1.2.0 jdf at host29 706 /Users/jdf/bin % sudo gem update --system Updating RubyGems Nothing to update jdf at host29 707 /Users/jdf/bin % gem -v 1.2.0 jdf at host29 708 /Users/jdf/bin % rehash jdf at host29 709 /Users/jdf/bin % gem -v 1.2.0 I also downloaded the .gem file for 1.3.1 and installed it, but still only had 1.2 returned from 'gem -v'. I finally downloaded the .tgz file and was able to install 1.3.1. -- Jim Freeze From kanarip at kanarip.com Sun Nov 9 08:56:05 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 09 Nov 2008 14:56:05 +0100 Subject: [Rubygems-developers] Problems updating a system from 1.2 to 1.3.1 In-Reply-To: <5cd596d60811090536h41b0ebc5t5a6527237f5a139c@mail.gmail.com> References: <5cd596d60811090536h41b0ebc5t5a6527237f5a139c@mail.gmail.com> Message-ID: <4916EBF5.8030902@kanarip.com> Jim Freeze wrote: > Has anyone experienced this problem: > > jdf at host29 703 /Users/jdf/bin % gem -v > 1.2.0 > jdf at host29 704 /Users/jdf/bin % sudo gem update --system > Password: > Updating RubyGems > Updating rubygems-update > Successfully installed rubygems-update-1.3.1 > ERROR: While executing gem ... (NameError) > undefined local variable or method `remote_gemspecs' for > # > jdf at host29 705 /Users/jdf/bin % gem -v > 1.2.0 > jdf at host29 706 /Users/jdf/bin % sudo gem update --system > Updating RubyGems > Nothing to update > jdf at host29 707 /Users/jdf/bin % gem -v > 1.2.0 > jdf at host29 708 /Users/jdf/bin % rehash > jdf at host29 709 /Users/jdf/bin % gem -v > 1.2.0 > > I also downloaded the .gem file for 1.3.1 and installed it, but still > only had 1.2 returned from 'gem -v'. > I finally downloaded the .tgz file and was able to install 1.3.1. > I've not seen this behaviour but I have been successfully packaging rubygems-1.3.1-1 for Fedora / EPEL (from .tgz): https://bugzilla.redhat.com/show_bug.cgi?id=470688 Kind regards, Jeroen van Meeuwen -kanarip From thewoolleyman at gmail.com Sun Nov 9 10:21:07 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 9 Nov 2008 08:21:07 -0700 Subject: [Rubygems-developers] Problems updating a system from 1.2 to 1.3.1 In-Reply-To: <5cd596d60811090536h41b0ebc5t5a6527237f5a139c@mail.gmail.com> References: <5cd596d60811090536h41b0ebc5t5a6527237f5a139c@mail.gmail.com> Message-ID: On Sun, Nov 9, 2008 at 6:36 AM, Jim Freeze wrote: > Has anyone experienced this problem: > Yes, I had it on one system. I also had to run setup from the zip to fix it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Mon Nov 10 20:12:56 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 10 Nov 2008 18:12:56 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? Message-ID: This should be a rubyforge support question, but I thought I'd ask here first to get input to write a coherent ticket... There are often occasions where I want to script a fresh download and install of the latest rubygems - especially since the auto-update doesn't work in 1.2.0. However, with each release, the mirror seems to change. It actually seems to be an annoying rule that a mirror that worked for the prior release (e.g. 1.3.0) doesn't work for a newer release (1.3.1). Is there anyway rubyforge can be configured to provide a non-mirrored url for the latest rubygems, or a proxy which will always redirect to a valid mirror? Thanks, -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jftucker at gmail.com Mon Nov 10 20:50:10 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 11 Nov 2008 01:50:10 +0000 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> how about something like this: http://github.com/raggi/source_ports/tree/stable/install.rb but wrapped up for rubygems setup.rb? On 11 Nov 2008, at 01:12, Chad Woolley wrote: > This should be a rubyforge support question, but I thought I'd ask > here first to get input to write a coherent ticket... > > There are often occasions where I want to script a fresh download > and install of the latest rubygems - especially since the auto- > update doesn't work in 1.2.0. > > However, with each release, the mirror seems to change. It actually > seems to be an annoying rule that a mirror that worked for the prior > release (e.g. 1.3.0) doesn't work for a newer release (1.3.1). > > Is there anyway rubyforge can be configured to provide a non- > mirrored url for the latest rubygems, or a proxy which will always > redirect to a valid mirror? > > Thanks, > -- Chad > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jftucker at gmail.com Mon Nov 10 21:00:41 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 11 Nov 2008 02:00:41 +0000 Subject: [Rubygems-developers] rake build task Message-ID: <14E545F6-53BE-4D82-BC4B-B4E18C781062@gmail.com> Hey folks, I need to send a patch [1], but, I don't think that's quite right yet, so until I try and grok why the test still pass, I have some questions... First of all, I note that gem19 install rake will install rake to rake19, and so on. This means the above patch is still wrong under those conditions. How do I find out the correct prefix from rubygems? Regarding the above patch, it solves an issue when building the new eventmachine rake build gem, under conditions that rake is being invoked from jruby -S gem install gemname. The prior code would invoke 'rake' from the path, which would lead in some configurations to the MRI install. Whilst rake is pretty common, what we do in the gem is this: http://github.com/eventmachine/eventmachine/tree/master/ Rakefile#L38-39 (ruby_platform =~ java) In order to allow for a common gem, which will build on a number of ruby platforms: http://github.com/eventmachine/eventmachine/tree/master/Rakefile#L54-61 Another slight aside, but interesting, is how I went about dealing with the fact that we don't currently supply args to rake builds: http://github.com/eventmachine/eventmachine/tree/master/Rakefile#L42-48 Thanks in advance, James. [1] From a009f31f8a21313332359644e36db5f431f8bf6a Mon Sep 17 00:00:00 2001 From: raggi Date: Tue, 11 Nov 2008 00:30:48 +0000 Subject: [PATCH] Added a fix for rake path search --- lib/rubygems/ext/rake_builder.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/rubygems/ext/rake_builder.rb b/lib/rubygems/ext/ rake_builder.rb index 0c64e61..0f5f629 100644 --- a/lib/rubygems/ext/rake_builder.rb +++ b/lib/rubygems/ext/rake_builder.rb @@ -15,7 +15,7 @@ class Gem::Ext::RakeBuilder < Gem::Ext::Builder run cmd, results end - cmd = ENV['rake'] || 'rake' + cmd = ENV['rake'] || "#{Gem.ruby} -S rake" cmd += " RUBYARCHDIR=#{dest_path} RUBYLIBDIR=#{dest_path}" # ENV is frozen run cmd, results -- 1.5.6.rc3.7.g336d0.dirty From tom at infoether.com Mon Nov 10 23:53:35 2008 From: tom at infoether.com (Tom Copeland) Date: Mon, 10 Nov 2008 23:53:35 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: On Nov 10, 2008, at 8:12 PM, Chad Woolley wrote: > This should be a rubyforge support question, but I thought I'd ask > here first to get input to write a coherent ticket... > > There are often occasions where I want to script a fresh download > and install of the latest rubygems - especially since the auto- > update doesn't work in 1.2.0. > > However, with each release, the mirror seems to change. It actually > seems to be an annoying rule that a mirror that worked for the prior > release (e.g. 1.3.0) doesn't work for a newer release (1.3.1). > > Is there anyway rubyforge can be configured to provide a non- > mirrored url for the latest rubygems, or a proxy which will always > redirect to a valid mirror? The RubyForge file downloads are more or less round-robined between the various mirror servers... I say "more or less" because some server are handed more requests than others. But all the mirrors should be serving all files after the rsync'ing process has finished... Yours, Tom From thewoolleyman at gmail.com Tue Nov 11 04:37:00 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 02:37:00 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: On Mon, Nov 10, 2008 at 9:53 PM, Tom Copeland wrote: > The RubyForge file downloads are more or less round-robined between the > various mirror servers... I say "more or less" because some server are > handed more requests than others. But all the mirrors should be serving all > files after the rsync'ing process has finished... > That doesn't appear to be the case. For example, this link is still valid: http://rubyforge.org/frs/download.php/43985/rubygems-1.3.0.tgz However, this one (manually edited to point to 1.3.1) is not: http://rubyforge.org/frs/download.php/43985/rubygems-1.3.1.tgz I can only download 1.3.1 if I use this different mirror (linked from the rubygems files page): http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz ...which means I had to update the URL in my scripts. Regardless, even if the 43985 mirror worked for 1.3.1, it still wouldn't be enough to make scripts stable because: 1. A currently-valid mirror could go offline in the future 2. There is still no generic url to grab the "latest" without hardcoding the version in the url - which means scripts must still be updated even if all mirrors worked and stayed around forever. Thanks, -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 11 04:41:03 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 02:41:03 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> Message-ID: On Mon, Nov 10, 2008 at 6:50 PM, James Tucker wrote: > how about something like this: > http://github.com/raggi/source_ports/tree/stable/install.rb > > but wrapped up for rubygems setup.rb? > Hmm. Not positive, but looks like that is dependent on the existence of a git branch named "stable". I don't think that is really relevant to this problem, which would be a rubyforge URL which always pulls the latest published version of the files on the rubyforge rubygems project. Thanks though, -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jftucker at gmail.com Tue Nov 11 06:06:00 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 11 Nov 2008 11:06:00 +0000 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> Message-ID: <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> On 11 Nov 2008, at 09:41, Chad Woolley wrote: > On Mon, Nov 10, 2008 at 6:50 PM, James Tucker > wrote: > how about something like this: > http://github.com/raggi/source_ports/tree/stable/install.rb > > but wrapped up for rubygems setup.rb? > > Hmm. Not positive, but looks like that is dependent on the > existence of a git branch named "stable". I don't think that is > really relevant to this problem, which would be a rubyforge URL > which always pulls the latest published version of the files on the > rubyforge rubygems project. Only the install points to a stable branch, the installer itself installs from several possible branches. The point is, though, rubygems release rake task could upload such a file as static content under http://rubygems.rubyforge.org/install-latest.rb or similar. One could then use the same trick. With rubygems, you could even pack up a little trick to install from the rubygems_update package and use a query on the source_index to find it maybe, or keep a yaml file with a pointer to the current version, or whatever. > > > Thanks though, > -- Chad > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 11 06:26:27 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 04:26:27 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> Message-ID: On Tue, Nov 11, 2008 at 4:06 AM, James Tucker wrote: > > The point is, though, rubygems release rake task could upload such a file > as static content under http://rubygems.rubyforge.org/install-latest.rb or > similar. One could then use the same trick. > OK, this could work, and wouldn't require a change to the rubyforge infrastructure. Even if it was just download-latest.rb that would still accomplish the goal and be simpler. > > With rubygems, you could even pack up a little trick to install from the > rubygems_update package and use a query on the source_index to find it > maybe, or keep a yaml file with a pointer to the current version, or > whatever. > Right, but I'm mostly concerned about clean installs or reinstalls from the tarball. If you already have rubygems > 1.2.0, you can just use the normal auto-update method. -------------- next part -------------- An HTML attachment was scrubbed... URL: From halostatue at gmail.com Tue Nov 11 07:34:05 2008 From: halostatue at gmail.com (Austin Ziegler) Date: Tue, 11 Nov 2008 07:34:05 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: <9e7db9110811110434g2b837df3keec203f0112a715c@mail.gmail.com> On Tue, Nov 11, 2008 at 4:37 AM, Chad Woolley wrote: > On Mon, Nov 10, 2008 at 9:53 PM, Tom Copeland wrote: >> The RubyForge file downloads are more or less round-robined between the >> various mirror servers... I say "more or less" because some server are >> handed more requests than others. But all the mirrors should be serving all >> files after the rsync'ing process has finished... > > That doesn't appear to be the case. For example, this link is still valid: > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.0.tgz > > However, this one (manually edited to point to 1.3.1) is not: > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.1.tgz Those are not mirrors. They are release IDs. They are, in fact, different things and you should not expect that they remain the same for everything. It's been a while since I've released anything on RubyForge, but you typically create a release (for 1.3.1) and then upload the files as appropriate for that release. -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 Daniel.Berger at qwest.com Tue Nov 11 10:59:04 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 11 Nov 2008 09:59:04 -0600 Subject: [Rubygems-developers] Gem#status? Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> Hi >From the journal of Phil Hagelberg: http://technomancy.us/117 "It'd be better if Rubygems allowed 2.2.0.a to be treated specially as a prerelease version that would be superceded by a later real release, and that's what Josh Susser, Alex Vollmer, and myself worked on." I'd rather not get into mangling version numbers in an attempt to parse every arcane schema that users come up with in the wild. However, I'm not opposed in principle to the notion of a gem "status" that would more or less be in line with the "status" field for RAA downloads, where a gem at 'stable' status (or 'production', or whatever you want to call it) would supercede a gem at 'prerelease' status. So, let's say on November 1, 2008 I want to put out a prerelease version of "foo" 1.0.0. It would look like this: Gem::Specification.new do |gem| gem.name = 'foo" gem.version = '1.0.0" gem.status = Gem::Status::PRERELEASE # Or ALPHA, or whatever end A month later I put out the "official" release: Gem::Specification.new do |gem| gem.name = 'foo" gem.version = '1.0.0" gem.status = Gem::Status::STABLE # The default, btw end Now I have two gems out there at 1.0.0, but one is tagged as a prerelease gem and one is tagged as stable gem. If a user does "gem install foo", they'll get the 'stable' gem, since it's understood to be the "real" version. If a user wants a specific release version they could use a command line switch, e.g. "gem install foo --status=prerelease". Then we just have to work out all the status options and determine their priority. Seem reasonable? Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From tom at infoether.com Tue Nov 11 11:26:41 2008 From: tom at infoether.com (Tom Copeland) Date: Tue, 11 Nov 2008 11:26:41 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: On Nov 11, 2008, at 4:37 AM, Chad Woolley wrote: > On Mon, Nov 10, 2008 at 9:53 PM, Tom Copeland > wrote: > The RubyForge file downloads are more or less round-robined between > the various mirror servers... I say "more or less" because some > server are handed more requests than others. But all the mirrors > should be serving all files after the rsync'ing process has > finished... > > That doesn't appear to be the case. For example, this link is still > valid: > > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.0.tgz > > However, this one (manually edited to point to 1.3.1) is not: > > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.1.tgz Oh gosh, sorry, I misunderstood. As Austin said, those ids are the release_ids... they're tied to a PostgreSQL SEQUENCE, so that's why they're incrementing. > 1. A currently-valid mirror could go offline in the future > 2. There is still no generic url to grab the "latest" without > hardcoding the version in the url - which means scripts must still > be updated even if all mirrors worked and stayed around forever. As part of the release process, someone could update a rubygems.rubyforge.org/latest.txt to point to the latest release... kinda clunky though.... hm. Yours, Tom From tom at infoether.com Tue Nov 11 11:27:33 2008 From: tom at infoether.com (Tom Copeland) Date: Tue, 11 Nov 2008 11:27:33 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: On Nov 11, 2008, at 11:26 AM, Tom Copeland wrote: > As part of the release process, someone could update a > rubygems.rubyforge.org/latest.txt to point to the latest release... > kinda clunky though.... hm. And that's exactly what you suggested a few messages from now, great minds think alike... Yours, Tom From hgs at dmu.ac.uk Tue Nov 11 11:42:52 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 11 Nov 2008 16:42:52 +0000 (GMT) Subject: [Rubygems-developers] Gem#status? In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Tue, 11 Nov 2008, Berger, Daniel wrote: > Hi > > >From the journal of Phil Hagelberg: > > http://technomancy.us/117 > > "It'd be better if Rubygems allowed 2.2.0.a to be treated specially as a > prerelease version that would be superceded by a later real release, and > that's what Josh Susser, Alex Vollmer, and myself worked on." > > I'd rather not get into mangling version numbers in an attempt to parse > every arcane schema that users come up with in the wild. However, I'm > not opposed in principle to the notion of a gem "status" that would more > or less be in line with the "status" field for RAA downloads, where a > gem at 'stable' status (or 'production', or whatever you want to call > it) would supercede a gem at 'prerelease' status. Could this be done more simply with another "decimal" place? Version 2.1.0.1 to 2.1.0.9999 or possibly, as each {major, minor, minor_minor, tiddler} may be regarded as an int: Version 2.2.0.-99 That might avoid having to have a list of acceptable names. How would one rank :random_jottings, :piffle and :balderdash for the really experimental versions that people might invent? > > So, let's say on November 1, 2008 I want to put out a prerelease version > of "foo" 1.0.0. It would look like this: The Tardis gem, as you plan to release it in the past? :-) > > Gem::Specification.new do |gem| > gem.name = 'foo" > gem.version = '1.0.0" > gem.status = Gem::Status::PRERELEASE # Or ALPHA, or whatever > end > > A month later I put out the "official" release: > > Gem::Specification.new do |gem| > gem.name = 'foo" > gem.version = '1.0.0" > gem.status = Gem::Status::STABLE # The default, btw > end > > Now I have two gems out there at 1.0.0, but one is tagged as a > prerelease gem and one is tagged as stable gem. If a user does "gem > install foo", they'll get the 'stable' gem, since it's understood to be > the "real" version. If a user wants a specific release version they > could use a command line switch, e.g. "gem install foo > --status=prerelease". > > Then we just have to work out all the status options and determine their > priority. I think numbers would be better, as we'll always run out of names, and the creativity with names (Shoes, raisins release for example) is somewhat unbounded. We won't run out of ints too quickly, unless that chap Cantor is going to release an infinite amount of software from his hotel chain.... > > Seem reasonable? > > Regards, > > Dan > Hugh From jeremy at hinegardner.org Tue Nov 11 11:51:18 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Tue, 11 Nov 2008 09:51:18 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> Message-ID: <20081111165118.GW31071@hinegardner.org> On Tue, Nov 11, 2008 at 04:26:27AM -0700, Chad Woolley wrote: > On Tue, Nov 11, 2008 at 4:06 AM, James Tucker wrote: > > > > > With rubygems, you could even pack up a little trick to install from the > > rubygems_update package and use a query on the source_index to find it > > maybe, or keep a yaml file with a pointer to the current version, or > > whatever. > > > > Right, but I'm mostly concerned about clean installs or reinstalls from the > tarball. If you already have rubygems > 1.2.0, you can just use the normal > auto-update method. The rubyforge gem itself gets you almost all the way there. This script will get you the latest release_id of rubygems, and its one more step to scrape the rubyforge page to get the download id, which is not built into the rubyforge gem, but wouldn't be all that extra to add to it if someone was so inclined. % cat rubygems-latest-version.rb #!/usr/bin/env ruby require 'rubygems' require 'rubyforge' # assuming you already have a rubyforge account and have manually run # 'rubyforge login' rf = RubyForge.new rf.configure rf.scrape_project('rubygems') rubygem_releases = rf.autoconfig['release_ids']['rubygems'] versions = {} rubygem_releases.each do |k,v| next unless Gem::Version.correct?( k ) versions[ Gem::Version.new( k ) ] = v end latest_version = versions.keys.sort.last puts "Latest Version : #{latest_version}" puts "Release id : #{versions[latest_version]}" Or, strip out all the needed functionality from the rubyforge gem and go that route. Which might be a better way to go if you are possibly on a machine with only a fresh install of ruby. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From technomancy at gmail.com Tue Nov 11 12:17:34 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Tue, 11 Nov 2008 09:17:34 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> (Daniel Berger's message of "Tue, 11 Nov 2008 09:59:04 -0600") References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <87abc6fahd.fsf@hagelb.org> "Berger, Daniel" writes: > I'd rather not get into mangling version numbers in an attempt to parse > every arcane schema that users come up with in the wild. Indeed; that would be foolhardy. However, we don't try to handle every arcane schema. We handle this: * Parts of versions with only numerical digits are treated as before. * Version parts with letters are prerelease (e.g. 'a', 'b5', or 'RC1'). * Versions with a prerelease part in the Nth part sort less than versions with N-1 parts. * Prerelease parts are sorted alphabetically using the normal Ruby string sorting rules. The code to do so is very simple and well-tested. > However, I'm not opposed in principle to the notion of a gem "status" > that would more or less be in line with the "status" field for RAA > downloads [...] > Seem reasonable? It would seem reasonable if you had proposed it before any code had been written, but it doesn't seem reasonable to throw away what we already have since we get the same benefits without adding a new field to the gemspec. I've just committed what I have. If you have any concrete objections I would be happy to attend to them, but everyone else I've talked to has been very glad to see this feature introduced. There is a little more logic to be added to the SpecFetcher about when to ignore prereleases, but other than that it should be ready. -Phil From thewoolleyman at gmail.com Tue Nov 11 12:19:32 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 10:19:32 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Tue, Nov 11, 2008 at 8:59 AM, Berger, Daniel wrote: > I'd rather not get into mangling version numbers in an attempt to parse > every arcane schema that users come up with in the wild. However, I'm > not opposed in principle to the notion of a gem "status" that would more > or less be in line with the "status" field for RAA downloads, where a > gem at 'stable' status (or 'production', or whatever you want to call > it) would supercede a gem at 'prerelease' status. > > So, let's say on November 1, 2008 I want to put out a prerelease version > of "foo" 1.0.0. It would look like this: > > Gem::Specification.new do |gem| > gem.name = 'foo" > gem.version = '1.0.0" > gem.status = Gem::Status::PRERELEASE # Or ALPHA, or whatever > end > > A month later I put out the "official" release: > > Gem::Specification.new do |gem| > gem.name = 'foo" > gem.version = '1.0.0" > gem.status = Gem::Status::STABLE # The default, btw > end > This approach isn't good because there's no way to version prerelease gems. Every prerelease gem would be versioned the same, which doesn't work if I want to distinguish between them. To version prerelease versions, you'd have to revert back to what Rails is doing anyway, and make the "real" release end in 1 for the most-minor increment. On Tue, Nov 11, 2008 at 9:42 AM, Hugh Sasse wrote: > Could this be done more simply with another "decimal" place? > Version 2.1.0.1 to 2.1.0.9999 No! This means the new release has the same version as the previous release. The prerelease isn't the code for version 2.1.0.anything, it's the code for 2.2.anything. This causes problems for third-party tool maintainers who want to write and proactively release forward or backward compatible code against the prerelease by checking for rails version >=2.2, or <=2.1. This problem is why I convinced Koz to go with the current approach, which at least ensures the above version checks can be made sensibly. > or possibly, as each {major, minor, minor_minor, tiddler} may be > regarded as an int: > Version 2.2.0.-99 I believe this is essentially what Josh, Alex, and Phil are going to do, but by using a non-numeric number rather than a negative number to indicate the prerelease status, with the addition of a flag to force install of a prerelease gem. This is essentially the same approach Daniel is proposing, but with the "prerelease" status automatically determined by the existence of the non-numeric version component. I initially thought this was a bad idea, especially since the current Rails approach works fine, as long as you are not hung up on your first public release ending in zero. However, the thing that immediately convinced me otherwise - I'm very pragmatic ;) - is that this would allow ANY prerelease gem to be pushed to rubyforge, and people would not automatically pull it down, because the default would be to NOT download any prerelease gems. This would help address many of the concerns about people not pushing their Github (nondefault repo) gems back to RubyForge (default repo), and facilitate some mechanism that would allow prerelease (and release) gems to automatically be pushed/pulled from Github to Rubyforge. I'm really interested to see how they are going to do this without the non-numeric versions breaking old versions of rubygems, but I'm hopeful :) -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 11 12:24:54 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 10:24:54 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87abc6fahd.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> Message-ID: On Tue, Nov 11, 2008 at 10:17 AM, Phil Hagelberg wrote: > The code to do so is very simple and well-tested. > > ... > > > Seem reasonable? > > I've just committed what I have. If you have any concrete objections I > would be happy to attend to them, but everyone else I've talked to has > been very glad to see this feature introduced. There is a little more > logic to be added to the SpecFetcher about when to ignore prereleases, > but other than that it should be ready. > All sounds good, but what do prior versions of rubygems do when you push non-numeric versions to the repository? If they blow up spectacularly, then I think you should add a check that will not allow any non-numeric-version gemspec to be built unless the rubygems version is >= the version which will contain your patch. Which SHOULD be 1.4.0 (major feature addition, not bugfix), and that version should be committed to the RubyGems repo right now - because the code in the repo is no longer 1.3.anything ;) -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From technomancy at gmail.com Tue Nov 11 12:59:43 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Tue, 11 Nov 2008 09:59:43 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: (Chad Woolley's message of "Tue, 11 Nov 2008 10:19:32 -0700") References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <871vxif8j4.fsf@hagelb.org> "Chad Woolley" writes: >> or possibly, as each {major, minor, minor_minor, tiddler} may be >> regarded as an int: >> Version 2.2.0.-99 > > I believe this is essentially what Josh, Alex, and Phil are going to > do, but by using a non-numeric number rather than a negative number to > indicate the prerelease status, with the addition of a flag to force > install of a prerelease gem. This is was sort of how it originally implemented, but with 2.2.0.a becoming [2,2,0,-1,'a'] behind the scenes for sorting purposes. There were some issues with a few edge cases, and Josh replaced it with new logic. I'm not sure of the details as to why; would have to ask him about it. > I initially thought this was a bad idea, especially since the current > Rails approach works fine, as long as you are not hung up on your > first public release ending in zero. > > However, the thing that immediately convinced me otherwise - I'm very > pragmatic ;) - is that this would allow ANY prerelease gem to be > pushed to rubyforge, and people would not automatically pull it down, > because the default would be to NOT download any prerelease gems. Yes, this would reduce the need for projects to run their own gem servers. Some large ones still might want to in order to reduce the delay in pushing out to a number of mirrors, but it levels the playing field a bit for smaller projects. > I'm really interested to see how they are going to do this without the > non-numeric versions breaking old versions of rubygems, but I'm > hopeful :) One thing we do is automatically check for prerelease versions when the gemspec is built, and add the correct required_rubygems_version field where appropriate. But this is not a complete solution. It prevents prerelease gems from sneaking in, but it doesn't prevent old clients from trying (and failing) to install the prerelease where it should be trying to install the latest stable. The approach that Eric suggested was to exclude prerelease gems from the "latest" source index and pull in the "full" source index when looking for prerelease gems. This is implemented, but there are some cases when we need the full source index but do not want prereleases installed. We can add guards for this in the next version of Rubygems, but I can't think of a way to handle this for pre-1.4 clients using this strategy. The only solution I can think of is to add a third source index for prereleases so they don't go into the full index *or* the latest index. As you can see, this is a bit of a hairy issue. But I think the status field that Daniel proposed would be subject to the exact same challenges when attempting to maintain backwards compatibility. Any ideas? Is adding a third index too drastic? -Phil From ryand-ruby at zenspider.com Tue Nov 11 13:32:00 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 11 Nov 2008 10:32:00 -0800 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: <20081111165118.GW31071@hinegardner.org> References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> <20081111165118.GW31071@hinegardner.org> Message-ID: <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> On Nov 11, 2008, at 08:51 , Jeremy Hinegardner wrote: > rf.scrape_project('rubygems') yup yup... scraping is the only current way to go in this case. unfortunately :( although, another cheap/easy possibility is that we always upload the rubygems package to the rubygems download dir... unfortunately, it looks like some of the mirrors aren't rsyncing correctly: http://gemmirror.xaop.net/gems/ gives a 403/forbidden. From ryand-ruby at zenspider.com Tue Nov 11 13:37:40 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue, 11 Nov 2008 10:37:40 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87abc6fahd.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> Message-ID: On Nov 11, 2008, at 09:17 , Phil Hagelberg wrote: > * Version parts with letters are prerelease (e.g. 'a', 'b5', or > 'RC1'). the second you do this you're gonna get bugs filed saying that you didn't sort the versions the way the user intended... how do you sort 'a1' vs 'b5' vs 'rc1' vs 'z7'? it is all a mess as far as I'm concerned. For ruby2c, I released 1.0.0 beta 1-5 which I versioned as 1.0.0.1 to 1.0.0.5. It seemed to work fine for me so far... I intentionally didn't do any alphas or rc's etc. but I wanted to be clear that it wasn't a clean 1.0.0 release. From technomancy at gmail.com Tue Nov 11 13:59:00 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Tue, 11 Nov 2008 10:59:00 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: (Ryan Davis's message of "Tue, 11 Nov 2008 10:37:40 -0800") References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> Message-ID: <87wsfadr7v.fsf@hagelb.org> Ryan Davis writes: >> * Version parts with letters are prerelease (e.g. 'a', 'b5', or >> RC1'). > > the second you do this you're gonna get bugs filed saying that you > didn't sort the versions the way the user intended... how do you sort > a1' vs 'b5' vs 'rc1' vs 'z7'? Really? String#<=> is pretty well-understood as far as I can tell. > For ruby2c, I released 1.0.0 beta 1-5 which I versioned as 1.0.0.1 to > 1.0.0.5. It seemed to work fine for me so far... I intentionally > didn't do any alphas or rc's etc. but I wanted to be clear that it > wasn't a clean 1.0.0 release. 1.0.0.1 looks like a very-minor increment on a 1.0.0 release. If I were to see that version available without reading through all the release announcements, I would have gone ahead and installed it. Any scheme that relies on users being thorough about reading the release notes is suspect in my mind. Also, issuing a gem update ruby2c would have pulled in this version, which is definitely not what users would expect. Did you keep it on a separate server? -Phil From thewoolleyman at gmail.com Tue Nov 11 14:40:58 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 12:40:58 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87wsfadr7v.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> Message-ID: On Tue, Nov 11, 2008 at 11:59 AM, Phil Hagelberg wrote: > Ryan Davis writes: > > >> * Version parts with letters are prerelease (e.g. 'a', 'b5', or > >> RC1'). > > > > the second you do this you're gonna get bugs filed saying that you > > didn't sort the versions the way the user intended... how do you sort > > a1' vs 'b5' vs 'rc1' vs 'z7'? > > Really? String#<=> is pretty well-understood as far as I can tell. > I agreed. Standard ruby string comparison follows the principle of least surprise. > > For ruby2c, I released 1.0.0 beta 1-5 which I versioned as 1.0.0.1 to > > 1.0.0.5. It seemed to work fine for me so far... I intentionally > > didn't do any alphas or rc's etc. but I wanted to be clear that it > > wasn't a clean 1.0.0 release. > > 1.0.0.1 looks like a very-minor increment on a 1.0.0 release. If I were > to see that version available without reading through all the release > announcements, I would have gone ahead and installed it. Any scheme that > relies on users being thorough about reading the release notes is > suspect in my mind. > > Also, issuing a gem update ruby2c would have pulled in this version, > which is definitely not what users would expect. Did you keep it on a > separate server? > Yes, 1.0.0.4 and 1.0.0.5 are on RubyForge (took a while to figure out that it is Ruby*To*C, not ruby2c, but anyway). This is also not a case that adequately illustrates the problems being discussed, because there are no prior releases before these. If there were already some 0.9.x releases on rubyforge, this approach would make sense (other than the fact that they are on rubyforge, more on that below), and be similar to the current Rails 2.2 approach, assuming Ryan versions the "final" 1.0 release as 1.0.1 or 1.1.0. However, the difference is that these 'beta' gems were pushed to rubyforge, whereas Rails is not going to push any prerelease gems to rubyforge. This is the problem Phil is talking about. Unless users (or dependent gems) are smart and/or diligent enough to manage their dependencies correctly and pessimistically (which nobody is or ever will be), they will still unknowingly pull down these "beta" gems if they are on RubyForge. The proposed approach solves all these problems, except for the old rubygems version's index problem. I think (not having looked at the code) a third index for the new non-numeric versions is probably the safest and best way to solve this in a way that will not break the world, but unfortunately probably also the most work to implement properly. -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgs at dmu.ac.uk Tue Nov 11 14:41:52 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue, 11 Nov 2008 19:41:52 +0000 (GMT) Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87wsfadr7v.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> Message-ID: On Tue, 11 Nov 2008, Phil Hagelberg wrote: > Ryan Davis writes: > > >> * Version parts with letters are prerelease (e.g. 'a', 'b5', or > >> RC1'). > > > > the second you do this you're gonna get bugs filed saying that you > > didn't sort the versions the way the user intended... how do you sort > > a1' vs 'b5' vs 'rc1' vs 'z7'? > > Really? String#<=> is pretty well-understood as far as I can tell. Oh, I bet will get scarier than that: Locale, current character set, multibyte chars, utf-[8,16,32], and is the -K option in use, and are we doing case sensitive matches or not? {Is anyone still using EBCDIC? I hope not, that's scarier than some of the things lurking in Dwemthy's Array! :-)} > > > For ruby2c, I released 1.0.0 beta 1-5 which I versioned as 1.0.0.1 to > > 1.0.0.5. It seemed to work fine for me so far... I intentionally > > didn't do any alphas or rc's etc. but I wanted to be clear that it > > wasn't a clean 1.0.0 release. > > 1.0.0.1 looks like a very-minor increment on a 1.0.0 release. If I were > to see that version available without reading through all the release > announcements, I would have gone ahead and installed it. Any scheme that > relies on users being thorough about reading the release notes is > suspect in my mind. Agreed, but we do have a tradition in the Ruby world about odd minor version numbers, so another convention for what I've called tiddler numbers seems possible. Staying numeric would be better. If not negatives, then maybe a number that can only be read as Hex might work, except a naive to_i would turn it to 0. "To 0xff thou shalt not count, and complex is right out!". That only leaves rationals unexplored and allowing a / in the version number might allow people to be scared off sufficiently, version 1.0.0.2/3 looks pretty odd. I only offer these in the hope that they'll spark something useful, since in themselves they are not, I think. Lateral thinking is about getting to a better place from here if there is such a place. > Hugh From tom at infoether.com Tue Nov 11 16:59:29 2008 From: tom at infoether.com (Tom Copeland) Date: Tue, 11 Nov 2008 16:59:29 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> <20081111165118.GW31071@hinegardner.org> <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> Message-ID: <3F189FAD-5CDF-4F68-AFB3-81FC28A9CE43@infoether.com> On Nov 11, 2008, at 1:32 PM, Ryan Davis wrote: > > On Nov 11, 2008, at 08:51 , Jeremy Hinegardner wrote: > >> rf.scrape_project('rubygems') > > yup yup... scraping is the only current way to go in this case. > unfortunately :( > > although, another cheap/easy possibility is that we always upload > the rubygems package to the rubygems download dir... unfortunately, > it looks like some of the mirrors aren't rsyncing correctly: > > http://gemmirror.xaop.net/gems/ > > gives a 403/forbidden. Yup, but this works: http://gemmirror.xaop.net/gems/rails-2.1.1.gem I think maybe they just don't have DirectoryIndex enabled in their Apache configs... Yours, Tom From technomancy at gmail.com Tue Nov 11 17:37:15 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Tue, 11 Nov 2008 14:37:15 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: (Hugh Sasse's message of "Tue, 11 Nov 2008 19:41:52 +0000 (GMT)") References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> Message-ID: <87prl1evok.fsf@hagelb.org> Hugh Sasse writes: >> Really? String#<=> is pretty well-understood as far as I can tell. > > Oh, I bet will get scarier than that: Locale, current character set, > multibyte chars, utf-[8,16,32], and is the -K option in use, and are > we doing case sensitive matches or not? {Is anyone still using EBCDIC? > I hope not, that's scarier than some of the things lurking in Dwemthy's > Array! :-)} It shouldn't be a surprise that things will break if you put a character with locale-dependent sorting in your version string. We don't have to support *every* string, merely that subset of strings that gem authors (on the whole a reasonable bunch, if I may generalize) would pick as version numbers. True; there's some potential insanity lurking there. But I think if you're going to go off the beaten track, it's pretty easy to make sure things are sorting the way you expect using IRB. >> 1.0.0.1 looks like a very-minor increment on a 1.0.0 release. If I were >> to see that version available without reading through all the release >> announcements, I would have gone ahead and installed it. Any scheme that >> relies on users being thorough about reading the release notes is >> suspect in my mind. > > Agreed, but we do have a tradition in the Ruby world about odd minor > version numbers Well, we *had* that tradition, but now Ruby 1.9.1 is going to be considered the stable release. > so another convention for what I've called tiddler numbers seems > possible. Staying numeric would be better. The problem with this is that it makes the number of digits significant. Rubygems doesn't currently force the use of three dot-separated parts. Most projects use that, but it's not enforced. If we change what is allowed, it should be as a superset of what's currently allowed, or we will introduce resistance to upgrades. > If not negatives, then maybe a number that can only be read as Hex > might work, except a naive to_i would turn it to 0. "To 0xff thou > shalt not count, and complex is right out!". That only leaves > rationals unexplored and allowing a / in the version number might > allow people to be scared off sufficiently, version 1.0.0.2/3 looks > pretty odd. > > I only offer these in the hope that they'll spark something useful, > since in themselves they are not, I think. Lateral thinking is about > getting to a better place from here if there is such a place. There's certainly a place for brainstorming, as long as it's clear that's what's happening rather than a serious suggestion. =) -Phil From thewoolleyman at gmail.com Tue Nov 11 17:39:52 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 15:39:52 -0700 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: <3F189FAD-5CDF-4F68-AFB3-81FC28A9CE43@infoether.com> References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> <20081111165118.GW31071@hinegardner.org> <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> <3F189FAD-5CDF-4F68-AFB3-81FC28A9CE43@infoether.com> Message-ID: On Tue, Nov 11, 2008 at 2:59 PM, Tom Copeland wrote: > Yup, but this works: > > http://gemmirror.xaop.net/gems/rails-2.1.1.gem > > I think maybe they just don't have DirectoryIndex enabled in their Apache > configs... > That's lame. That means that the 'gems' link on this page will fail intermittently depending on which mirror you hit: http://gems.rubyforge.org/ All the mirror owners should turn it on for the gems dir, or that link should be smart enough not to go to a mirror returning a 403... -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Tue Nov 11 17:42:41 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 11 Nov 2008 15:42:41 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87prl1evok.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <87prl1evok.fsf@hagelb.org> Message-ID: On Tue, Nov 11, 2008 at 3:37 PM, Phil Hagelberg wrote: > Hugh Sasse writes: > > > Agreed, but we do have a tradition in the Ruby world about odd minor > > version numbers > > Well, we *had* that tradition, but now Ruby 1.9.1 is going to be > considered the stable release. > > > so another convention for what I've called tiddler numbers seems > > possible. Staying numeric would be better. > > The problem with this is that it makes the number of digits > significant. Rubygems doesn't currently force the use of three > dot-separated parts. Most projects use that, but it's not enforced. > I'd venture to say that most gem owners don't follow the odd/even convention. Plus, with auto-generated gems (like GitHub does), it's very useful to use a timestamp as a component of your version (optionally prefixed with an IRB-sortable non-numeric character). -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at infoether.com Tue Nov 11 20:25:11 2008 From: tom at infoether.com (Tom Copeland) Date: Tue, 11 Nov 2008 20:25:11 -0500 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> <20081111165118.GW31071@hinegardner.org> <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> <3F189FAD-5CDF-4F68-AFB3-81FC28A9CE43@infoether.com> Message-ID: <58FA55F8-8267-4094-B47A-185CD6642F1A@infoether.com> On Nov 11, 2008, at 5:39 PM, Chad Woolley wrote: > On Tue, Nov 11, 2008 at 2:59 PM, Tom Copeland > wrote: > Yup, but this works: > > http://gemmirror.xaop.net/gems/rails-2.1.1.gem > > I think maybe they just don't have DirectoryIndex enabled in their > Apache configs... > > That's lame. That means that the 'gems' link on this page will fail > intermittently depending on which mirror you hit: http://gems.rubyforge.org/ Yup. Maybe that link should be removed... not sure how useful that directory listing is even if it's enabled. > All the mirror owners should turn it on for the gems dir, Hm, perhaps that's true. Yours, Tom From ryand-ruby at zenspider.com Wed Nov 12 04:39:52 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 12 Nov 2008 01:39:52 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <87wsfadr7v.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> Message-ID: <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: > Really? String#<=> is pretty well-understood as far as I can tell. yes... it is very well understood to be very bad for this problem: >> "a2" <=> "a11" => 1 >> 2 <=> 11 => -1 From ryand-ruby at zenspider.com Wed Nov 12 04:41:19 2008 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Wed, 12 Nov 2008 01:41:19 -0800 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: <005E6CAA-5EE8-455C-8D48-9812516D1A2F@gmail.com> <57678181-F4B2-4C83-820D-3916D9B2E8A6@gmail.com> <20081111165118.GW31071@hinegardner.org> <62139EDD-9F8D-4DF5-A6BE-B2B9AA9F5D4D@zenspider.com> <3F189FAD-5CDF-4F68-AFB3-81FC28A9CE43@infoether.com> Message-ID: <05E0B22B-B755-4419-AAEA-82908BEA6BF0@zenspider.com> On Nov 11, 2008, at 14:39 , Chad Woolley wrote: > All the mirror owners should turn it on for the gems dir, or that > link should be smart enough not to go to a mirror returning a 403... or the gemserver should create an explicit index.. that way apache config doesn't even come into play (beyond defaulting to index.html). From luislavena at gmail.com Wed Nov 12 06:14:14 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 12 Nov 2008 08:14:14 -0300 Subject: [Rubygems-developers] Persistent URI for rubyforge rubygems downloads? In-Reply-To: References: Message-ID: <71166b3b0811120314i2e0dbdd1u918001114bd2d905@mail.gmail.com> On Tue, Nov 11, 2008 at 6:37 AM, Chad Woolley wrote: > > > On Mon, Nov 10, 2008 at 9:53 PM, Tom Copeland wrote: >> >> The RubyForge file downloads are more or less round-robined between the >> various mirror servers... I say "more or less" because some server are >> handed more requests than others. But all the mirrors should be serving all >> files after the rsync'ing process has finished... > > That doesn't appear to be the case. For example, this link is still valid: > > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.0.tgz > > However, this one (manually edited to point to 1.3.1) is not: > > http://rubyforge.org/frs/download.php/43985/rubygems-1.3.1.tgz > > I can only download 1.3.1 if I use this different mirror (linked from the > rubygems files page): > > http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz > > ...which means I had to update the URL in my scripts. > > Regardless, even if the 43985 mirror worked for 1.3.1, it still wouldn't be > enough to make scripts stable because: > > 1. A currently-valid mirror could go offline in the future > 2. There is still no generic url to grab the "latest" without hardcoding the > version in the url - which means scripts must still be updated even if all > mirrors worked and stayed around forever. > 45905 like 43985 (for 1.3.0) refers to the release package in GForce software, is not a permanent URL that you can reference. We deal the same while updating rubyinstaller scripts. -- 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 josh at hasmanythrough.com Wed Nov 12 06:17:21 2008 From: josh at hasmanythrough.com (Josh Susser) Date: Wed, 12 Nov 2008 06:17:21 -0500 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> Message-ID: <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: > > On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: > >> Really? String#<=> is pretty well-understood as far as I can tell. > > > yes... it is very well understood to be very bad for this problem: > > >> "a2" <=> "a11" > => 1 > >> 2 <=> 11 > => -1 So use a.1 and a.11 instead of a1 and a11 def test_order numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] versions = numbers.collect { |n| Gem::Version.new(n) } assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } end -- Josh Susser http://blog.hasmanythrough.com From djberg96 at gmail.com Thu Nov 13 00:26:17 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Wed, 12 Nov 2008 22:26:17 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> Message-ID: <491BBA79.3020509@gmail.com> Josh Susser wrote: > > On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: > >> >> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: >> >>> Really? String#<=> is pretty well-understood as far as I can tell. >> >> >> yes... it is very well understood to be very bad for this problem: >> >> >> "a2" <=> "a11" >> => 1 >> >> 2 <=> 11 >> => -1 > > > So use a.1 and a.11 instead of a1 and a11 > > def test_order > numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] > versions = numbers.collect { |n| Gem::Version.new(n) } > assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } > end I can't say I like where this is going. In my opinion this is going to lead to unforeseen issues. I don't know what those issues are exactly, I just have a very bad feeling about it. I recommend holding off on this for now. Regards, Dan From luislavena at gmail.com Thu Nov 13 06:13:06 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Nov 2008 08:13:06 -0300 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <491BBA79.3020509@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> Message-ID: <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger wrote: > Josh Susser wrote: >> >> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: >> >>> >>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: >>> >>>> Really? String#<=> is pretty well-understood as far as I can tell. >>> >>> >>> yes... it is very well understood to be very bad for this problem: >>> >>> >> "a2" <=> "a11" >>> => 1 >>> >> 2 <=> 11 >>> => -1 >> >> >> So use a.1 and a.11 instead of a1 and a11 >> >> def test_order >> numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] >> versions = numbers.collect { |n| Gem::Version.new(n) } >> assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } >> end > > I can't say I like where this is going. > > In my opinion this is going to lead to unforeseen issues. I don't know what > those issues are exactly, I just have a very bad feeling about it. > > I recommend holding off on this for now. > > Regards, > My guts tell me the same, but I guess is too late since several of these commits made to the trunk already. There is already a big nightmare (not to say gem hell) related to preview/rc gems laying in github or rubyforge that complicate the environment of many users (I get several reports about that). As example I can mention rspec gem depending on a patched version of rcov that only exist in github and has no binaries for it. Having that dependency buried and hidden from users make it hard to track. I believe pushing RC or preview versions to rubyforge will make "gem update" for several users a nightmare. As example, take gems that require compilation. Noone cares about this situation, but rubygems is dumb in this aspect, it will pick the latest version available with "ruby" as platform and try to compile it. If you lack the toolchain (either b'cause you're in a server or in Windows) you will make your environment bomb out and get lot of negavtive experiences from users. Previously, no RC or preview gem was published to rubyforge. Previews and RC where available through private gem servers to avoid this situation letting the developers control how and when these gems will hit the mirrors and made into the public. I don't see big OS distros like Ubuntu or even debian opening the room for RC and preview packages to their official distribution repositories. Anyway, just my PoV, this will also render useless patterns like "~>" and even worse dumb developers that do not check or maintain their dependency list properly. -- 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 transfire at gmail.com Thu Nov 13 08:22:56 2008 From: transfire at gmail.com (Trans) Date: Thu, 13 Nov 2008 05:22:56 -0800 (PST) Subject: [Rubygems-developers] Gem#status? In-Reply-To: <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> Message-ID: <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> On Nov 13, 6:13?am, "Luis Lavena" wrote: > On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger wrote: > > Josh Susser wrote: > > >> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: > > >>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: > > >>>> Really? String#<=> is pretty well-understood as far as I can tell. > > >>> yes... it is very well understood to be very bad for this problem: > > >>> >> "a2" <=> "a11" > >>> => 1 > >>> >> 2 <=> 11 > >>> => -1 > > >> So use a.1 and a.11 instead of a1 and a11 > > >> ?def test_order > >> ? ?numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] > >> ? ?versions = numbers.collect { |n| Gem::Version.new(n) } > >> ? ?assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } > >> ?end > > > I can't say I like where this is going. > > > In my opinion this is going to lead to unforeseen issues. I don't know what > > those issues are exactly, I just have a very bad feeling about it. > > > I recommend holding off on this for now. > > > Regards, > > My guts tell me the same, but I guess is too late since several of > these commits made to the trunk already. > > There is already a big nightmare (not to say gem hell) related to > preview/rc gems laying in github or rubyforge that complicate the > environment of many users (I get several reports about that). As > example I can mention rspec gem depending on a patched version of rcov > that only exist in github and has no binaries for it. > > Having that dependency buried and hidden from users make it hard to track. > > I believe pushing RC or preview versions to rubyforge will make "gem > update" for several users a nightmare. As example, take gems that > require compilation. > > Noone cares about this situation, but rubygems is dumb in this aspect, > it will pick the latest version available with "ruby" as platform and > try to compile it. If you lack the toolchain (either b'cause you're in > a server or in Windows) you will make your environment bomb out and > get lot of negavtive experiences from users. > > Previously, no RC or preview gem was published to rubyforge. Previews > and RC where available through private gem servers to avoid this > situation letting the developers control how and when these gems will > hit the mirrors and made into the public. > > I don't see big OS distros like Ubuntu or even debian opening the room > for RC and preview packages to their official distribution > repositories. I've occasionally seen pre-releases in the repositories. > Anyway, just my PoV, this will also render useless patterns like "~>" > and even worse dumb developers that do not check or maintain their > dependency list properly. I'm not sure why it's so hard to make RubyGems understand that 1.0.0rc10 > 1.0.0rc1 and 1.0.0 > 1.0.0rc1 That's really all that's needed. And ~> should just not consider any version with lettering at the end. T. From luislavena at gmail.com Thu Nov 13 08:26:27 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Nov 2008 10:26:27 -0300 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> Message-ID: <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> On Thu, Nov 13, 2008 at 10:22 AM, Trans wrote: > > > On Nov 13, 6:13 am, "Luis Lavena" wrote: >> On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger wrote: >> > Josh Susser wrote: >> >> >> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: >> >> >>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: >> >> >>>> Really? String#<=> is pretty well-understood as far as I can tell. >> >> >>> yes... it is very well understood to be very bad for this problem: >> >> >>> >> "a2" <=> "a11" >> >>> => 1 >> >>> >> 2 <=> 11 >> >>> => -1 >> >> >> So use a.1 and a.11 instead of a1 and a11 >> >> >> def test_order >> >> numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] >> >> versions = numbers.collect { |n| Gem::Version.new(n) } >> >> assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } >> >> end >> >> > I can't say I like where this is going. >> >> > In my opinion this is going to lead to unforeseen issues. I don't know what >> > those issues are exactly, I just have a very bad feeling about it. >> >> > I recommend holding off on this for now. >> >> > Regards, >> >> My guts tell me the same, but I guess is too late since several of >> these commits made to the trunk already. >> >> There is already a big nightmare (not to say gem hell) related to >> preview/rc gems laying in github or rubyforge that complicate the >> environment of many users (I get several reports about that). As >> example I can mention rspec gem depending on a patched version of rcov >> that only exist in github and has no binaries for it. >> >> Having that dependency buried and hidden from users make it hard to track. >> >> I believe pushing RC or preview versions to rubyforge will make "gem >> update" for several users a nightmare. As example, take gems that >> require compilation. >> >> Noone cares about this situation, but rubygems is dumb in this aspect, >> it will pick the latest version available with "ruby" as platform and >> try to compile it. If you lack the toolchain (either b'cause you're in >> a server or in Windows) you will make your environment bomb out and >> get lot of negavtive experiences from users. >> >> Previously, no RC or preview gem was published to rubyforge. Previews >> and RC where available through private gem servers to avoid this >> situation letting the developers control how and when these gems will >> hit the mirrors and made into the public. >> >> I don't see big OS distros like Ubuntu or even debian opening the room >> for RC and preview packages to their official distribution >> repositories. > > I've occasionally seen pre-releases in the repositories. > >> Anyway, just my PoV, this will also render useless patterns like "~>" >> and even worse dumb developers that do not check or maintain their >> dependency list properly. > > I'm not sure why it's so hard to make RubyGems understand that > > 1.0.0rc10 > 1.0.0rc1 > > and > > 1.0.0 > 1.0.0rc1 > > That's really all that's needed. > > And ~> should just not consider any version with lettering at the end. > > T. So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the user system. Riiight. That also bring things related to cleanup of these gems... what to do if you're not considering these cases in full spectrum? -- 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 djberg96 at gmail.com Thu Nov 13 09:10:54 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Thu, 13 Nov 2008 07:10:54 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> Message-ID: <6037b70c0811130610j2dcf07f6p9dcd1f841f33a6d7@mail.gmail.com> On Thu, Nov 13, 2008 at 4:13 AM, Luis Lavena wrote: > On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger wrote: >> Josh Susser wrote: >>> >>> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: >>> >>>> >>>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: >>>> >>>>> Really? String#<=> is pretty well-understood as far as I can tell. >>>> >>>> >>>> yes... it is very well understood to be very bad for this problem: >>>> >>>> >> "a2" <=> "a11" >>>> => 1 >>>> >> 2 <=> 11 >>>> => -1 >>> >>> >>> So use a.1 and a.11 instead of a1 and a11 >>> >>> def test_order >>> numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] >>> versions = numbers.collect { |n| Gem::Version.new(n) } >>> assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } >>> end >> >> I can't say I like where this is going. >> >> In my opinion this is going to lead to unforeseen issues. I don't know what >> those issues are exactly, I just have a very bad feeling about it. >> >> I recommend holding off on this for now. >> >> Regards, >> > > My guts tell me the same, but I guess is too late since several of > these commits made to the trunk already. What's done can be undone. > There is already a big nightmare (not to say gem hell) related to > preview/rc gems laying in github or rubyforge that complicate the > environment of many users (I get several reports about that). As > example I can mention rspec gem depending on a patched version of rcov > that only exist in github and has no binaries for it. I feel like there's an element of personal responsibility here that we're trying to work around with a technical solution. > Having that dependency buried and hidden from users make it hard to track. > > I believe pushing RC or preview versions to rubyforge will make "gem > update" for several users a nightmare. As example, take gems that > require compilation. > > Noone cares about this situation, but rubygems is dumb in this aspect, > it will pick the latest version available with "ruby" as platform and > try to compile it. If you lack the toolchain (either b'cause you're in > a server or in Windows) you will make your environment bomb out and > get lot of negavtive experiences from users. This is one of the reasons I think we need to bring back generic platform constants. But, that's another story. > Previously, no RC or preview gem was published to rubyforge. Previews > and RC where available through private gem servers to avoid this > situation letting the developers control how and when these gems will > hit the mirrors and made into the public. I'm tempted to say that it should be left this way. You really want to install an RC release? You'll have to go through a little extra effort to get it. > I don't see big OS distros like Ubuntu or even debian opening the room > for RC and preview packages to their official distribution > repositories. > > Anyway, just my PoV, this will also render useless patterns like "~>" > and even worse dumb developers that do not check or maintain their > dependency list properly. Plus, as you mentioned in a later email, we'll need to work out the rules for gem clean and gem uninstall. Regards, Dan From technomancy at gmail.com Thu Nov 13 12:52:33 2008 From: technomancy at gmail.com (Phil Hagelberg) Date: Thu, 13 Nov 2008 09:52:33 -0800 Subject: [Rubygems-developers] Prerelease Gems (was: Gem#status?) In-Reply-To: <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> (Luis Lavena's message of "Thu, 13 Nov 2008 08:13:06 -0300") References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> Message-ID: <87k5b71pjy.fsf_-_@hagelb.org> "Luis Lavena" writes: > There is already a big nightmare (not to say gem hell) related to > preview/rc gems laying in github or rubyforge that complicate the > environment of many users (I get several reports about that). As > example I can mention rspec gem depending on a patched version of rcov > that only exist in github and has no binaries for it. Right now a lot of people keep prerelease gems on github only. This is because there's no good way to handle them in Rubyforge. Currently if someone installs a stable release of a gem (on github, or any source that's been added) and then issues a "gem update" after a prerelease has been pushed out, they will pull it in even if they want to stick with the stable release. This problem will be alleviated if rubygems has a way of distinguishing between stable releases and prereleases. > I believe pushing RC or preview versions to rubyforge will make "gem > update" for several users a nightmare. This is exactly what I'm working on right now. It's not like we're just tossing prerelease gems into a big pile and calling it done; we're taking special care to make sure that they only get pulled in when they're explicitly requested. > Previously, no RC or preview gem was published to rubyforge. That's not true; see Ryan's earlier post. Previously there's been no sane way to handle prereleases, so everyone does it differently. Merb has one way, Rails has another, other people make up their own. I've run the idea by Rick Olson of Rails core, and he is in favour of it. Everyone I mentioned it to at RubyConf was eager to see it implemented. > Previews and RC where available through private gem servers to avoid > this situation letting the developers control how and when these gems > will hit the mirrors and made into the public. But this also means that nobody can offer prerelease gems unless they're willing to run their own gem servers (or willing to seriously confound the users of their gems.) If Rubyforge can offer this service, it will level the playing field for smaller projects. > I don't see big OS distros like Ubuntu or even debian opening the room > for RC and preview packages to their official distribution > repositories. Oh, don't they? (http://p.hagelb.org/prerelease.png) Even if that weren't the case, there are a lot of things apt-get doesn't do that we do, like allowing multiple versions of a gem to be installed at the same time. If we were to blindly follow their lead, we would lose a lot of really useful functionality. Gems have a *much* more rapid pace of change than debs do; it's only natural that the infrastructure should reflect this. > Anyway, just my PoV, this will also render useless patterns like "~>" > and even worse dumb developers that do not check or maintain their > dependency list properly. Actually, the whole point of this is to *fix* the usage of ~> for prereleases. Right now if you want to depend on version 0.9 of Merb, you will pull in their 1.0 RC, because its version is 0.9.99 or some such. A lot of projects use this versioning scheme, and it renders major-version-only matching useless. If you read carefully over the proposed solution and can come up with a real flaw in it, then *please* bring it up. If you've found some edge case that I haven't thought of, I'm all ears. But vague fears and doubts really do very little to help the situation. That said, I'm willing to defer to Eric's judgment if he can find merit in any of the objections that have been raised. -Phil From transfire at gmail.com Thu Nov 13 13:34:47 2008 From: transfire at gmail.com (Trans) Date: Thu, 13 Nov 2008 10:34:47 -0800 (PST) Subject: [Rubygems-developers] Gem#status? In-Reply-To: <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> Message-ID: <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> On Nov 13, 8:26?am, "Luis Lavena" wrote: > On Thu, Nov 13, 2008 at 10:22 AM, Trans wrote: > > > On Nov 13, 6:13 am, "Luis Lavena" wrote: > >> On Thu, Nov 13, 2008 at 2:26 AM, Daniel Berger wrote: > >> > Josh Susser wrote: > > >> >> On Nov 12, 2008, at 4:39 AM, Ryan Davis wrote: > > >> >>> On Nov 11, 2008, at 10:59 , Phil Hagelberg wrote: > > >> >>>> Really? String#<=> is pretty well-understood as far as I can tell. > > >> >>> yes... it is very well understood to be very bad for this problem: > > >> >>> >> "a2" <=> "a11" > >> >>> => 1 > >> >>> >> 2 <=> 11 > >> >>> => -1 > > >> >> So use a.1 and a.11 instead of a1 and a11 > > >> >> ?def test_order > >> >> ? ?numbers = %w[ 1.0.a 1.0.a.1 1.0.a.2 1.0.a.11 1.0.b.1 1 1.0.1 1.2 ] > >> >> ? ?versions = numbers.collect { |n| Gem::Version.new(n) } > >> >> ? ?assert_equal numbers, versions.sort.collect { |v| v.parts.join(".") } > >> >> ?end > > >> > I can't say I like where this is going. > > >> > In my opinion this is going to lead to unforeseen issues. I don't know what > >> > those issues are exactly, I just have a very bad feeling about it. > > >> > I recommend holding off on this for now. > > >> > Regards, > > >> My guts tell me the same, but I guess is too late since several of > >> these commits made to the trunk already. > > >> There is already a big nightmare (not to say gem hell) related to > >> preview/rc gems laying in github or rubyforge that complicate the > >> environment of many users (I get several reports about that). As > >> example I can mention rspec gem depending on a patched version of rcov > >> that only exist in github and has no binaries for it. > > >> Having that dependency buried and hidden from users make it hard to track. > > >> I believe pushing RC or preview versions to rubyforge will make "gem > >> update" for several users a nightmare. As example, take gems that > >> require compilation. > > >> Noone cares about this situation, but rubygems is dumb in this aspect, > >> it will pick the latest version available with "ruby" as platform and > >> try to compile it. If you lack the toolchain (either b'cause you're in > >> a server or in Windows) you will make your environment bomb out and > >> get lot of negavtive experiences from users. > > >> Previously, no RC or preview gem was published to rubyforge. Previews > >> and RC where available through private gem servers to avoid this > >> situation letting the developers control how and when these gems will > >> hit the mirrors and made into the public. > > >> I don't see big OS distros like Ubuntu or even debian opening the room > >> for RC and preview packages to their official distribution > >> repositories. > > > I've occasionally seen pre-releases in the repositories. > > >> Anyway, just my PoV, this will also render useless patterns like "~>" > >> and even worse dumb developers that do not check or maintain their > >> dependency list properly. > > > I'm not sure why it's so hard to make RubyGems understand that > > > ?1.0.0rc10 > 1.0.0rc1 > > > and > > > ?1.0.0 > 1.0.0rc1 > > > That's really all that's needed. > > > And ~> should just not consider any version with lettering at the end. > > > T. > > So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the user system. No. I think people use ~> when they expect very tight and rational versioning. So ~> means production code only, and rc30 would not fit the bill. That's what I meant by "not consider". If one wanted to accept rc versions, then use > or >= instead. > Riiight. That also bring things related to cleanup of these gems... > what to do if you're not considering these cases in full spectrum? Seems to me one should also be able to tell the gem command "consider production releases only". T. From josh at hasmanythrough.com Thu Nov 13 13:45:32 2008 From: josh at hasmanythrough.com (Josh Susser) Date: Thu, 13 Nov 2008 13:45:32 -0500 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> Message-ID: <7F9B6DEE-FAD7-4FF1-8873-F876ABA17D7F@hasmanythrough.com> On Nov 13, 2008, at 1:34 PM, Trans wrote: >> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the >> user system. > > No. I think people use ~> when they expect very tight and rational > versioning. So ~> means production code only, and rc30 would not fit > the bill. That's what I meant by "not consider". > > If one wanted to accept rc versions, then use > or >= instead. > >> Riiight. That also bring things related to cleanup of these gems... >> what to do if you're not considering these cases in full spectrum? > > Seems to me one should also be able to tell the gem command "consider > production releases only". That is the default with the new code. You need to use the -- prerelease option if you don't want prerelease gems to be ignored. -- Josh Susser http://blog.hasmanythrough.com From luislavena at gmail.com Thu Nov 13 14:07:32 2008 From: luislavena at gmail.com (Luis Lavena) Date: Thu, 13 Nov 2008 16:07:32 -0300 Subject: [Rubygems-developers] Prerelease Gems (was: Gem#status?) In-Reply-To: <87k5b71pjy.fsf_-_@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <87k5b71pjy.fsf_-_@hagelb.org> Message-ID: <71166b3b0811131107u4ca1cd84i6e778c6b9f7908de@mail.gmail.com> On Thu, Nov 13, 2008 at 2:52 PM, Phil Hagelberg wrote: > "Luis Lavena" writes: > >> There is already a big nightmare (not to say gem hell) related to >> preview/rc gems laying in github or rubyforge that complicate the >> environment of many users (I get several reports about that). As >> example I can mention rspec gem depending on a patched version of rcov >> that only exist in github and has no binaries for it. > > Right now a lot of people keep prerelease gems on github only. This is > because there's no good way to handle them in Rubyforge. Currently if > someone installs a stable release of a gem (on github, or any source > that's been added) and then issues a "gem update" after a prerelease has > been pushed out, they will pull it in even if they want to stick with > the stable release. This problem will be alleviated if rubygems has a > way of distinguishing between stable releases and prereleases. > The problem I faced with github gems is that people started to rely on that, and other gem developers started to push projects to rubyforge with dependencies on gems that only exist on github. Some users didn't add github source and faced mysterious errors while installing or doing gem update. >> I believe pushing RC or preview versions to rubyforge will make "gem >> update" for several users a nightmare. > > This is exactly what I'm working on right now. It's not like we're just > tossing prerelease gems into a big pile and calling it done; we're > taking special care to make sure that they only get pulled in when > they're explicitly requested. > Hmn, I haven't looked in the commits and the added new test to find a serious reference of pre-release, only the handling of letter for versioning (which doesn't mean prerelease or release at all). I can decide version my gem "1.2.abc" and and doesn't make it pre-release, just a silly versioning schema. >> Previously, no RC or preview gem was published to rubyforge. > > That's not true; see Ryan's earlier post. Previously there's been no > sane way to handle prereleases, so everyone does it differently. Merb > has one way, Rails has another, other people make up their own. I've run > the idea by Rick Olson of Rails core, and he is in favour of > it. Everyone I mentioned it to at RubyConf was eager to see it > implemented. Sorry my english, I wanted to say "publishing of preview/rc gems to rubyforge was not encouraged". >> Previews and RC where available through private gem servers to avoid >> this situation letting the developers control how and when these gems >> will hit the mirrors and made into the public. > > But this also means that nobody can offer prerelease gems unless they're > willing to run their own gem servers (or willing to seriously confound > the users of their gems.) If Rubyforge can offer this service, it will > level the playing field for smaller projects. > >> I don't see big OS distros like Ubuntu or even debian opening the room >> for RC and preview packages to their official distribution >> repositories. > > Oh, don't they? (http://p.hagelb.org/prerelease.png) > > Even if that weren't the case, there are a lot of things apt-get doesn't > do that we do, like allowing multiple versions of a gem to be installed > at the same time. If we were to blindly follow their lead, we would lose > a lot of really useful functionality. Gems have a *much* more rapid pace > of change than debs do; it's only natural that the infrastructure should > reflect this. > Is not the same case, is not enabled by default, which contrary to rubygems that depends on gems.rubyforge.org (and is the default one) I agree that gems evolve in a faster way than deb packages, and because of that, gem update can become more problematic. >> Anyway, just my PoV, this will also render useless patterns like "~>" >> and even worse dumb developers that do not check or maintain their >> dependency list properly. > > Actually, the whole point of this is to *fix* the usage of ~> for > prereleases. Right now if you want to depend on version 0.9 of Merb, you > will pull in their 1.0 RC, because its version is 0.9.99 or some such. A > lot of projects use this versioning scheme, and it renders > major-version-only matching useless. I concede you a point on that, been bitten by ~> as gem developer but also as user of these gems too. > If you read carefully over the proposed solution and can come up with a > real flaw in it, then *please* bring it up. If you've found some edge > case that I haven't thought of, I'm all ears. But vague fears and doubts > really do very little to help the situation. > I accept that the proposal is great (btw, a reference blog port will be great), and I thank the work done by you and contributions by Josh and Alex, but don't ignore the fact that developers will not use it properly and will not keep using >= to indicate a gem dependency. My comments came from the experience not only as gem developer but dealing with reports of people that installed gems, done gem updates with rubyforge as unique source and also those that added github too as "best practice" indicated in several forums. I often prefer expose my doubts about something that rant later about something that could have been done properly. If you scan the mailing list can find references to these things, as example the release of rubygems 0.9.5. > That said, I'm willing to defer to Eric's judgment if he can find merit > in any of the objections that have been raised. > > -Phil -- 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 Thu Nov 13 14:42:00 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 13 Nov 2008 12:42:00 -0700 Subject: [Rubygems-developers] Prerelease Gems (was: Gem#status?) In-Reply-To: <71166b3b0811131107u4ca1cd84i6e778c6b9f7908de@mail.gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <87k5b71pjy.fsf_-_@hagelb.org> <71166b3b0811131107u4ca1cd84i6e778c6b9f7908de@mail.gmail.com> Message-ID: On Thu, Nov 13, 2008 at 12:07 PM, Luis Lavena wrote: > The problem I faced with github gems is that people started to rely on > that, and other gem developers started to push projects to rubyforge > with dependencies on gems that only exist on github. > > Some users didn't add github source and faced mysterious errors while > installing or doing gem update. > Seems like there are two separate problems here. First is the fact that rubyforge.org is still the only default repo in rubygems, but people are pushing gems there that have dependencies on other repos (github). They do this unknowingly, because they have github set up as a source in their ~/.gemrc, and it works for them. This is already solveable with the --source parameter (even though it is clunky and could be improved) The second problem is the basic problem of verson management for prerelease versions, and allowing people to not get prereleases when they don't want them. This second problem is also already solvable with the current rubygems approach, if people (1) properly use pessimistic version constraints, and (2) use versions properly (a prerelease version should have a significant version bump so people can avoid pulling it with a pessimistic constraint), and (3) use a controlled dependency management approach in their apps (standard rubygems gem method with explicit version, rails config.gems, geminstaller, etc). Now, I'm not saying these are optimal solutions, because they depend on gem authors and users to know what they are doing, which isn't always likely or sustainable. However, any alternative we come up with should make the problem SIMPLER for the majority of people and not break other stuff majorly/unexpectedly, or else we might be better off sticking with the status quo. -- Chad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Thu Nov 13 15:17:45 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 13 Nov 2008 13:17:45 -0700 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <7F9B6DEE-FAD7-4FF1-8873-F876ABA17D7F@hasmanythrough.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> <7F9B6DEE-FAD7-4FF1-8873-F876ABA17D7F@hasmanythrough.com> Message-ID: On Thu, Nov 13, 2008 at 11:45 AM, Josh Susser wrote: > That is the default with the new code. You need to use the --prerelease > option if you don't want prerelease gems to be ignored. FYI, these changes don't appear to have broken anything in my functional tests on Linux or Mac: http://ci.thewoolleyweb.com/builds/geminstaller_trunk_using_rubygems_9-9-9/1120.7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drbrain at segment7.net Thu Nov 13 15:26:27 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Nov 2008 12:26:27 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <871vxif8j4.fsf@hagelb.org> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <871vxif8j4.fsf@hagelb.org> Message-ID: On Nov 11, 2008, at 09:59 AM, Phil Hagelberg wrote: > "Chad Woolley" writes: >> >> I'm really interested to see how they are going to do this without >> the >> non-numeric versions breaking old versions of rubygems, but I'm >> hopeful :) > > One thing we do is automatically check for prerelease versions when > the > gemspec is built, and add the correct required_rubygems_version field > where appropriate. But this is not a complete solution. It prevents > prerelease gems from sneaking in, but it doesn't prevent old clients > from trying (and failing) to install the prerelease where it should be > trying to install the latest stable. > > The approach that Eric suggested was to exclude prerelease gems from > the > "latest" source index and pull in the "full" source index when looking > for prerelease gems. > > This is implemented, but there are some cases when we need the full > source index but do not want prereleases installed. We can add guards > for this in the next version of Rubygems, but I can't think of a way > to > handle this for pre-1.4 clients using this strategy. The only > solution I > can think of is to add a third source index for prereleases so they > don't go into the full index *or* the latest index. This could be a problem when looking for gems where a prerelease and actual release match and you are trying to install an older version. I haven't tested this scenario to see what happens, though. Older RubyGems will treat a prerelease-versioned gem as having extra zeros. > As you can see, this is a bit of a hairy issue. But I think the status > field that Daniel proposed would be subject to the exact same > challenges when attempting to maintain backwards compatibility. > > Any ideas? Is adding a third index too drastic? That could be a good solution, have a prerelease-only index to solve the backwards compatibility problem I mentioned above. (If it is a problem, I don't know what older RubyGems do yet.) From drbrain at segment7.net Thu Nov 13 15:31:13 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Nov 2008 12:31:13 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <491BBA79.3020509@gmail.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> Message-ID: On Nov 12, 2008, at 21:26 PM, Daniel Berger wrote: >> [...] > > I can't say I like where this is going. > > In my opinion this is going to lead to unforeseen issues. I don't > know what those issues are exactly, I just have a very bad feeling > about it. > > I recommend holding off on this for now. FWIW, it'll probably be a month or two before I can put a release together, so we have plenty of time to go over the many issues. From drbrain at segment7.net Thu Nov 13 15:31:49 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Nov 2008 12:31:49 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> Message-ID: On Nov 11, 2008, at 11:41 AM, Hugh Sasse wrote: > On Tue, 11 Nov 2008, Phil Hagelberg wrote: >> Ryan Davis writes: >>>> * Version parts with letters are prerelease (e.g. 'a', 'b5', or >>>> RC1'). >>> >>> the second you do this you're gonna get bugs filed saying that you >>> didn't sort the versions the way the user intended... how do you >>> sort >>> a1' vs 'b5' vs 'rc1' vs 'z7'? >> >> Really? String#<=> is pretty well-understood as far as I can tell. > > Oh, I bet will get scarier than that: Locale, current character set, > multibyte chars, utf-[8,16,32], and is the -K option in use, and are > we doing case sensitive matches or not? {Is anyone still using > EBCDIC? > I hope not, that's scarier than some of the things lurking in > Dwemthy's > Array! :-)} It will be simple enough to restrict version characters to the ASCII range. From drbrain at segment7.net Thu Nov 13 15:51:48 2008 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 13 Nov 2008 12:51:48 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> Message-ID: On Nov 13, 2008, at 10:34 AM, Trans wrote: >> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the >> user system. > > No. I think people use ~> when they expect very tight and rational > versioning. So ~> means production code only, and rc30 would not fit > the bill. That's what I meant by "not consider". ~> 2.1.0 means any version between 2.1.0 and 2.1.9... only. It doesn't mean anything else (nor should it). 2.1.0.rc30 is less than 2.1.0, and 2.1.9... is less than 2.2.0.rc1. This was described further up the thread. If there exists a 2.1.5.rc1 and you specify the prerelease flag, then you should get what you asked for. > If one wanted to accept rc versions, then use > or >= instead. Adding the ability to install prerelease gems should not change what comparison means. From transfire at gmail.com Fri Nov 14 13:55:11 2008 From: transfire at gmail.com (Trans) Date: Fri, 14 Nov 2008 10:55:11 -0800 (PST) Subject: [Rubygems-developers] Gem#status? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> Message-ID: On Nov 13, 3:51?pm, Eric Hodel wrote: > On Nov 13, 2008, at 10:34 AM, Trans wrote: > > >> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the ? > >> user system. > > > No. I think people use ~> when they expect very tight and rational > > versioning. So ~> means production code only, and rc30 would not fit > > the bill. That's what I meant by "not consider". > > ~> 2.1.0 means any version between 2.1.0 and 2.1.9... only. ?It ? > doesn't mean anything else (nor should it). > > 2.1.0.rc30 is less than 2.1.0, and 2.1.9... is less than 2.2.0.rc1. ? > This was described further up the thread. Ok, great. That's exactly what I was saying. But is the extra dot necessary? "2.1.0rc1" and such is common, but an extra dot, I've seen anyone use that notation before. > If there exists a 2.1.5.rc1 and you specify the prerelease flag, then ? > you should get what you asked for. > > > If one wanted to accept rc versions, then use > or >= instead. > > Adding the ability to install prerelease gems should not change what ? > comparison means. There's two sides to this. Installing is one of them. What about the constraint on the gem method? T. From drbrain at segment7.net Fri Nov 14 17:57:10 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 14 Nov 2008 14:57:10 -0800 Subject: [Rubygems-developers] Gem#status? In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <87abc6fahd.fsf@hagelb.org> <87wsfadr7v.fsf@hagelb.org> <451575A1-EBB7-48CC-ABF0-82C39BA7AF8B@zenspider.com> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> Message-ID: <783C7A18-71DD-46C6-A80E-E3E6A91D0EFA@segment7.net> On Nov 14, 2008, at 10:55 AM, Trans wrote: > On Nov 13, 3:51 pm, Eric Hodel wrote: >> On Nov 13, 2008, at 10:34 AM, Trans wrote: >>>> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the >>>> user system. >> >>> No. I think people use ~> when they expect very tight and rational >>> versioning. So ~> means production code only, and rc30 would not fit >>> the bill. That's what I meant by "not consider". >> >> ~> 2.1.0 means any version between 2.1.0 and 2.1.9... only. It >> doesn't mean anything else (nor should it). >> >> 2.1.0.rc30 is less than 2.1.0, and 2.1.9... is less than 2.2.0.rc1. >> This was described further up the thread. > > Ok, great. That's exactly what I was saying. But is the extra dot > necessary? "2.1.0rc1" and such is common, but an extra dot, I've seen > anyone use that notation before. It makes things easier in RubyGems. > There's two sides to this. Installing is one of them. What about the > constraint on the gem method? Don't install prerelease gems if you don't want to use them. Uninstall prerelease gems if they don't work like you want. If you're going to a foot shooting party then RubyGems won't restrict you to a BB gun. From luislavena at gmail.com Fri Nov 14 18:11:48 2008 From: luislavena at gmail.com (Luis Lavena) Date: Fri, 14 Nov 2008 20:11:48 -0300 Subject: [Rubygems-developers] Gem#status? In-Reply-To: <783C7A18-71DD-46C6-A80E-E3E6A91D0EFA@segment7.net> References: <7524A45A1A5B264FA4809E2156496CFB04514E6E@ITOMAE2KM01.AD.QINTRA.COM> <696D74C9-56AA-4A97-8216-617B3507E095@hasmanythrough.com> <491BBA79.3020509@gmail.com> <71166b3b0811130313s7bdb421ao8c5556d1dd63a14a@mail.gmail.com> <9d19afee-b245-4190-8247-fdadcdf89403@b38g2000prf.googlegroups.com> <71166b3b0811130526m182524abj9ac4b5445006800@mail.gmail.com> <8217838e-c0eb-46c5-a37e-c4be3c9878ae@d36g2000prf.googlegroups.com> <783C7A18-71DD-46C6-A80E-E3E6A91D0EFA@segment7.net> Message-ID: <71166b3b0811141511r3d1b65a9kdbc358523ec23fe@mail.gmail.com> On Fri, Nov 14, 2008 at 7:57 PM, Eric Hodel wrote: > On Nov 14, 2008, at 10:55 AM, Trans wrote: >> >> On Nov 13, 3:51 pm, Eric Hodel wrote: >>> >>> On Nov 13, 2008, at 10:34 AM, Trans wrote: >>>>> >>>>> So ~> for 2.1.0 will be the same as 2.1.0.rc30 gem installed in the >>>>> user system. >>> >>>> No. I think people use ~> when they expect very tight and rational >>>> versioning. So ~> means production code only, and rc30 would not fit >>>> the bill. That's what I meant by "not consider". >>> >>> ~> 2.1.0 means any version between 2.1.0 and 2.1.9... only. It >>> doesn't mean anything else (nor should it). >>> >>> 2.1.0.rc30 is less than 2.1.0, and 2.1.9... is less than 2.2.0.rc1. >>> This was described further up the thread. >> >> Ok, great. That's exactly what I was saying. But is the extra dot >> necessary? "2.1.0rc1" and such is common, but an extra dot, I've seen >> anyone use that notation before. > > It makes things easier in RubyGems. > Cool with that. >> There's two sides to this. Installing is one of them. What about the >> constraint on the gem method? > > Don't install prerelease gems if you don't want to use them. Uninstall > prerelease gems if they don't work like you want. > > If you're going to a foot shooting party then RubyGems won't restrict you to > a BB gun. > So that means Kernel::gem or Kernel::require will automatically pick the RC version unless you explicitly tell them not to? Irb playing with Gem::Requirement and Gem::Versions looks like... -- 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 jeremy at hinegardner.org Fri Nov 14 18:55:42 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Fri, 14 Nov 2008 16:55:42 -0700 Subject: [Rubygems-developers] --destdir changed behavior again ? Message-ID: <20081114235542.GL31071@hinegardner.org> Hi all, I was packaging up rubygems 1.3.1 fo use at my work and it appears that the setup.rb behavior has changed since 1.2.0. in 1.2.0: ./setup.rb --destdir=/fakeroot/location Items get installed into: /fakeroot/location/usr/bin /fakeroot/location/usr/lib in 1.3.1 ( and 1.3.0 ) ./setup.rb --destdir=/fakeroot/location Items get installed into: /fakeroot/location/bin /fakeroot/location/lib Is the purpose now, if you want to use destdir, that you are required to also use --prefix? I don't know about others, but for me, --destdir means setting where '/' is supposed to be, and then rubygems should install relative to that as normal. The bug for me is all in : unless install_destdir.empty? top_dir = Pathname.new(RbConfig::TOPDIR) lib_dir_p = Pathname.new(lib_dir) bin_dir_p = Pathname.new(bin_dir) lib_dir = File.join install_destdir, lib_dir_p.relative_path_from(top_dir) bin_dir = File.join install_destdir, bin_dir_p.relative_path_from(top_dir) end I'm thinking it should really be: top_dir = Pathname.new(RbConfig::TOPDIR).parent thoughts? enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From avatar at spellboundnet.com Fri Nov 14 20:13:13 2008 From: avatar at spellboundnet.com (Donavan Pantke) Date: Fri, 14 Nov 2008 20:13:13 -0500 Subject: [Rubygems-developers] --destdir changed behavior again ? In-Reply-To: <20081114235542.GL31071@hinegardner.org> References: <20081114235542.GL31071@hinegardner.org> Message-ID: <200811142013.14446.avatar@spellboundnet.com> On Friday 14 November 2008 18:55:42 Jeremy Hinegardner wrote: > Hi all, > > I was packaging up rubygems 1.3.1 fo use at my work and it appears that the > setup.rb behavior has changed since 1.2.0. What distro are you packaging for? I just went through some RPM packaging work with 1.3.1 and so i might already have something you can use. Thanks! Donavan > > in 1.2.0: > > ./setup.rb --destdir=/fakeroot/location > > Items get installed into: > > /fakeroot/location/usr/bin > /fakeroot/location/usr/lib > > in 1.3.1 ( and 1.3.0 ) > > ./setup.rb --destdir=/fakeroot/location > > Items get installed into: > > /fakeroot/location/bin > /fakeroot/location/lib > > Is the purpose now, if you want to use destdir, that you are required to > also use --prefix? I don't know about others, but for me, --destdir > means setting where '/' is supposed to be, and then rubygems should > install relative to that as normal. > > The bug for me is all in : > > unless install_destdir.empty? > top_dir = Pathname.new(RbConfig::TOPDIR) > lib_dir_p = Pathname.new(lib_dir) > bin_dir_p = Pathname.new(bin_dir) > > lib_dir = File.join install_destdir, > lib_dir_p.relative_path_from(top_dir) bin_dir = File.join install_destdir, > bin_dir_p.relative_path_from(top_dir) end > > I'm thinking it should really be: > > top_dir = Pathname.new(RbConfig::TOPDIR).parent > > thoughts? > > enjoy, > > -jeremy From jeremy at hinegardner.org Sat Nov 15 02:10:30 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sat, 15 Nov 2008 00:10:30 -0700 Subject: [Rubygems-developers] --destdir changed behavior again ? In-Reply-To: <200811142013.14446.avatar@spellboundnet.com> References: <20081114235542.GL31071@hinegardner.org> <200811142013.14446.avatar@spellboundnet.com> Message-ID: <20081115071030.GM31071@hinegardner.org> On Fri, Nov 14, 2008 at 08:13:13PM -0500, Donavan Pantke wrote: > On Friday 14 November 2008 18:55:42 Jeremy Hinegardner wrote: > > Hi all, > > > > I was packaging up rubygems 1.3.1 fo use at my work and it appears that the > > setup.rb behavior has changed since 1.2.0. > > What distro are you packaging for? I just went through some RPM packaging work > with 1.3.1 and so i might already have something you can use. > I'm already done with the packaging, its for our internal CentOS servers, I was just surprised when I had to change the setup.rb parameters from 1.2.0 to 1.3.1. I've worked around it, I just didn't know if it was an intentional change or not. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From luislavena at gmail.com Sat Nov 15 06:36:09 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 15 Nov 2008 08:36:09 -0300 Subject: [Rubygems-developers] --destdir changed behavior again ? In-Reply-To: <20081114235542.GL31071@hinegardner.org> References: <20081114235542.GL31071@hinegardner.org> Message-ID: <71166b3b0811150336m51a974bfyb6fa3c88ef992f19@mail.gmail.com> On Fri, Nov 14, 2008 at 8:55 PM, Jeremy Hinegardner wrote: > Hi all, > > I was packaging up rubygems 1.3.1 fo use at my work and it appears that the > setup.rb behavior has changed since 1.2.0. > > in 1.2.0: > > ./setup.rb --destdir=/fakeroot/location > > Items get installed into: > > /fakeroot/location/usr/bin > /fakeroot/location/usr/lib > > in 1.3.1 ( and 1.3.0 ) > > ./setup.rb --destdir=/fakeroot/location > > Items get installed into: > > /fakeroot/location/bin > /fakeroot/location/lib > > Is the purpose now, if you want to use destdir, that you are required to > also use --prefix? I don't know about others, but for me, --destdir > means setting where '/' is supposed to be, and then rubygems should > install relative to that as normal. > > The bug for me is all in : > > unless install_destdir.empty? > top_dir = Pathname.new(RbConfig::TOPDIR) > lib_dir_p = Pathname.new(lib_dir) > bin_dir_p = Pathname.new(bin_dir) > > lib_dir = File.join install_destdir, lib_dir_p.relative_path_from(top_dir) > bin_dir = File.join install_destdir, bin_dir_p.relative_path_from(top_dir) > end > > I'm thinking it should really be: > > top_dir = Pathname.new(RbConfig::TOPDIR).parent > > thoughts? > The change was introduced due a previous bug and the imposibility to rely on Pathname to resolve Windows paths. Bundlign RubyGems with One-Click Installer generated issues, since by default it tried to perform all the destdir operations, even when you didn't used the parameter. Back in July I introduced the change and asked more about this issue, since was making my life really hard to update since it's introduction. In any case, I was not pleased to break others implementations or process by this, but the feedback I got was somehow late in relation to my patch and the release process of RubyGems, so it became "official" at that time. The references about this topic: Request for comments: http://rubyforge.org/pipermail/rubygems-developers/2008-July/003969.html Replies: http://rubyforge.org/pipermail/rubygems-developers/2008-August/004026.html We use also destdir to package RubyGems separated from Ruby, but it was generating a complex folder structure (and errors due driver letters). Anyhow, properly fix that benefit both of us will be really great. I tried to avoid any platform validations since thos are tend to be forgotten... 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 luislavena at gmail.com Sat Nov 15 10:07:54 2008 From: luislavena at gmail.com (Luis Lavena) Date: Sat, 15 Nov 2008 12:07:54 -0300 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. Message-ID: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> Hello Guys, This issue was raised originally back in 2007: http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html And raised again by Charlie Savage in July 2008: http://rubyforge.org/pipermail/rubygems-developers/2008-July/003978.html I've explored the different alternatives under several environments and the following are my findings: 1) Alteration of PATH to prepend the DLL location. This was one of the proposed alternatives, and I believe is the one implemented in libxml package. This was also mimicked due the lack of this functionality for DataObjects SQLite3 adapter during the Merb 1.0 release. While this has proven to work, activation of several gems that bundle binaries using this technique make this PATH alteration to child processes, thus could end with alteration of the expected environment for those processes. As example, I bundled libmySQL.dll from MySQL 5.0.51a in mysql gem, while system wide I have installed 5.1.29. The gem executed and connected properly to the 5.1 server, but executing of command line application "mysql" (common practice found in several projects) generated segfaults for these applications and failure due worng exported symbols (and missing ones). There is another issue in relation to PATH size limititations. PATH under XP and 2003 can be up to 2048 bytes, under certains circumstances, this PATH get mangled and only 1024 bytes get copied to spawned child process or by the the process altering the PATH too. There is a patch for 2003 and XP: http://support.microsoft.com/kb/906469 In any case, the folder structure used by rubygems and the location where users install ruby will generate, after activation of 3 or 4 gems compromise the PATH integrity. As example, I have 450 bytes used for my PATH, with ruby Installed in C:\Ruby\bin. Adding "c:/rubylib/ruby/1.8/gems/gem_name-version/lib" to the PATH for each gem activated. 2) Usage of SetDllDirectory Another solution proposed was the usage of Win32API in combination with SetDllDirectory to append the path for the dll, altering the LoadLibrary search order to be able to pick the specified dll. SetDllDirectory was introduced in XP SP1 and with Windows 2003, so has no presence previous in Windows 2000 or NT. Moreover, SetDllDirectory can only add ONE path a time, and doesn't allow concatenation like PATH as search. This means you can SetDllDirectory and inmediately after you're required to load the extension that depend on the DLL. You need to repeat those steps for each binary that depends on external DLLs. It seems SetDllDirectory considered multiple paths in their specs, but no implementation can be used for it right now. RubyGems is not designed to produce that kind of modification or awareness of the dependencies, rendering this method useless for our purposes. 3) LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH The last technique involves explicitly loading the DLL dependency at runtime into the process, instead of waiting for the extension to fire the sequence. The usage of LOAD_WITH_ALTERED_SEARCH_PATH option allow explicit call to a DLL without affecting the PATH and without being affected by SetDllLibrary limitations. The only drawback is that these dlls will be loaded into the process at gem activation and not when the extensions get loaded, making your process a big heavier from startup. This similar approach is being used by Google Chrome to locate and load plugins and by other projects with small differences. === Those are the scenarios I've evaluated. I'm CC'ing win32utils list since I believe Park and Daniel can provide some feedback on these findings prior me hacking something for RubyGems. Thanks in advance for any feedback provided to this. 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 jeremy at hinegardner.org Sat Nov 15 18:08:45 2008 From: jeremy at hinegardner.org (Jeremy Hinegardner) Date: Sat, 15 Nov 2008 16:08:45 -0700 Subject: [Rubygems-developers] --destdir changed behavior again ? In-Reply-To: <71166b3b0811150336m51a974bfyb6fa3c88ef992f19@mail.gmail.com> References: <20081114235542.GL31071@hinegardner.org> <71166b3b0811150336m51a974bfyb6fa3c88ef992f19@mail.gmail.com> Message-ID: <20081115230844.GN31071@hinegardner.org> On Sat, Nov 15, 2008 at 08:36:09AM -0300, Luis Lavena wrote: > On Fri, Nov 14, 2008 at 8:55 PM, Jeremy Hinegardner > wrote: > > Hi all, > > > > I was packaging up rubygems 1.3.1 fo use at my work and it appears that the > > setup.rb behavior has changed since 1.2.0. > > > > The change was introduced due a previous bug and the imposibility to > rely on Pathname to resolve Windows paths. > > Bundlign RubyGems with One-Click Installer generated issues, since by > default it tried to perform all the destdir operations, even when you > didn't used the parameter. > > Back in July I introduced the change and asked more about this issue, > since was making my life really hard to update since it's > introduction. Well it looks like i have those threads in my archive, but I failed to give them due consideration, sorry about that. > In any case, I was not pleased to break others implementations or > process by this, but the feedback I got was somehow late in relation > to my patch and the release process of RubyGems, so it became > "official" at that time. No worries, I've managed to work around it for now. > The references about this topic: > > Request for comments: > http://rubyforge.org/pipermail/rubygems-developers/2008-July/003969.html > > Replies: > http://rubyforge.org/pipermail/rubygems-developers/2008-August/004026.html > > We use also destdir to package RubyGems separated from Ruby, but it > was generating a complex folder structure (and errors due driver > letters). > > Anyhow, properly fix that benefit both of us will be really great. I > tried to avoid any platform validations since thos are tend to be > forgotten... I'll submit a patch on rubyforge that may help. enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner jeremy at hinegardner.org From cfis at savagexi.com Sun Nov 16 16:19:17 2008 From: cfis at savagexi.com (Charlie Savage) Date: Sun, 16 Nov 2008 14:19:17 -0700 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> Message-ID: <49208E55.4030906@savagexi.com> > I've explored the different alternatives under several environments > and the following are my findings: > > 1) Alteration of PATH to prepend the DLL location. > 2) Usage of SetDllDirectory > 3) LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH Maybe we do something simple and say that all shared dependencies get put into ruby/lib on windows (or create a new directory, ruby/shared or something). Or we could just do what happens now, put everything in bin. But I think its probably be better to separate them out. One potential drawback with this solution is if 2 gems use the same shared library, but install different versions (although maybe the files would have different names). Charlie -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From luislavena at gmail.com Tue Nov 18 15:52:31 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Nov 2008 18:52:31 -0200 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <49208E55.4030906@savagexi.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <49208E55.4030906@savagexi.com> Message-ID: <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> On Sun, Nov 16, 2008 at 7:19 PM, Charlie Savage wrote: >> I've explored the different alternatives under several environments >> and the following are my findings: >> >> 1) Alteration of PATH to prepend the DLL location. >> 2) Usage of SetDllDirectory >> 3) LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH > > Maybe we do something simple and say that all shared dependencies get put > into ruby/lib on windows (or create a new directory, ruby/shared or > something). Or we could just do what happens now, put everything in bin. > But I think its probably be better to separate them out. We will still face the override of the libraries by old/new versions that came from different gems. > One potential drawback with this solution is if 2 gems use the same shared > library, but install different versions (although maybe the files would have > different names). > Highly unlikely the dll has different version, like ones found on *nix, they always stick to the same name. I'm looking right now how option 3 will affect when allocating two handles and adding the proper hooks to cleanup those at_exit. Eric: with option 3 we open handles at the OS level. do you think we can hook a at_exit function to perform the cleanup (close) of these handles? -- 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 cfis at savagexi.com Tue Nov 18 15:59:01 2008 From: cfis at savagexi.com (Charlie Savage) Date: Tue, 18 Nov 2008 13:59:01 -0700 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <49208E55.4030906@savagexi.com> <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> Message-ID: <49232C95.3010001@savagexi.com> Luis Lavena wrote: > On Sun, Nov 16, 2008 at 7:19 PM, Charlie Savage wrote: >>> I've explored the different alternatives under several environments >>> and the following are my findings: >>> >>> 1) Alteration of PATH to prepend the DLL location. >>> 2) Usage of SetDllDirectory >>> 3) LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH >> Maybe we do something simple and say that all shared dependencies get put >> into ruby/lib on windows (or create a new directory, ruby/shared or >> something). Or we could just do what happens now, put everything in bin. >> But I think its probably be better to separate them out. > > We will still face the override of the libraries by old/new versions > that came from different gems. Yes, but that's true in both cases, isn't it? > Highly unlikely the dll has different version, like ones found on > *nix, they always stick to the same name. Well, take for example libxml-ruby. It uses these dlls: libiconv-2 libxml2-2 zlib1 So the major numbers are in the name.... > I'm looking right now how option 3 will affect when allocating two > handles and adding the proper hooks to cleanup those at_exit. Yes, that would be better. Charlie -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From luislavena at gmail.com Tue Nov 18 17:19:20 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 18 Nov 2008 20:19:20 -0200 Subject: [Rubygems-developers] Give priority to platform for gem update ? Message-ID: <71166b3b0811181419h1a3adf68wa5c3987014856cdb@mail.gmail.com> This has been generating lot of issues for several folks, including the ones using Jruby, not only Windows. Description: An existing version of a gem (1.1.0) was installed on the system. The gem was a platform specific one. The developer releases a new version of his gem (1.2.0), doing the pure ruby one. Users doing "gem update" will have issues when RubyGems tries to install version 1.2.0 and bomb out due: platform lack of support for native gems (jruby) lack of development tool chain (windows). All these issues has been lately showing up in different places, including stack overflow, ruby-talk, merb and datamapper mailing list. Charles Oliver Nutter suggested (dunno if was ruby-talk or here) we should alter the platform preference order and give more weight/priority to local platform than ruby one. For References: http://stackoverflow.com/questions/43778/sqlite3-ruby-gem-failed-to-build-gem-native-extension http://stackoverflow.com/questions/134581/gem-update-on-windows-is-it-broken The idea will be: "gem update" will only install the latest version of gem to the latest one with current-platform. Also, this can be overwritten if specific version is indicated, like the new prerelease functionality. Thoughts? -- 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 dsisnero at gmail.com Wed Nov 19 11:45:56 2008 From: dsisnero at gmail.com (Dominic Sisneros) Date: Wed, 19 Nov 2008 09:45:56 -0700 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> Message-ID: On Sat, Nov 15, 2008 at 8:07 AM, Luis Lavena wrote: > Hello Guys, > > This issue was raised originally back in 2007: > > http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html > > And raised again by Charlie Savage in July 2008: > > http://rubyforge.org/pipermail/rubygems-developers/2008-July/003978.html > > I've explored the different alternatives under several environments > and the following are my findings: I was looking from the links from the site where the compiled windows binaries for the current one-click-installer are located to see if there is any info how they compile and do stuff on windows and found this information from the following site http://homepage1.nifty.com/markey/ruby/win-env/ruby_on_win01_e.html#howtomake-mswin32 : ------------------------------------------ *Aug. 21, 1999 added* >From version 1.4.0 of Ruby, DLL generation got easier. All you have to do is comment out the module list in Setup.nt. (If you uncomment, it generates statically linked binaries.) Now two versions' modules need to find a way to co-exist. You should put - cygwin32 version of extension module DLL's in XXX/i386-cygwin32 - mswin32 Vern of extension modules DLL's in XXX/i386-mswin32 There should be no problem with this setup. Basically, you can find out where the modules should be with following command: ruby -e 'puts $:' With Ruby 1.4.0, cygwin32 version's output should be /usr/local/lib/ruby/1.4/site_ruby/i386-cygwin /usr/local/lib/ruby/1.4/site_ruby /usr/local/lib/ruby/1.4/i386-cygwin /cygdrive/d/lib /usr/local/lib/ruby/1.4 so, just put cygwin32 version of Ruby extension DLL in \usr\local\lib\ruby\1.4\i386-cygwin with mswin32 version, you'll see /usr/local/lib/site_ruby /usr/local/lib/ruby/1.4/i386-mswin32 D:/lib /usr/local/lib/ruby/1.4 so, put modules in \usr\local\lib\ruby\1.4\i386-mswin32 -------------------------------------------- So, we could possibly have one directory c:/ruby/lib/ruby/1.8/i386-mswin32 for mswin32 compiled stuff and a separate directory for mingw-32 compiled stuff if we have a separate name for ruby.exe and rubym for mingw. But, either way, I suggest we put the dll in a i386-mingw subdirectory either off of gems directory or main ruby directory -------------- next part -------------- An HTML attachment was scrubbed... URL: From luislavena at gmail.com Wed Nov 19 11:52:29 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 Nov 2008 14:52:29 -0200 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> Message-ID: <71166b3b0811190852m5a750031h41ef6a4263ec1627@mail.gmail.com> On Wed, Nov 19, 2008 at 2:45 PM, Dominic Sisneros wrote: > > > On Sat, Nov 15, 2008 at 8:07 AM, Luis Lavena wrote: >> >> Hello Guys, >> >> This issue was raised originally back in 2007: >> >> http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html >> >> And raised again by Charlie Savage in July 2008: >> >> http://rubyforge.org/pipermail/rubygems-developers/2008-July/003978.html >> >> I've explored the different alternatives under several environments >> and the following are my findings: > > I was looking from the links from the site where the compiled windows > binaries for the current one-click-installer are located to see if there is > any info how they compile and do stuff on windows and found this information > from the following site > http://homepage1.nifty.com/markey/ruby/win-env/ruby_on_win01_e.html#howtomake-mswin32: Maybe this will be considered thread hijack, but Aslak Hellesoy posted his finding about building gems for Windows without the need of VC6 compiler: http://blog.aslakhellesoy.com/2008/3/30/ruby-usb-gems -- 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 Wed Nov 19 11:48:33 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Wed, 19 Nov 2008 10:48:33 -0600 Subject: [Rubygems-developers] Question on class cache updates In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514DF4@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514DF4@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514EA3@ITOMAE2KM01.AD.QINTRA.COM> Hi, > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Berger, Daniel > Sent: Wednesday, October 29, 2008 3:25 PM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] Question on class cache updates > > Hi, > > I have a quick question on class cache updates. It seems to > be updating the class cache even if I don't specify -u on the > command line. Is that expected behavior? > > RubyGems Environment: > - RUBYGEMS VERSION: 1.3.1 > - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32_80] > - INSTALLATION DIRECTORY: C:/ruby/lib/ruby/gems/1.8 > - RUBY EXECUTABLE: C:/ruby/bin/ruby.exe > - EXECUTABLE DIRECTORY: C:/ruby/bin > - RUBYGEMS PLATFORMS: > - ruby > - x86-mswin32-80 > - GEM PATHS: > - C:/ruby/lib/ruby/gems/1.8 > - C:/Documents and Settings/djberge/.gem/ruby/1.8 > - GEM CONFIGURATION: > - :update_sources => true > - :verbose => true > - :benchmark => false > - :backtrace => false > - :bulk_threshold => 1000 > - REMOTE SOURCES: > - http://gems.rubyforge.org/ > > C:\>gem install foobar > ERROR: could not find gem foobar locally or in a repository > Updating class cache with 1730 classes... > > Seems odd to me, but if that's expected, then I'll just be quiet. > > However, it also seems to do it when I tell it not to: > > C:\>gem install win32-dir --no-update-sources Successfully > installed win32-dir-0.3.2 > 1 gem installed > Installing ri documentation for win32-dir-0.3.2... > Updating class cache with 1730 classes... > Installing RDoc documentation for win32-dir-0.3.2... > > That, or I'm confused about -u, which is a definite possibility. I think RF was having a problem with mailing lists when I originally sent this, so I'd like to bring it up again. Does anyone have any insight on this please? Is this a bug? If so I'll file it. Thanks, 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 dsisnero at gmail.com Wed Nov 19 12:13:34 2008 From: dsisnero at gmail.com (Dominic Sisneros) Date: Wed, 19 Nov 2008 10:13:34 -0700 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <71166b3b0811190852m5a750031h41ef6a4263ec1627@mail.gmail.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <71166b3b0811190852m5a750031h41ef6a4263ec1627@mail.gmail.com> Message-ID: The link was to show that they suggest putting the dll files under c:/ruby/lib/ruby/1.8/i386-mswin32 if compiled with mswin32 and under c:/ruby/lib/ruby/1.8/i386-mingw if compiled with mingw, msys chain. That way, you could use the same pure ruby libraries if you rename ruby mingw version of executables to rubym and irbm and have the specific i386-mingw directory added to the PATH for mingw extensions. On Wed, Nov 19, 2008 at 9:52 AM, Luis Lavena wrote: > On Wed, Nov 19, 2008 at 2:45 PM, Dominic Sisneros > wrote: > > > > > > On Sat, Nov 15, 2008 at 8:07 AM, Luis Lavena > wrote: > >> > >> Hello Guys, > >> > >> This issue was raised originally back in 2007: > >> > >> > http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html > >> > >> And raised again by Charlie Savage in July 2008: > >> > >> > http://rubyforge.org/pipermail/rubygems-developers/2008-July/003978.html > >> > >> I've explored the different alternatives under several environments > >> and the following are my findings: > > > > I was looking from the links from the site where the compiled windows > > binaries for the current one-click-installer are located to see if there > is > > any info how they compile and do stuff on windows and found this > information > > from the following site > > > http://homepage1.nifty.com/markey/ruby/win-env/ruby_on_win01_e.html#howtomake-mswin32 > : > > Maybe this will be considered thread hijack, but Aslak Hellesoy posted > his finding about building gems for Windows without the need of VC6 > compiler: > > http://blog.aslakhellesoy.com/2008/3/30/ruby-usb-gems > > -- > 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 > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luislavena at gmail.com Wed Nov 19 12:23:35 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 19 Nov 2008 15:23:35 -0200 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <71166b3b0811190852m5a750031h41ef6a4263ec1627@mail.gmail.com> Message-ID: <71166b3b0811190923jd5338b8ye4b7452430bc7f67@mail.gmail.com> On Wed, Nov 19, 2008 at 3:13 PM, Dominic Sisneros wrote: > The link was to show that they suggest putting the dll files under > c:/ruby/lib/ruby/1.8/i386-mswin32 if compiled with mswin32 and under > c:/ruby/lib/ruby/1.8/i386-mingw if compiled with mingw, msys chain. That > way, you could use the same pure ruby libraries if you rename ruby mingw > version of executables to rubym and irbm and have the specific i386-mingw > directory added to the PATH for mingw extensions. > That's the way extension installation and site_ruby used to work (this was pre-rubygems world). Under that scenario, when you installed a newer version of a extension it override the previous one, simple as that. With gems, things can co-exist and thus, landing in a shared directory (btw, which already exist) will not be an option with gems that can depend on the same dll name but different versions. Right now you have i386-msvcrt that indicates the dependency on MSVCRT.dll, for both MinGW and VC6. -- 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 swdc17 at gmail.com Tue Nov 25 06:08:16 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 11:08:16 +0000 Subject: [Rubygems-developers] Executing code after installing gem Message-ID: Hi all, I have been looking for a way to execute some Ruby code at the end of installing my gem. I can't seem to find anything that allows me to do this. I want to chmod a file in the gem directory. I don't want to have to tell my users they must do this upon install. I would have it run on requirement of the gem, but chmod'ing the file will most likely require sudo rights as well. Any help appreciated, -Matt From jftucker at gmail.com Tue Nov 25 06:35:59 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 25 Nov 2008 11:35:59 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: Message-ID: <308606C5-306C-483C-84B9-00952D7D4BF3@gmail.com> Use the rakefile ext builder? On 25 Nov 2008, at 11:08, Matt King wrote: > Hi all, > > I have been looking for a way to execute some Ruby code at the end of > installing my gem. I can't seem to find anything that allows me to do > this. > > I want to chmod a file in the gem directory. I don't want to have to > tell my users they must do this upon install. I would have it run on > requirement of the gem, but chmod'ing the file will most likely > require sudo rights as well. > > Any help appreciated, > -Matt > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From swdc17 at gmail.com Tue Nov 25 06:41:44 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 11:41:44 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <308606C5-306C-483C-84B9-00952D7D4BF3@gmail.com> References: <308606C5-306C-483C-84B9-00952D7D4BF3@gmail.com> Message-ID: 2008/11/25 James Tucker : > Use the rakefile ext builder? Tried that. It exited out with 'No builder for extension.' > On 25 Nov 2008, at 11:08, Matt King wrote: > >> Hi all, >> >> I have been looking for a way to execute some Ruby code at the end of >> installing my gem. I can't seem to find anything that allows me to do >> this. >> >> I want to chmod a file in the gem directory. I don't want to have to >> tell my users they must do this upon install. I would have it run on >> requirement of the gem, but chmod'ing the file will most likely >> require sudo rights as well. >> >> Any help appreciated, >> -Matt From jftucker at gmail.com Tue Nov 25 07:18:18 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 25 Nov 2008 12:18:18 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: <308606C5-306C-483C-84B9-00952D7D4BF3@gmail.com> Message-ID: <1DB96D63-42D0-4A4E-A567-14529D32BA90@gmail.com> On 25 Nov 2008, at 11:41, Matt King wrote: > 2008/11/25 James Tucker : >> Use the rakefile ext builder? > > Tried that. It exited out with 'No builder for extension.' I set this up to allow us to build a 3-platform gem for eventmachine, so an example is sitting in our rakefile: This part is a hack to get around the fact that there's no way to supply arguments to the rake builder: http://github.com/eventmachine/eventmachine/tree/master/Rakefile#L42-48 Here you'll need to make sure that the gem manifest includes the Rakefile and that s.extensions reads Rakefile http://github.com/eventmachine/eventmachine/tree/master/Rakefile#L83-91 HTH > >> On 25 Nov 2008, at 11:08, Matt King wrote: >> >>> Hi all, >>> >>> I have been looking for a way to execute some Ruby code at the end >>> of >>> installing my gem. I can't seem to find anything that allows me to >>> do >>> this. >>> >>> I want to chmod a file in the gem directory. I don't want to have to >>> tell my users they must do this upon install. I would have it run on >>> requirement of the gem, but chmod'ing the file will most likely >>> require sudo rights as well. >>> >>> Any help appreciated, >>> -Matt > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From luislavena at gmail.com Tue Nov 25 07:24:22 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 25 Nov 2008 10:24:22 -0200 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: Message-ID: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> On Tue, Nov 25, 2008 at 9:08 AM, Matt King wrote: > Hi all, > > I have been looking for a way to execute some Ruby code at the end of > installing my gem. I can't seem to find anything that allows me to do > this. > > I want to chmod a file in the gem directory. I don't want to have to > tell my users they must do this upon install. I would have it run on > requirement of the gem, but chmod'ing the file will most likely > require sudo rights as well. > > Any help appreciated, > -Matt Hello Matt, RubyGems is not designed for arbitrary code execution, which will be a security concern. A bad intentioned gem developer will release a gem that can take advantage of this privilege and perform nasty tasks. If you like to have a script marked as executable, why not create a CLI and put into the bin directory to be mapped by rubygems as executable for you? http://rubygems.org/read/chapter/20#default_executable http://rubygems.org/read/chapter/20#executables -- 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 swdc17 at gmail.com Tue Nov 25 07:30:06 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 12:30:06 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <1DB96D63-42D0-4A4E-A567-14529D32BA90@gmail.com> References: <308606C5-306C-483C-84B9-00952D7D4BF3@gmail.com> <1DB96D63-42D0-4A4E-A567-14529D32BA90@gmail.com> Message-ID: 2008/11/25 James Tucker : > > On 25 Nov 2008, at 11:41, Matt King wrote: > >> 2008/11/25 James Tucker : >>> >>> Use the rakefile ext builder? >> >> Tried that. It exited out with 'No builder for extension.' > > I set this up to allow us to build a 3-platform gem for eventmachine, so an > example is sitting in our rakefile: Thanks for the help. I'll try to implement something like this and see what happens... -Matt From swdc17 at gmail.com Tue Nov 25 07:31:58 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 12:31:58 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> Message-ID: 2008/11/25 Luis Lavena : > Matt, > > RubyGems is not designed for arbitrary code execution, which will be a > security concern. > > A bad intentioned gem developer will release a gem that can take > advantage of this privilege and perform nasty tasks. Yes, didn't think of it that way. Makes total sense. > If you like to have a script marked as executable, why not create a > CLI and put into the bin directory to be mapped by rubygems as > executable for you? Well because it's not something a user will execute at the CLI, it's a required executable by the gem itself in order for some functionality to work. Thanks, -Matt From luislavena at gmail.com Tue Nov 25 07:34:51 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 25 Nov 2008 10:34:51 -0200 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> Message-ID: <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> On Tue, Nov 25, 2008 at 10:31 AM, Matt King wrote: > 2008/11/25 Luis Lavena : >> Matt, >> >> RubyGems is not designed for arbitrary code execution, which will be a >> security concern. >> >> A bad intentioned gem developer will release a gem that can take >> advantage of this privilege and perform nasty tasks. > > Yes, didn't think of it that way. Makes total sense. > >> If you like to have a script marked as executable, why not create a >> CLI and put into the bin directory to be mapped by rubygems as >> executable for you? > > Well because it's not something a user will execute at the CLI, it's a > required executable by the gem itself in order for some functionality > to work. By required executable you mean a binary? Or you're calling/shelling out to another ruby script that you bundle? If you provide more information (ala: details) will be much more easy for us to contribute ideas to proper implement this without guessing :-) -- 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 swdc17 at gmail.com Tue Nov 25 07:39:57 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 12:39:57 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> Message-ID: 2008/11/25 Luis Lavena : >> Well because it's not something a user will execute at the CLI, it's a >> required executable by the gem itself in order for some functionality >> to work. > > By required executable you mean a binary? Or you're calling/shelling > out to another ruby script that you bundle? > > If you provide more information (ala: details) will be much more easy > for us to contribute ideas to proper implement this without guessing > :-) Alright, so the gem is a Rails app that gets symlinked from several directories. The app uses background_job (bj), and in the gem there is a jobs/ folder. background_job requires all of these files within this directory to be world executable. And it must live in the jobs/ folder. It never gets executed by a user at the CLI, but when a job is submitted via the Rails app, it spins it off using the corresponding files in this folder. Additionally, although I have it world executable before building the gem, it doesn't seem to stick when I actually build it. Thanks for the help, -Matt From jftucker at gmail.com Tue Nov 25 08:37:22 2008 From: jftucker at gmail.com (James Tucker) Date: Tue, 25 Nov 2008 13:37:22 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> Message-ID: <8034782D-365F-4CAB-A9F3-33287A06E41E@gmail.com> On 25 Nov 2008, at 12:39, Matt King wrote: > 2008/11/25 Luis Lavena : >>> Well because it's not something a user will execute at the CLI, >>> it's a >>> required executable by the gem itself in order for some >>> functionality >>> to work. >> >> By required executable you mean a binary? Or you're calling/shelling >> out to another ruby script that you bundle? >> >> If you provide more information (ala: details) will be much more easy >> for us to contribute ideas to proper implement this without guessing >> :-) > > Alright, so the gem is a Rails app that gets symlinked from several > directories. The app uses background_job (bj), and in the gem there is > a jobs/ folder. background_job requires all of these files within this > directory to be world executable. And it must live in the jobs/ > folder. It never gets executed by a user at the CLI, but when a job is > submitted via the Rails app, it spins it off using the corresponding > files in this folder. > > Additionally, although I have it world executable before building the > gem, it doesn't seem to stick when I actually build it. Right, rubygems doesn't seem to maintain executable bits for files not in the executable list. Don't you need a general install via rake anyway (like rake db:migrate)? In which case surely something like: task :install => %w[db:migrate jobs:chmod] ? > > > Thanks for the help, > -Matt > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From cfis at savagexi.com Tue Nov 25 11:28:36 2008 From: cfis at savagexi.com (Charlie Savage) Date: Tue, 25 Nov 2008 09:28:36 -0700 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> Message-ID: <492C27B4.4030202@savagexi.com> > RubyGems is not designed for arbitrary code execution, which will be a > security concern. Except it already does by letting a developer specify a Rakefile in spec.extensions. That's how I hacked around RubyGems to correctly install dependent dlls into the lib directory. Not to mention the fact that once I have my gem installed, it can pretty much do what it wants. Charlie -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From luislavena at gmail.com Tue Nov 25 11:31:53 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 25 Nov 2008 14:31:53 -0200 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <492C27B4.4030202@savagexi.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <492C27B4.4030202@savagexi.com> Message-ID: <71166b3b0811250831s11d71e57n4990b7d5f75a9c91@mail.gmail.com> On Tue, Nov 25, 2008 at 2:28 PM, Charlie Savage wrote: >> RubyGems is not designed for arbitrary code execution, which will be a >> security concern. > > Except it already does by letting a developer specify a Rakefile in > spec.extensions. That's how I hacked around RubyGems to correctly install > dependent dlls into the lib directory. Point taken, but is a flaw, not intentional by design. Talking in a sudoer powered environment, moving dlls do not apply, which was the case Matt asked. > Not to mention the fact that once I have my gem installed, it can pretty > much do what it wants. Yep, RubyGems opens the pandora box, having the power doesn't mean we should abuse of it, so in the future when it gets fixed we don't rant about loosing that cool feature ;-) -- 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 Nov 25 11:34:00 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Tue, 25 Nov 2008 10:34:00 -0600 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <492C27B4.4030202@savagexi.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <492C27B4.4030202@savagexi.com> Message-ID: <7524A45A1A5B264FA4809E2156496CFB04514ECB@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Charlie Savage > Sent: Tuesday, November 25, 2008 9:29 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] Executing code after installing gem > > > RubyGems is not designed for arbitrary code execution, > which will be a > > security concern. > > Except it already does by letting a developer specify a > Rakefile in spec.extensions. That's how I hacked around > RubyGems to correctly install dependent dlls into the lib directory. > > Not to mention the fact that once I have my gem installed, it > can pretty much do what it wants. Interesting. Maybe we should provide a builtin hook for a post installation task on the condition that the gem is signed? Just a thought. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From jim.weirich at gmail.com Tue Nov 25 11:37:46 2008 From: jim.weirich at gmail.com (Jim Weirich) Date: Tue, 25 Nov 2008 11:37:46 -0500 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <492C27B4.4030202@savagexi.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <492C27B4.4030202@savagexi.com> Message-ID: On Nov 25, 2008, at 11:28 AM, Charlie Savage wrote: > Except it already does by letting a developer specify a Rakefile in > spec.extensions. That's how I hacked around RubyGems to correctly > install dependent dlls into the lib directory. > > Not to mention the fact that once I have my gem installed, it can > pretty much do what it wants. Once it is installed, it will run as a regular user, not as root. Ideally you want to be able to build as a normal user and only switch to root for the "copy files" portion of the install. Is there a system independent way of doing that? -- -- Jim Weirich -- jim.weirich at gmail.com From luislavena at gmail.com Tue Nov 25 11:43:46 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 25 Nov 2008 14:43:46 -0200 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514ECB@ITOMAE2KM01.AD.QINTRA.COM> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <492C27B4.4030202@savagexi.com> <7524A45A1A5B264FA4809E2156496CFB04514ECB@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <71166b3b0811250843g4d92bfd0vc68a014b91cc6d5a@mail.gmail.com> On Tue, Nov 25, 2008 at 2:34 PM, Berger, Daniel wrote: >> -----Original Message----- >> From: rubygems-developers-bounces at rubyforge.org >> [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf >> Of Charlie Savage >> Sent: Tuesday, November 25, 2008 9:29 AM >> To: rubygems-developers at rubyforge.org >> Subject: Re: [Rubygems-developers] Executing code after installing gem >> >> > RubyGems is not designed for arbitrary code execution, >> which will be a >> > security concern. >> >> Except it already does by letting a developer specify a >> Rakefile in spec.extensions. That's how I hacked around >> RubyGems to correctly install dependent dlls into the lib directory. >> >> Not to mention the fact that once I have my gem installed, it >> can pretty much do what it wants. > > Interesting. > > Maybe we should provide a builtin hook for a post installation task on > the condition that the gem is signed? > > Just a thought. > This was discussed previously in the list back in 2006/2007 and no positive value was gained at that time. Will be very helpful to lot of gems, but at the same time package maintainers from debian / ubuntu could object about it (which they already do). The thing is that due the given sudo power during gem installation, the build process runs as sudo, not as normal user, so the extconf.rb has all the power to do nasty things. I'm personally not fond to allow more than what we already do as side effect. -- 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 Tue Nov 25 11:45:42 2008 From: luislavena at gmail.com (Luis Lavena) Date: Tue, 25 Nov 2008 14:45:42 -0200 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <492C27B4.4030202@savagexi.com> Message-ID: <71166b3b0811250845m40874361l9a071eb86a5ae8d8@mail.gmail.com> On Tue, Nov 25, 2008 at 2:37 PM, Jim Weirich wrote: > > On Nov 25, 2008, at 11:28 AM, Charlie Savage wrote: > >> Except it already does by letting a developer specify a Rakefile in >> spec.extensions. That's how I hacked around RubyGems to correctly install >> dependent dlls into the lib directory. >> >> Not to mention the fact that once I have my gem installed, it can pretty >> much do what it wants. > > Once it is installed, it will run as a regular user, not as root. > > Ideally you want to be able to build as a normal user and only switch to > root for the "copy files" portion of the install. Is there a system > independent way of doing that? > This has been in the Feature request queue of RubyGems for quite some time: http://rubyforge.org/tracker/index.php?func=detail&aid=8820&group_id=126&atid=578 On the portability note, you can drop root privileges on *nix, but is not portable without conditions. -- 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 swdc17 at gmail.com Tue Nov 25 12:57:35 2008 From: swdc17 at gmail.com (Matt King) Date: Tue, 25 Nov 2008 17:57:35 +0000 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <8034782D-365F-4CAB-A9F3-33287A06E41E@gmail.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> <8034782D-365F-4CAB-A9F3-33287A06E41E@gmail.com> Message-ID: 2008/11/25 James Tucker : > Right, rubygems doesn't seem to maintain executable bits for files not in > the executable list. > > Don't you need a general install via rake anyway (like rake db:migrate)? > > In which case surely something like: > > task :install => %w[db:migrate jobs:chmod] > > ? James, that is a great idea. I'm going to see if I can pull that one off. Cheers, -Matt From drbrain at segment7.net Tue Nov 25 22:12:25 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 25 Nov 2008 19:12:25 -0800 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: <8034782D-365F-4CAB-A9F3-33287A06E41E@gmail.com> References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> <8034782D-365F-4CAB-A9F3-33287A06E41E@gmail.com> Message-ID: <5F4BAA6D-7B3D-4AA1-ADA5-3C7CB83A814D@segment7.net> On Nov 25, 2008, at 05:37 AM, James Tucker wrote: > On 25 Nov 2008, at 12:39, Matt King wrote: >> >> Additionally, although I have it world executable before building the >> gem, it doesn't seem to stick when I actually build it. > > Right, rubygems doesn't seem to maintain executable bits for files > not in the executable list. It should, at least since RubyGems 1.3.0. From drbrain at segment7.net Tue Nov 25 22:17:34 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 25 Nov 2008 19:17:34 -0800 Subject: [Rubygems-developers] Executing code after installing gem In-Reply-To: References: <71166b3b0811250424y25075c11o1c453990da0c36a3@mail.gmail.com> <71166b3b0811250434i98ecb23g347d3c3ad6080d6d@mail.gmail.com> Message-ID: On Nov 25, 2008, at 04:39 AM, Matt King wrote: > 2008/11/25 Luis Lavena : >>> Well because it's not something a user will execute at the CLI, >>> it's a >>> required executable by the gem itself in order for some >>> functionality >>> to work. >> >> By required executable you mean a binary? Or you're calling/shelling >> out to another ruby script that you bundle? >> >> If you provide more information (ala: details) will be much more easy >> for us to contribute ideas to proper implement this without guessing >> :-) > > Alright, so the gem is a Rails app that gets symlinked from several > directories. The app uses background_job (bj), and in the gem there is > a jobs/ folder. background_job requires all of these files within this > directory to be world executable. And it must live in the jobs/ > folder. It never gets executed by a user at the CLI, but when a job is > submitted via the Rails app, it spins it off using the corresponding > files in this folder. That's a shame, if they are all ruby scripts there's no need to chmod them, bj could execute them directly via system like: system "#{Gem.ruby} path/to/my/script" From drbrain at segment7.net Tue Nov 25 22:19:22 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 25 Nov 2008 19:19:22 -0800 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <49208E55.4030906@savagexi.com> <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> Message-ID: <7D05BC8D-172D-4BA2-B034-1FF471044800@segment7.net> On Nov 18, 2008, at 12:52 PM, Luis Lavena wrote: > I'm looking right now how option 3 will affect when allocating two > handles and adding the proper hooks to cleanup those at_exit. > > Eric: with option 3 we open handles at the OS level. do you think we > can hook a at_exit function to perform the cleanup (close) of these > handles? I think that's fine. How does it behave with fork? From drbrain at segment7.net Tue Nov 25 22:26:22 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 25 Nov 2008 19:26:22 -0800 Subject: [Rubygems-developers] Question on class cache updates In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB04514DF4@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB04514DF4@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <366F9183-1F0F-45F8-BD74-7D8CFD08AB53@segment7.net> On Oct 29, 2008, at 14:24 PM, Berger, Daniel wrote: > I have a quick question on class cache updates. It seems to be > updating > the class cache even if I don't specify -u on the command line. Is > that > expected behavior? This is the ri class cache. > C:\>gem install foobar > ERROR: could not find gem foobar locally or in a repository > Updating class cache with 1730 classes... > > Seems odd to me, but if that's expected, then I'll just be quiet. This is a bug, the doc manager shouldn't do anything. Fixed. > However, it also seems to do it when I tell it not to: > > C:\>gem install win32-dir --no-update-sources > Successfully installed win32-dir-0.3.2 > 1 gem installed > Installing ri documentation for win32-dir-0.3.2... > Updating class cache with 1730 classes... > Installing RDoc documentation for win32-dir-0.3.2... > > That, or I'm confused about -u, which is a definite possibility. If you specify --no-ri you should not get this message. (The code reads that way.) I've updated RDoc to say "Updating ri class cache with [N] classes..." From djberg96 at gmail.com Tue Nov 25 23:05:27 2008 From: djberg96 at gmail.com (Daniel Berger) Date: Tue, 25 Nov 2008 21:05:27 -0700 Subject: [Rubygems-developers] Question on class cache updates In-Reply-To: <366F9183-1F0F-45F8-BD74-7D8CFD08AB53@segment7.net> References: <7524A45A1A5B264FA4809E2156496CFB04514DF4@ITOMAE2KM01.AD.QINTRA.COM> <366F9183-1F0F-45F8-BD74-7D8CFD08AB53@segment7.net> Message-ID: <492CCB07.7010302@gmail.com> Eric Hodel wrote: > On Oct 29, 2008, at 14:24 PM, Berger, Daniel wrote: >> I have a quick question on class cache updates. It seems to be updating >> the class cache even if I don't specify -u on the command line. Is that >> expected behavior? > > This is the ri class cache. > >> C:\>gem install foobar >> ERROR: could not find gem foobar locally or in a repository >> Updating class cache with 1730 classes... >> >> Seems odd to me, but if that's expected, then I'll just be quiet. > > This is a bug, the doc manager shouldn't do anything. Fixed. > >> However, it also seems to do it when I tell it not to: >> >> C:\>gem install win32-dir --no-update-sources >> Successfully installed win32-dir-0.3.2 >> 1 gem installed >> Installing ri documentation for win32-dir-0.3.2... >> Updating class cache with 1730 classes... >> Installing RDoc documentation for win32-dir-0.3.2... >> >> That, or I'm confused about -u, which is a definite possibility. > > If you specify --no-ri you should not get this message. (The code reads > that way.) > > I've updated RDoc to say "Updating ri class cache with [N] classes..." Many thanks Eric. Regards, Dan From luislavena at gmail.com Wed Nov 26 06:15:58 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 26 Nov 2008 09:15:58 -0200 Subject: [Rubygems-developers] Binaries dependencies (shared_libraries) for Windows. In-Reply-To: <7D05BC8D-172D-4BA2-B034-1FF471044800@segment7.net> References: <71166b3b0811150707y371c4bc7rf5a35877b35802ea@mail.gmail.com> <49208E55.4030906@savagexi.com> <71166b3b0811181252ld67822o9cacf64df0485a91@mail.gmail.com> <7D05BC8D-172D-4BA2-B034-1FF471044800@segment7.net> Message-ID: <71166b3b0811260315n228a16e0wa96fbe88c61207e@mail.gmail.com> On Wed, Nov 26, 2008 at 1:19 AM, Eric Hodel wrote: > On Nov 18, 2008, at 12:52 PM, Luis Lavena wrote: >> >> I'm looking right now how option 3 will affect when allocating two >> handles and adding the proper hooks to cleanup those at_exit. >> >> Eric: with option 3 we open handles at the OS level. do you think we >> can hook a at_exit function to perform the cleanup (close) of these >> handles? > > I think that's fine. How does it behave with fork? There is no fork on Windows to worry about, but need to test that out first. Didn't find the time for it yet, so will do this weekend. -- 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 rubygems at freeze.org Thu Nov 27 11:15:35 2008 From: rubygems at freeze.org (Jim Freeze) Date: Thu, 27 Nov 2008 10:15:35 -0600 Subject: [Rubygems-developers] Gems on Github and Dependencies Message-ID: <5cd596d60811270815j5f9e9cc6t9b74da4624746cf1@mail.gmail.com> Hello If we post gems on github, where does rubygems look for dependencies? Is it possible to have dependencies on github or will rubygems always look for dependencies on rubyforge, or at all? Thanks -- Jim Freeze From josh at hasmanythrough.com Fri Nov 28 10:02:05 2008 From: josh at hasmanythrough.com (Josh Susser) Date: Fri, 28 Nov 2008 10:02:05 -0500 Subject: [Rubygems-developers] Gems on Github and Dependencies In-Reply-To: <5cd596d60811270815j5f9e9cc6t9b74da4624746cf1@mail.gmail.com> References: <5cd596d60811270815j5f9e9cc6t9b74da4624746cf1@mail.gmail.com> Message-ID: <2CB8E884-855D-460D-A0E1-F7F878339AF9@hasmanythrough.com> You can tell rubygems where to look for gems by adding a source. ~> gem source -l *** CURRENT SOURCES *** http://gems.rubyforge.org ~> gem source -a http://gems.github.com http://gems.github.com added to sources ~> gem source -l *** CURRENT SOURCES *** http://gems.rubyforge.org http://gems.github.com You can also use the --source option on the gem install command, but keep in mind --source replaces the list of standard sources, it doesn't add to them. --josh On Nov 27, 2008, at 11:15 AM, Jim Freeze wrote: > Hello > > If we post gems on github, where does rubygems look for dependencies? > Is it possible to have dependencies on github or will rubygems always > look for dependencies on rubyforge, or at all? > > Thanks > > -- > Jim Freeze > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -- Josh Susser http://blog.hasmanythrough.com From rubygems at freeze.org Fri Nov 28 20:31:04 2008 From: rubygems at freeze.org (Jim Freeze) Date: Fri, 28 Nov 2008 19:31:04 -0600 Subject: [Rubygems-developers] Gems on Github and Dependencies In-Reply-To: <2CB8E884-855D-460D-A0E1-F7F878339AF9@hasmanythrough.com> References: <5cd596d60811270815j5f9e9cc6t9b74da4624746cf1@mail.gmail.com> <2CB8E884-855D-460D-A0E1-F7F878339AF9@hasmanythrough.com> Message-ID: <5cd596d60811281731o266a1cfdob9a73afc3cf2c7d@mail.gmail.com> On Fri, Nov 28, 2008 at 9:02 AM, Josh Susser wrote: > You can tell rubygems where to look for gems by adding a source. > > ~> gem source -l > *** CURRENT SOURCES *** > > http://gems.rubyforge.org > ~> gem source -a http://gems.github.com > http://gems.github.com added to sources > ~> gem source -l > *** CURRENT SOURCES *** > > http://gems.rubyforge.org > http://gems.github.com Ok, I wasn't aware of this new feature. So, it appears that I can add a gem to github and if that gem has dependencies on gems at rubyforge, someone could install it with the following: % gem source -a http://gems.github.com % sudo gem install some-githubgem and rubygems will pull from github for some-githubgem and will pull the other dependencies from rubyforge. Is that right? Thanks Josh. -- Jim Freeze