From martin.krauskopf at gmail.com Fri Aug 1 02:36:45 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Fri, 01 Aug 2008 08:36:45 +0200 Subject: [Rubygems-developers] Commit mailing list for easy progress watching Message-ID: Hi, could anybody from RubyGems developers setup mailing list when one could subscribe for watching RubyGems commits. It is possible on rubyforge and is much more convenient then going through 'svn log' and/or 'svn di'. It's described in detail here: http://rubyforge.org/docman/view.php/5/460/faq.html#syncmail (SVN section below) Or it is already set up anywhere else and already possible to watch commits? We already did so for debug-commons and ruby-debug project so I'm 'attaching' few-steps instruction for quick setup without the need to read the above document. Just s/joe/ in sftp login. Would be great to be able to watch the progress easily for outside world and mainly I believe for RubyGems developers as well. Thanks, m. Quick how-to: First you need to set up the commit mailing list, e.g. rubygems-commits at rubyforge.org. It is easily doable through admin interface in rubygems project: 1) be logged in, go to the rubygems's Admin page 2) Mail Admin -> Add Mailing List Then after the mailing list is confirmed by rubyforge admins (usually pretty quickly), all what is needed is to copy-paste the post-commit hook below into your rubyforge hooks directory. Save the attachment e.g. to the ~/tmp directory and do something like: $ cd ~/tmp $ sftp joe at rubyforge.org:/var/svn/rubygems/hooks sftp> put post-commit sftp> chmod 775 post-commit That should be all. post-commit #!/bin/sh REPOS="$1" REV="$2" PATH=/usr/bin:/bin:/usr/local/bin PROJECT=/var/svn/rubygems svnnotify --repos-path "$REPOS" --revision "$REV" \ --svnlook /usr/local/bin/svnlook \ --to rubygems-commits at rubyforge.org --from nobody at rubyforge.org \ --with-diff --subject-cx From martin.krauskopf at gmail.com Fri Aug 1 03:19:31 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Fri, 01 Aug 2008 09:19:31 +0200 Subject: [Rubygems-developers] Commit mailing list for easy progress watching In-Reply-To: References: Message-ID: Martin Krauskopf wrote: [...] > Quick how-to: Mailer daemon or something has mangled 'at' containing links in the quick how-to. I can resend it personally with right ones if anybody is interested in setting-up the list. m. From vsizikov at gmail.com Fri Aug 1 04:41:07 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Fri, 1 Aug 2008 10:41:07 +0200 Subject: [Rubygems-developers] Commit mailing list for easy progress watching In-Reply-To: References: Message-ID: <3454c9680808010141q2c640ac5k424f14753da0e54c@mail.gmail.com> Hi Martin, I have a full GIT mirror of rubygems subversion repository here: http://github.com/vvs/rubygems It's being updated hourly, and you could follow up the commits here: http://github.com/vvs/rubygems/commits/master That would include the RSS feed, with links back to the diffs for each commit. Thanks, --Vladimir On Fri, Aug 1, 2008 at 8:36 AM, Martin Krauskopf wrote: > Hi, > > could anybody from RubyGems developers setup mailing list when one could > subscribe for watching RubyGems commits. It is possible on rubyforge and > is much more convenient then going through 'svn log' and/or 'svn di'. > > It's described in detail here: > > http://rubyforge.org/docman/view.php/5/460/faq.html#syncmail > (SVN section below) > > Or it is already set up anywhere else and already possible to watch > commits? We already did so for debug-commons and ruby-debug project so > I'm 'attaching' few-steps instruction for quick setup without the need > to read the above document. > Just s/joe/ in sftp login. > > Would be great to be able to watch the progress easily for outside world > and mainly I believe for RubyGems developers as well. > > Thanks, > > m. > > > Quick how-to: > > First you need to set up the commit mailing list, e.g. > rubygems-commits at rubyforge.org. It is easily doable through admin > interface in rubygems project: > > 1) be logged in, go to the rubygems's Admin page > 2) Mail Admin -> Add Mailing List > > Then after the mailing list is confirmed by rubyforge admins (usually > pretty quickly), all what is needed is to copy-paste the post-commit > hook below into your rubyforge hooks directory. > > Save the attachment e.g. to the ~/tmp directory and do something like: > > $ cd ~/tmp > $ sftp joe at rubyforge.org:/var/svn/rubygems/hooks > sftp> put post-commit > sftp> chmod 775 post-commit > > That should be all. > > post-commit > > #!/bin/sh > REPOS="$1" > REV="$2" > PATH=/usr/bin:/bin:/usr/local/bin > PROJECT=/var/svn/rubygems > > svnnotify --repos-path "$REPOS" --revision "$REV" \ > --svnlook /usr/local/bin/svnlook \ > --to rubygems-commits at rubyforge.org --from nobody at rubyforge.org \ > --with-diff --subject-cx > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From martin.krauskopf at gmail.com Fri Aug 1 04:57:51 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Fri, 01 Aug 2008 10:57:51 +0200 Subject: [Rubygems-developers] Commit mailing list for easy progress watching In-Reply-To: <3454c9680808010141q2c640ac5k424f14753da0e54c@mail.gmail.com> References: <3454c9680808010141q2c640ac5k424f14753da0e54c@mail.gmail.com> Message-ID: Vladimir Sizikov wrote: > Hi Martin, > > I have a full GIT mirror of rubygems subversion repository here: > http://github.com/vvs/rubygems > > It's being updated hourly, and you could follow up the commits here: > http://github.com/vvs/rubygems/commits/master > > That would include the RSS feed, with links back to the diffs for each commit. Thanks a lot Vladimir. That's exactly it. :) m. From drbrain at segment7.net Fri Aug 1 16:20:20 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Aug 2008 13:20:20 -0700 Subject: [Rubygems-developers] LOCAL/REMOTE tokens are not printed for non-tty In-Reply-To: References: Message-ID: <19BA0CBE-9DFB-4C72-A6F2-9BA44280DC43@segment7.net> On Jul 31, 2008, at 14:43 PM, Martin Krauskopf wrote: > Hi all, likely mainly Eric ;), > > what was the reason for the change: > > .../rubyforge.org/rubygems$ svn di -r 1834:1835 > .... > + * lib/rubygems/commands/query_command.rb: Don't print LOCAL/REMOTE > + gems if stdout is not a TTY. > .... > > we use LOCAL and REMOTE lines as 'recognition tokens' when parsing > output of the 'gem list <...>' in the Gem Manager in NetBeans Ruby > IDE. > So with this change our 'parser' is broken. > > Any chance the change will be reverted (e.g. in RubyGems 1.2.1), so > the > output remains backward compatible for cases like this? The goal of the change is to make it easier to hook `gem` up to shell scripts, for example: gem install rdoc gem list | xargs gem rdoc --ri --rdoc Do you run this usually like `gem list -b`? I could add a special case for that. > PS: I know that parsing of the output is poor solution, we are going > to > switch to pure one using RubyGems API in next versions of the Gem > Manager Alternately, if you run `gem list -r` and `gem list -l` separately, you shouldn't need to parse anything. From bjorn.maeland at gmail.com Fri Aug 1 17:00:06 2008 From: bjorn.maeland at gmail.com (=?ISO-8859-1?Q?Bj=F8rn_Arild_M=E6land?=) Date: Fri, 1 Aug 2008 23:00:06 +0200 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command Message-ID: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Hi, I've made a couple of very small patches that deals with the list command. The first patch [1] causes the list command to exit 1 if "gem list " has no results. This should be transparent to most users, but useful for i.e shell scripts. It also saves a couple of cycles since it exits early from the output_query_result method if spec_tuples is empty. The second patch [2] changes the behaviour of the --installed switch. Before, the argument was treated like a pattern, so "gem list -i r" returns true if you have the rails gem installed, but no gem named just "r". My change causes this command to only check for exact matches. The rationale is that since the output is just true/false, one could be fooled into believing that a gem was installed. This is especially true for automated tasks, like shell scripts. Some people _might_ depend on this behaviour (I can't really imagine why, though), thats why I put it in a seperate patch. [1] http://github.com/Chrononaut/rubygems/commit/671cbfafe302b515e026fdc74e491ce0af5a6b16.diff [2] http://github.com/Chrononaut/rubygems/commit/98f817a4515677e42d6172dba0e2db859e94e6b3.diff Regards, Bj?rn Arild M?land -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.krauskopf at gmail.com Fri Aug 1 18:03:43 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Sat, 02 Aug 2008 00:03:43 +0200 Subject: [Rubygems-developers] LOCAL/REMOTE tokens are not printed for non-tty In-Reply-To: <19BA0CBE-9DFB-4C72-A6F2-9BA44280DC43@segment7.net> References: <19BA0CBE-9DFB-4C72-A6F2-9BA44280DC43@segment7.net> Message-ID: Eric Hodel wrote: [...] >> Any chance the change will be reverted (e.g. in RubyGems 1.2.1), so the >> output remains backward compatible for cases like this? > > The goal of the change is to make it easier to hook `gem` up to shell > scripts, for example: > > gem install rdoc > gem list | xargs gem rdoc --ri --rdoc That makes sense, thanks. > Do you run this usually like `gem list -b`? Now, the same 'parser' is used for `gem list {-b,-l,-r}` in the Gem Manager, but..... > I could add a special case for that. ... if you would add this, it will be trivial to tweak our current code. So yes, it would be helpful. It would be probably helpful for CLI usage as well. Since it would be easy to spot where the remote gems starts in the gem listing. >> PS: I know that parsing of the output is poor solution, we are going to >> switch to pure one using RubyGems API in next versions of the Gem >> Manager > > Alternately, if you run `gem list -r` and `gem list -l` separately, you > shouldn't need to parse anything. We are doing so {-l, -r} when only local, or remote, gems need to be read/reloaded, but first time we run with -b. Running two processes is slower with JRuby (not sure about Rubinius). Thus is 'last resort' solution. BTW, shouldn't be trunk switched to 1.2.1 (or 1.3.0). Now if I install latest official stable release 1.2.0 and trunk version, it's hard to recognize what I'm running - particularly we had bug reported against 1.2.0, but the user has trunk version[1]. Thanks, m. [1] http://www.netbeans.org/issues/show_bug.cgi?id=141461 From thewoolleyman at gmail.com Fri Aug 1 20:39:10 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 1 Aug 2008 17:39:10 -0700 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: On Fri, Aug 1, 2008 at 2:00 PM, Bj?rn Arild M?land wrote: > I've made a couple of very small patches that deals with the list command. I haven't looked closely, but I think these are good patches. i've worked around these exact issues in GemInstaller when I interact with the RubyGems API, and these patches would make some of my code go away. They will break me, but I have to look at some other recent changes anyway which broke me (apparently tty, more brittle output-parsing stuff like this). Couple of concerns: * They will likely break other people who use the API, so there should be good warning before they are applied/released - and perhaps a minor version bump in trunk when they are applied, so it is easy to write version specific code to use the patches or not (and thus maintain backward compatibility by still using my previous workarounds). * Not sure about the return code of 1. No results isn't really an error. ALso, it might be useful to distinguish it from other (real?) errors or exit conditions. Are there any? Maybe a different return code than 1? -- Chad From rubygems at freeze.org Fri Aug 1 22:11:11 2008 From: rubygems at freeze.org (Jim Freeze) Date: Fri, 1 Aug 2008 21:11:11 -0500 Subject: [Rubygems-developers] Uninstalling gems from custom gem directory Message-ID: <5cd596d60808011911h65021a2j2b697b00e061e805@mail.gmail.com> Hello In my merb applications, I install gems in the ./gems directory with the '-i' option. How would I remove or update gems in custom install directories? Is it ok to just remove the specific gem, or will that confuse the cache file? Thanks -- Jim Freeze From thewoolleyman at gmail.com Sat Aug 2 16:46:34 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 2 Aug 2008 13:46:34 -0700 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: On Fri, Aug 1, 2008 at 5:39 PM, Chad Woolley wrote: > I haven't looked closely, but I think these are good patches. I tried these, and they don't appear to break my API interaction or the rubygems test suite. They gave some minor problems applying, I don't know if this is the way github makes diffs or what. Anway, they seem good to apply, if Eric thinks so. -- Chad From bjorn.maeland at gmail.com Sat Aug 2 17:08:51 2008 From: bjorn.maeland at gmail.com (=?ISO-8859-1?Q?Bj=F8rn_Arild_M=E6land?=) Date: Sat, 2 Aug 2008 23:08:51 +0200 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: <866e16220808021408y9aa9eeanedcaf88bee81078e@mail.gmail.com> Thanks for your feedback. You're right, the diffs are not correctly formatted for SVN, sorry about that. I've made the output from `svn diff` available here: http://pastie.org/246285 (includes both patches) About the return code, I'm not entirely sure on 1 either. I saw 2 and 4 were used elsewere in the source - I'll leave that decision to someone else. The important thing is that it doesn't return 0, though. - Bj?rn 2008/8/2 Chad Woolley > On Fri, Aug 1, 2008 at 5:39 PM, Chad Woolley > wrote: > > I haven't looked closely, but I think these are good patches. > > I tried these, and they don't appear to break my API interaction or > the rubygems test suite. They gave some minor problems applying, I > don't know if this is the way github makes diffs or what. > > Anway, they seem good to apply, if Eric thinks so. > > -- 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 vsizikov at gmail.com Sat Aug 2 17:30:53 2008 From: vsizikov at gmail.com (Vladimir Sizikov) Date: Sat, 2 Aug 2008 23:30:53 +0200 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: <866e16220808021408y9aa9eeanedcaf88bee81078e@mail.gmail.com> References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> <866e16220808021408y9aa9eeanedcaf88bee81078e@mail.gmail.com> Message-ID: <3454c9680808021430h4d779e06of95824ba55a83a81@mail.gmail.com> Hi, On Sat, Aug 2, 2008 at 11:08 PM, Bj?rn Arild M?land wrote: > Thanks for your feedback. You're right, the diffs are not correctly > formatted for SVN, sorry about that. I've made the output from `svn diff` > available here: http://pastie.org/246285 (includes both patches) I think that: patch -p1 < path-to-patch.diff from the root of the SVN working copy should work, right? Indeed, Subversion and Git use different levels, SVN - 0, GIT - 1. Thanks, --Vladimir From drbrain at segment7.net Sat Aug 2 21:08:15 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sat, 2 Aug 2008 18:08:15 -0700 Subject: [Rubygems-developers] Uninstalling gems from custom gem directory In-Reply-To: <5cd596d60808011911h65021a2j2b697b00e061e805@mail.gmail.com> References: <5cd596d60808011911h65021a2j2b697b00e061e805@mail.gmail.com> Message-ID: <3BD8C314-84FD-48BF-BFA9-1038587D79C0@segment7.net> On Aug 1, 2008, at 19:11 PM, Jim Freeze wrote: > In my merb applications, I install gems in the ./gems directory with > the '-i' option. > How would I remove or update gems in custom install directories? gem uninstall -i ./gems blah From martin.krauskopf at gmail.com Sun Aug 3 05:13:22 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Sun, 03 Aug 2008 11:13:22 +0200 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: Bj?rn Arild M?land wrote: > Hi, > > I've made a couple of very small patches that deals with the list > command. > > The first patch [1] causes the list command to exit 1 if "gem list > " has no results. [...] But the patch does not differ between: $ gem list # on *empty* repository $ echo $? # => 1 but should be 0 in this case and $ gem list abcd_not_exists $ echo $? # => 1 is correct which is how e.g. 'ls' behaves. 'ls' on empty dir has no result and exist with 0. But ls on non-matching pattern returns 1. Thus tweaking condition in QueryCommand#output_query_results like shown in http://pastie.org/246474 (there is probably better way then '/^/i == options[:name]' for check whether user actually specified pattern on CLI). Also 'ls' shows error in the case there is no matching pattern when the pattern is given. Might be such approach would be taken? $ ls abcd_not_exists ls: cannot access abcd_not_exists: No such file or directory m. From drbrain at segment7.net Mon Aug 4 14:07:52 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 4 Aug 2008 11:07:52 -0700 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: On Aug 3, 2008, at 02:13 AM, Martin Krauskopf wrote: > Bj?rn Arild M?land wrote: > > Hi, > > > > I've made a couple of very small patches that deals with the list > > command. > > > > The first patch [1] causes the list command to exit 1 if "gem list > > " has no results. > [...] > > But the patch does not differ between: > > $ gem list # on *empty* repository > $ echo $? # => 1 but should be 0 in this case > > and > > $ gem list abcd_not_exists > $ echo $? # => 1 is correct > > which is how e.g. 'ls' behaves. 'ls' on empty dir has no result and > exist with 0. But ls on non-matching pattern returns 1. > > Thus tweaking condition in QueryCommand#output_query_results like > shown > in http://pastie.org/246474 (there is probably better way then > '/^/i == options[:name]' for check whether user actually specified > pattern on CLI). Bj?rn, can you make this change? I will commit it. > > > Also 'ls' shows error in the case there is no matching pattern when > the > pattern is given. Might be such approach would be taken? > > $ ls abcd_not_exists > ls: cannot access abcd_not_exists: No such file or directory > > m. > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers From drbrain at segment7.net Mon Aug 4 14:08:16 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 4 Aug 2008 11:08:16 -0700 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: <866e16220808021408y9aa9eeanedcaf88bee81078e@mail.gmail.com> References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> <866e16220808021408y9aa9eeanedcaf88bee81078e@mail.gmail.com> Message-ID: <1C1E36BF-02B2-403F-AE64-88810697CE1F@segment7.net> On Aug 2, 2008, at 14:08 PM, Bj?rn Arild M?land wrote: > About the return code, I'm not entirely sure on 1 either. I saw 2 > and 4 were used elsewere in the source - I'll leave that decision to > someone else. The important thing is that it doesn't return 0, though. There's no policy for return codes in RubyGems. From bjorn.maeland at gmail.com Mon Aug 4 17:01:59 2008 From: bjorn.maeland at gmail.com (=?ISO-8859-1?Q?Bj=F8rn_Arild_M=E6land?=) Date: Mon, 4 Aug 2008 23:01:59 +0200 Subject: [Rubygems-developers] [PATCH] Two changes to the gem list command In-Reply-To: References: <866e16220808011400j6b30fdfdp6b69eee269a65930@mail.gmail.com> Message-ID: <866e16220808041401x4310e747p49856428136a9c50@mail.gmail.com> The complete patch, with Martin's input (thanks!) is available here: http://pastie.org/247307 2008/8/4 Eric Hodel > > On Aug 3, 2008, at 02:13 AM, Martin Krauskopf wrote: > > Bj?rn Arild M?land wrote: >> > Hi, >> > >> > I've made a couple of very small patches that deals with the list >> > command. >> > >> > The first patch [1] causes the list command to exit 1 if "gem list >> > " has no results. >> [...] >> >> But the patch does not differ between: >> >> $ gem list # on *empty* repository >> $ echo $? # => 1 but should be 0 in this case >> >> and >> >> $ gem list abcd_not_exists >> $ echo $? # => 1 is correct >> >> which is how e.g. 'ls' behaves. 'ls' on empty dir has no result and >> exist with 0. But ls on non-matching pattern returns 1. >> >> Thus tweaking condition in QueryCommand#output_query_results like shown >> in http://pastie.org/246474 (there is probably better way then >> '/^/i == options[:name]' for check whether user actually specified >> pattern on CLI). >> > > Bj?rn, can you make this change? I will commit it. > > >> >> Also 'ls' shows error in the case there is no matching pattern when the >> pattern is given. Might be such approach would be taken? >> >> $ ls abcd_not_exists >> ls: cannot access abcd_not_exists: No such file or directory >> >> m. >> >> _______________________________________________ >> Rubygems-developers mailing list >> Rubygems-developers at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rubygems-developers >> > > _______________________________________________ > 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 neil at brightbox.co.uk Tue Aug 5 03:41:57 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 5 Aug 2008 08:41:57 +0100 Subject: [Rubygems-developers] Gem binary clash problems. In-Reply-To: <50d9f33a0808042317i16af8289v939b5fe08fc8d3ce@mail.gmail.com> References: <50d9f33a0808042317i16af8289v939b5fe08fc8d3ce@mail.gmail.com> Message-ID: <50d9f33a0808050041v3a9d7e83hbfccd5777984d431@mail.gmail.com> There is a problem with the way that gem installs binaries, in that it doesn't really co-operate with the native package manager or other versions of itself when it installs and uninstalls binaries. This leads to clashes. If the native package manager has installed '/usr/bin/rails' then gem will overwrite it. If you install and uninstall a gem, but don't remove the executable gem will leave a dangling wrapper that fails with: /usr/local/lib/site_ruby/1.8/rubygems.rb:578:in `report_activate_error': Could not find RubyGem brightbox (>= 0) (Gem::LoadError) from /usr/local/lib/site_ruby/1.8/rubygems.rb:134:in `activate' from /usr/local/lib/site_ruby/1.8/rubygems.rb:49:in `gem' from /usr/bin/brightbox:18 This means that shell scripts that just check whether a command exists or not before running them will fail as well. If instead you decide to remove the binary then you run into the opposite problem. gem1.8 install gem1.9 install gem1.8 uninstall -x : command not found And if you don't uninstall a version then you are into the philosophical argument of whether the first 1.8 version or the last 1.9 version of the gem should be the one called by . In Debian/Ubuntu these are solved using the operating system's alternatives system and I've used that in my Rubygems packaging to work around the problems described above. There is a feeling though that Rubygems really ought to be dealing with this problem itself. Clearly it is only going to get worse as users switch between MRI, Rubinius and Jruby. I couldn't see an easy way of getting this inside Rubygems, and neither is it as simple a problem as it first seems (to handle it properly needs a lot of state work - if the inside of the Debian alternatives scripts are anything to go by). I was wondering what others thought about how these clashes should be handled? -- Neil Wilson From neil at brightbox.co.uk Tue Aug 5 04:31:29 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 5 Aug 2008 09:31:29 +0100 Subject: [Rubygems-developers] Ruby1.9 and Edge Gems - gem_prelude error. In-Reply-To: <50d9f33a0808042252s3073ab34ie3047276e1f31daa@mail.gmail.com> References: <50d9f33a0808042252s3073ab34ie3047276e1f31daa@mail.gmail.com> Message-ID: <50d9f33a0808050131y204b973fwe3ab8eb823f1a646@mail.gmail.com> I have the latest committed version of gem installed along with Ruby1.9. I can install gems with gem1.9 however when I try and run a binary (such as 'cap' from Capistrano) I get. gem_prelude.rb:113:in `push_gem_version_on_load_path': undefined method `<=>' for nil:NilClass (NoMethodError) from gem_prelude.rb:8:in `gem' from /usr/local/bin/cap:18:in `
' Is anybody else seeing this? -- Neil Wilson From martin.krauskopf at gmail.com Fri Aug 8 07:15:50 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Fri, 08 Aug 2008 13:15:50 +0200 Subject: [Rubygems-developers] Access to latest_specs.4.8.gz fails Message-ID: Hi, From time to time I'm getting following error: $ gem list -r --backtrace -V *** REMOTE GEMS *** GET 304 Not Modified: http://gems.rubyforge.org/latest_specs.4.8.gz ERROR: While executing gem ... (URI::InvalidURIError) bad URI(is not URI?): Found out this is due to zenspider's patch: $ svn di -r 1806:1807 Index: lib/rubygems/remote_fetcher.rb =================================================================== --- lib/rubygems/remote_fetcher.rb (revision 1806) +++ lib/rubygems/remote_fetcher.rb (revision 1807) @@ -288,6 +288,10 @@ request.add_field 'Connection', 'keep-alive' request.add_field 'Keep-Alive', '30' + if last_modified then + request.add_field 'If-Modified-Since', last_modified.rfc2822 + end + connection = connection_for uri retried = false $ svn log -r 1807 ------------------------------------------------------------------------ r1807 | zenspider | 2008-06-24 06:43:27 +0200 (Tue, 24 Jun 2008) |1 line Damn right... bitch ------------------------------------------------------------------------ When client sets 'If-Modified-Since' header, server might then response with '304 Not Modified'[1] which does not contain 'Location' field in the response header. Thus code in the RemoteFetcher#open_uri_or_path fails since Net::HTTPNotModified is subclass of Net::HTTPRedirection and the code tries to read the 'Location' field (which is `nil'). Seems to me that fix would be to revert the change in rev. 1807 or the code should handle such situation and use previously gotten latest_specs GZip in case of 304? Any ideas? Thanks, m. [1] http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#3xx_Redirection From drbrain at segment7.net Mon Aug 11 22:48:54 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 11 Aug 2008 19:48:54 -0700 Subject: [Rubygems-developers] Access to latest_specs.4.8.gz fails In-Reply-To: References: Message-ID: <06B5B2C6-61CB-473E-9AC2-2EC837ABC466@segment7.net> On Aug 8, 2008, at 04:15 AM, Martin Krauskopf wrote: > From time to time I'm getting following error: > > $ gem list -r --backtrace -V > > *** REMOTE GEMS *** > > GET 304 Not Modified: http://gems.rubyforge.org/latest_specs.4.8.gz > ERROR: While executing gem ... (URI::InvalidURIError) > bad URI(is not URI?): Fixed, try 1847. From drbrain at segment7.net Wed Aug 13 17:57:28 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 13 Aug 2008 14:57:28 -0700 Subject: [Rubygems-developers] Gem binary clash problems. In-Reply-To: <50d9f33a0808050041v3a9d7e83hbfccd5777984d431@mail.gmail.com> References: <50d9f33a0808042317i16af8289v939b5fe08fc8d3ce@mail.gmail.com> <50d9f33a0808050041v3a9d7e83hbfccd5777984d431@mail.gmail.com> Message-ID: <97D80EDB-634F-4919-8C3B-83925F48F089@segment7.net> On Aug 5, 2008, at 00:41 AM, Neil Wilson wrote: > There is a problem with the way that gem installs binaries, in that it > doesn't really co-operate with the native package manager or other > versions of itself when it installs and uninstalls binaries. This > leads to clashes. > > If the native package manager has installed '/usr/bin/rails' then gem > will overwrite it. Yes. Perhaps it should ask. > If you install and uninstall a gem, but don't remove the executable > gem will leave a dangling wrapper that fails with: > > /usr/local/lib/site_ruby/1.8/rubygems.rb:578:in > `report_activate_error': Could not find RubyGem brightbox (>= 0) > (Gem::LoadError) > from /usr/local/lib/site_ruby/1.8/rubygems.rb:134:in `activate' > from /usr/local/lib/site_ruby/1.8/rubygems.rb:49:in `gem' > from /usr/bin/brightbox:18 > > This means that shell scripts that just check whether a command exists > or not before running them will fail as well. I'm not sure what the utility of the option to keep the wrapper is. RubyGems should be smarter here. > If instead you decide to remove the binary then you run into the > opposite problem. > > gem1.8 install > gem1.9 install > gem1.8 uninstall -x > > > : command not found --format-executables is provided for this purpose, but it is a rare need. Most users of RubyGems have only one ruby installed. > And if you don't uninstall a version then you are into the > philosophical argument of whether the first 1.8 version or the last > 1.9 version of the gem should be the one called by . I think it's ok for users to shoot themselves in the foot, but RubyGems would definitely be more friendly if it asked first. > In Debian/Ubuntu these are solved using the operating system's > alternatives system and I've used that in my Rubygems packaging to > work around the problems described above. There is a feeling though > that Rubygems really ought to be dealing with this problem itself. > Clearly it is only going to get worse as users switch between MRI, > Rubinius and Jruby. > > I couldn't see an easy way of getting this inside Rubygems, and > neither is it as simple a problem as it first seems (to handle it > properly needs a lot of state work - if the inside of the Debian > alternatives scripts are anything to go by). > > I was wondering what others thought about how these clashes should > be handled? I think making a few changes to when RubyGems overwrites executables will help a lot, primarily by asking the user about what to do, and advertising about --format-executables at that time. From drbrain at segment7.net Wed Aug 13 18:32:28 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 13 Aug 2008 15:32:28 -0700 Subject: [Rubygems-developers] How to deal with binary dependencies? In-Reply-To: <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com> References: <48824C15.4000804@savagexi.com> <71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com> <4884DC19.9060600@savagexi.com> <71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com> <4884E223.6000107@savagexi.com> <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com> Message-ID: On Jul 21, 2008, at 12:56 PM, Luis Lavena wrote: >> Of course, you might not want that to happen on all platforms, but >> to solve >> that you just provide platform specific gems (which obviously you >> have to >> anyway if the GEM include binary files). For a Windows GEM you'd >> include >> the spec.libraries line, for other platform GEMS you would not. > > I'll love to heard back from Eric and other RubyGems developers > about this. I think I'd prefer 'shared_libraries' as the name of this thing. AFAIK, only windows has the problem being dealt with in this thread, so we can implement whichever solution is best for windows. From drbrain at segment7.net Wed Aug 13 18:33:59 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 13 Aug 2008 15:33:59 -0700 Subject: [Rubygems-developers] Ruby1.9 and Edge Gems - gem_prelude error. In-Reply-To: <50d9f33a0808050131y204b973fwe3ab8eb823f1a646@mail.gmail.com> References: <50d9f33a0808042252s3073ab34ie3047276e1f31daa@mail.gmail.com> <50d9f33a0808050131y204b973fwe3ab8eb823f1a646@mail.gmail.com> Message-ID: On Aug 5, 2008, at 01:31 AM, Neil Wilson wrote: > I have the latest committed version of gem installed along with > Ruby1.9. I can install gems with gem1.9 however when I try and run a > binary (such as 'cap' from Capistrano) I get. > > gem_prelude.rb:113:in `push_gem_version_on_load_path': undefined > method `<=>' for nil:NilClass (NoMethodError) > from gem_prelude.rb:8:in `gem' > from /usr/local/bin/cap:18:in `
' > > Is anybody else seeing this? Yes, I will fix it. From neil at brightbox.co.uk Sat Aug 16 02:40:14 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Sat, 16 Aug 2008 07:40:14 +0100 Subject: [Rubygems-developers] Gem binary clash problems. In-Reply-To: <97D80EDB-634F-4919-8C3B-83925F48F089@segment7.net> References: <50d9f33a0808042317i16af8289v939b5fe08fc8d3ce@mail.gmail.com> <50d9f33a0808050041v3a9d7e83hbfccd5777984d431@mail.gmail.com> <97D80EDB-634F-4919-8C3B-83925F48F089@segment7.net> Message-ID: <50d9f33a0808152340p5bebc32eq44f18267137d44a5@mail.gmail.com> 2008/8/13 Eric Hodel : > --format-executables is provided for this purpose, but it is a rare need. > Most users of RubyGems have only one ruby installed. At the moment perhaps. However once 1.9 goes production ready I expect a lot of people wanting to swap and change around. > I think making a few changes to when RubyGems overwrites executables will > help a lot, primarily by asking the user about what to do, and advertising > about --format-executables at that time. Be careful when asking for input. It makes gems much harder to script. -- Neil Wilson From thewoolleyman at gmail.com Sat Aug 16 13:49:20 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 16 Aug 2008 10:49:20 -0700 Subject: [Rubygems-developers] Gem binary clash problems. In-Reply-To: <50d9f33a0808152340p5bebc32eq44f18267137d44a5@mail.gmail.com> References: <50d9f33a0808042317i16af8289v939b5fe08fc8d3ce@mail.gmail.com> <50d9f33a0808050041v3a9d7e83hbfccd5777984d431@mail.gmail.com> <97D80EDB-634F-4919-8C3B-83925F48F089@segment7.net> <50d9f33a0808152340p5bebc32eq44f18267137d44a5@mail.gmail.com> Message-ID: On Fri, Aug 15, 2008 at 11:40 PM, Neil Wilson wrote: > Be careful when asking for input. It makes gems much harder to script. Yes. Any stdin should be disable-able by passing an appropriate option. And, the option should be supported both on the command line and when using RubyGems programatically via the appropriate API. -- Chad From cfis at savagexi.com Sat Aug 16 16:49:56 2008 From: cfis at savagexi.com (Charlie Savage) Date: Sat, 16 Aug 2008 14:49:56 -0600 Subject: [Rubygems-developers] How to deal with binary dependencies? In-Reply-To: References: <48824C15.4000804@savagexi.com> <71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com> <4884DC19.9060600@savagexi.com> <71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com> <4884E223.6000107@savagexi.com> <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com> Message-ID: <48A73D74.6080900@savagexi.com> > On Jul 21, 2008, at 12:56 PM, Luis Lavena wrote: > >>> Of course, you might not want that to happen on all platforms, but to >>> solve >>> that you just provide platform specific gems (which obviously you >>> have to >>> anyway if the GEM include binary files). For a Windows GEM you'd >>> include >>> the spec.libraries line, for other platform GEMS you would not. >> >> I'll love to heard back from Eric and other RubyGems developers about >> this. > > I think I'd prefer 'shared_libraries' as the name of this thing. AFAIK, > only windows has the problem being dealt with in this thread, so we can > implement whichever solution is best for windows. Well, it could happen on any platform if you don't the library installed. The ifferences are 1) many of these libraries come by default on Linux but not Windows 2) its easier to install them on Linux, particularly if there aren't pre-built binaries by the library maintainers. Anyway, shared_libraries seems like a good name to me. So the idea would be: Add shared_libraries to a specification. If any are set, make sure they end up on the execution path by a) copying them to ruby/bin or b) munging the PATH for the running Ruby program (see previous emails for more discussion about these two approaches). If we want to get this done, should be develop a patch for Gems? Charlie > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers -------------- 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 drbrain at segment7.net Sun Aug 17 03:55:22 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 17 Aug 2008 00:55:22 -0700 Subject: [Rubygems-developers] How to deal with binary dependencies? In-Reply-To: <48A73D74.6080900@savagexi.com> References: <48824C15.4000804@savagexi.com> <71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com> <4884DC19.9060600@savagexi.com> <71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com> <4884E223.6000107@savagexi.com> <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com> <48A73D74.6080900@savagexi.com> Message-ID: On Aug 16, 2008, at 13:49 PM, Charlie Savage wrote: >> On Jul 21, 2008, at 12:56 PM, Luis Lavena wrote: >>>> Of course, you might not want that to happen on all platforms, >>>> but to solve >>>> that you just provide platform specific gems (which obviously you >>>> have to >>>> anyway if the GEM include binary files). For a Windows GEM you'd >>>> include >>>> the spec.libraries line, for other platform GEMS you would not. >>> >>> I'll love to heard back from Eric and other RubyGems developers >>> about this. >> I think I'd prefer 'shared_libraries' as the name of this thing. >> AFAIK, only windows has the problem being dealt with in this >> thread, so we can implement whichever solution is best for windows. > > Well, it could happen on any platform if you don't the library > installed. The ifferences are 1) many of these libraries come by > default on Linux but not Windows 2) its easier to install them on > Linux, particularly if there aren't pre-built binaries by the > library maintainers. Also, adding the library's path to PATH only works on windows. On unix-like platforms, I think you need to set LD_LIBRARY_PATH instead. > Anyway, shared_libraries seems like a good name to me. So the idea > would be: > > Add shared_libraries to a specification. If any are set, make sure > they end up on the execution path by a) copying them to ruby/bin or > b) munging the PATH for the running Ruby program (see previous > emails for more discussion about these two approaches). > > If we want to get this done, should be develop a patch for Gems? Since I don't have a windows environment for ruby, I can't implement this. Can you write the patch? From neil at brightbox.co.uk Sun Aug 17 18:01:25 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Sun, 17 Aug 2008 23:01:25 +0100 Subject: [Rubygems-developers] Hook required for update --system Message-ID: <50d9f33a0808171501v5a63dcf9y9ed1234af4fd3626@mail.gmail.com> As you know I've been working on some new packaging for Ubuntu using the new operating_system.rb facilities. One of the things I want to do is override the 'update --system' facility so that it calls the native package manager rather than trying to do it via gems. An update via gems always goes into the wrong directory, and it would upset the native package manager anyway. I couldn't see an easy way of changing the facility so I had to patch the update command so that it simply execs the correct package manager command. Would it be possible to factor out the default behaviour of adding 'rubygems-update' to the list of gems to update so that it can be overridden in 'operating_system.rb'? -- Neil Wilson From neil at brightbox.co.uk Sun Aug 17 18:08:13 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Sun, 17 Aug 2008 23:08:13 +0100 Subject: [Rubygems-developers] Overriding default directories Message-ID: <50d9f33a0808171508m42eb561cu118ee201880a558d@mail.gmail.com> Using the 'operating_system.rb' I have been unable to find a simple way of changing the default directories by altering a single setting. For ubuntu, gems needs to go in /var/lib/gems/1.8 and the binaries in /var/lib/gems/1.8/bin. With every other setting I keep getting the standard /usr/lib showing up somewhere, either on the gem path or the binary path depending how things are changed. Essentially there doesn't appear to be one place with gems gets the path and the binary path from. The best I've come up with is: # Set the default gem installation directories and paths to the Debian # defaults by poking the correct values into the ENV hash. ENV['GEM_HOME'] = File.join('','var','lib','gems',ConfigMap[:ruby_version]) # I don't want to see 'default_dir' ever. ENV['GEM_PATH'] = user_dir Is there a better way? -- Neil Wilson From drbrain at segment7.net Sun Aug 17 19:08:42 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 17 Aug 2008 16:08:42 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming Message-ID: Please test out RubyGems trunk. The best way to install it and make sure you can still update to 1.3.0 on the official release is: $ svn up $ sudo rake install Current Release notes for 1.3.0: = Announce: RubyGems Release 1.3.0 Release 1.3.0 adds new features and fixes some bugs. New features: * RubyGems doesn't print LOCAL/REMOTE titles for `gem query` and friends if stdout is not a TTY, except with --both. * Added Gem.find_files, allows a gem to discover features provided by other gems. * Added pre/post (un)install hooks for packagers of RubyGems. (Not for gems themselves). * RubyGems now installs into ~/.gem if GEM_HOME is not writable. Use --no-user-install command-line switch to disable this behavior. * Fetching specs for update now uses If-Modified-Since requests. Bugs Fixed: * RubyGems 1.3.0+ now updates when no previous rubygems-update is installed. Bug #20775 by Hemant Kumar. * RubyGems now uses the regexp we already have for `gem list -- installed`. Bug #20876 by Nick Hoffman. * Platform is now forced to Gem::Platform::RUBY when nil or blank in the indexer. Fixes various uninstallable gems. * Handle EINVAL on seek. Based on patch in bug #20791 by Neil Wilson. * Fix HTTPS support. Patch #21072 by Alex Arnell. * RubyGems now loads all cache files even if latest has been loaded. Bug #20776 by Uwe Kubosch. * RubyGems checks for support of development dependencies for #to_ruby. Bug #20778 by Evan Weaver. * Now specifications from the future can be loaded. * Binary script uninstallation fixed. Bug #21234 by Neil Wilson. * Uninstallation with -i fixed. Bug #20812 by John Clayton. * Gem::Uninstaller#remove_all now calls Gem::Uninstaller#uninstall_gem so hooks get called. Bug #21242 by Neil Wilson. Other Changes Include: * Rakefile * If the SETUP_OPTIONS environment variable is set, pass its contents as arguments to setup.rb * lib/rubygems/platform.rb * Remove deprecated constant warnings and really deprecate them. (WIN32, etc). * lib/rubygems/remote_fetcher.rb * Now uses ~/.gem/cache if the cache dir in GEM_HOME is not writable. * lib/rubygems/source_index.rb * Deprecate options to 'search' other than Gem::Dependency instances and issue warning until November 2008. * setup.rb * --destdir folder structure now built using Pathname, so it works for Windows platforms. * test/* * Fixes to run tests when under test/rubygems/. Patch by Yusuke ENDOH [ruby-core:17353]. * test/test_ext_configure_builder.rb * Locale-free patch by Yusuke Endoh [ruby-core:17444]. For a full list of changes to RubyGems and the contributor for each change, see the ChangeLog file. Special thanks to Chad Wooley for backwards compatibility testing and Luis Lavena for continuing windows support. == How can I get RubyGems? NOTE: If you have installed RubyGems using a package system you may want to install a new RubyGems through the same packaging system. If you have a recent version of RubyGems (0.8.5 or later), then all you need to do is: $ gem update --system (you might need to be admin/root) NOTE: RubyGems 1.1 and 1.2 have problems upgrading when there is no rubygems-update installed. You will need to follow the second set of update instructions if you see "Nothing to update". NOTE: You may have to run the command twice if you have any previosly installed rubygems-update gems. If you have an older version of RubyGems installed, then you can still do it in two steps: $ gem install rubygems-update (again, might need to be admin/root) $ update_rubygems (... here too) If you don't have any gems install, there is still the pre-gem approach to getting software ... doing it manually: 1. DOWNLOAD FROM: http://rubyforge.org/frs/?group_id=126 2. UNPACK INTO A DIRECTORY AND CD THERE 3. INSTALL WITH: ruby setup.rb (you may need admin/root privilege) == To File Bugs The RubyGems bug tracker can be found on RubyForge at: http://rubyforge.org/tracker/?func=add&group_id=126&atid=575 When filing a bug, `gem env` output will be helpful in diagnosing the issue. If you find a bug where RubyGems crashes, please provide debug output. You can do that with `gem --debug the_command`. == Thanks Keep those gems coming! -- Jim & Chad & Eric (for the RubyGems team) From thewoolleyman at gmail.com Sun Aug 17 20:49:09 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 17 Aug 2008 17:49:09 -0700 Subject: [Rubygems-developers] RubyGems 1.3.0 Upcoming In-Reply-To: References: Message-ID: On Sun, Aug 17, 2008 at 4:08 PM, Eric Hodel wrote: > Please test out RubyGems trunk. All of the GemInstaller integration/regression tests are passing. Looks good there.. > Current Release notes for 1.3.0: Um, you mean 1.2.0, right? That's what rubygems_version.rb says in trunk, anyway. Wait, I already have that installed! Can you _please_ start bumping the version as soon as you release? In other words, after this release, bump to 1.4.0 in trunk, and bump to 1.4.1 again right before release. Multiple people have asked for this to make their lives easier when integrating against trunk versions of rubygems. It's necessary if you need to put backward-compatibility version-conditional logic when calling the RubyGems API. If you don't, I have to manually edit the version in whenever I integrate or install from trunk. It doesn't hurt anything for the public releases not to end in zero. It's the right thing to do. NOT to do so sets a bad example for other gems. > * RubyGems now installs into ~/.gem if GEM_HOME is not writable. Use > --no-user-install command-line switch to disable this behavior. This sounds awesome, but there doesn't seem to be an easy way to change to this approach if you already have rubygems installed as root (in the standard system location). If I run setup.rb without sudo, it tries to install over the existing install and fails However, there is still no easy "uninstall" method (which has been discussed in a couple of threads over the last couple of years). > Use --no-user-install command-line switch to disable this behavior. Shouldn't these options be exposed on setup.rb as well? If a system admin (or installation automation script) wants to force a non-root user install on a clean system with no ruby gems, you should be able to say 'ruby setup.rb --user-install' I'm assuming that just not running it as sudo would accomplish the same thing, but it seems strange to only be able to do it implicitly, not explicitly. Finally, I'm not sure how to test this fully on my local box. First, running "rake gem" fails because I don't have /.gem/gem-private_key.pem. Even if I had the gem, how would I force gem update --system --user-install to use a non-released local update gem, rather than the latest one on rubyforge? Overall, looks great though. Good work. -- Chad From rbrown at exherbo.org Mon Aug 18 16:21:40 2008 From: rbrown at exherbo.org (Richard Brown) Date: Mon, 18 Aug 2008 21:21:40 +0100 Subject: [Rubygems-developers] r1841 --destdir behaviour Message-ID: Hi, I wrote the initial patch for --destdir support, and I have a couple of issues with r1841, I did email Luis and say I would have a look at the end of last month, but I've been a little tied up, sorry. It uses RbConfig::TOPDIR, which on my x86_64 machine is nil, because of the way mkconfig generates TOPDIR. (It has a hardcoded 'lib' in it, my ruby is installed to 'lib64'. It looks like using RbConfig:CONFIG['prefix'] would be a better choice. This patch has also changed the behaviour of --destdir, and I'm not sure if this is intentional or not. My intent in adding --destdir was to replicate the functionality of make DESTDIR="/image" install So setup.rb --destdir="/foo" would install to "/foo/usr/lib64/ruby/site_ruby/1.8" with this revision it would now be installed to "/foo/lib64/ruby/site_ruby/1.8", which is incorrect. Regards, -- Richard Brown From luislavena at gmail.com Tue Aug 19 18:42:04 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 20 Aug 2008 00:42:04 +0200 Subject: [Rubygems-developers] r1841 --destdir behaviour In-Reply-To: References: Message-ID: <71166b3b0808191542k5c32f0d4sfeef8cc39d426bde@mail.gmail.com> On Mon, Aug 18, 2008 at 10:21 PM, Richard Brown wrote: > Hi, I wrote the initial patch for --destdir support, and I have a > couple of issues with r1841, I did email Luis and say I would have a > look at the end of last month, but I've been a little tied up, sorry. > Glad to have you back :-D > It uses RbConfig::TOPDIR, which on my x86_64 machine is nil, because > of the way mkconfig generates TOPDIR. (It has a hardcoded 'lib' in it, > my ruby is installed to 'lib64'. It looks like using > RbConfig:CONFIG['prefix'] would be a better choice. > Since there was no documentation on the expected results I just came up with something that I was able to understand. For the me idea was that --destdir will generate the same tree hierarchy used by ruby and it's components, but having as parent folder a different one. so: --destdir=/foo/bar will prepend /foo/bar to the /lib/ruby/gems/1.8 and related folder structure... I think was a wrong assumption. > This patch has also changed the behaviour of --destdir, and I'm not > sure if this is intentional or not. My intent in adding --destdir was > to replicate the functionality of > > make DESTDIR="/image" install > > So setup.rb --destdir="/foo" would install to > "/foo/usr/lib64/ruby/site_ruby/1.8" with this revision it would now be > installed to "/foo/lib64/ruby/site_ruby/1.8", which is incorrect. > The thing with that is /usr is not part of the ruby installation structure, but the underliying OS/distro installation structure. /usr has no meaning on Windows (XP, x64): ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mingw32] irb(main):002:0> RbConfig::TOPDIR => "C:/Program Files (x86)/Ruby18" irb(main):003:0> RbConfig::CONFIG['prefix'] => "C:/Program Files (x86)/Ruby18" And this my rbconfig TOPDIR definition: TOPDIR = File.dirname(__FILE__).chomp!("/lib/ruby/1.8/i386-mingw32") == This is my output in Ubuntu: ruby 1.8.6 (2008-03-03 patchlevel 114) [i686-linux] irb(main):002:0> RbConfig::TOPDIR => "/usr" irb(main):003:0> RbConfig::CONFIG['prefix'] => "/usr" Since you're comparing destdir to prefix, when you supply the prefix you need to specify also "usr" part of the path, that is not part of Ruby or guessed somehow, right? Or I'm missing something? > Regards, Regards and thank you for taking a look at this. -- 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 Aug 19 19:09:37 2008 From: luislavena at gmail.com (Luis Lavena) Date: Wed, 20 Aug 2008 01:09:37 +0200 Subject: [Rubygems-developers] RubyGems, building of extensions and paths Message-ID: <71166b3b0808191609y3c2e8a01s676b15806268019a@mail.gmail.com> Hey Guys, This just popped in rake-devel and also Ruby bugs reports in RubyForge: [#21591] gem install hpricot failure 'C:/Program' not recognised on win 64 system http://rubyforge.org/tracker/?group_id=426&atid=1698&func=detail&aid=21591 Basically if you installed Ruby+RubyGems in a folder with spaces (the default for 32bits applications in the 64bits version of XP/Vista), it will generate a problem. I've pinpointed the issue to how Gem.ruby is being used by the ext_conf_builder (line 12) and rake_builder (line 13). Ruby-core workaround this in the FileUtils code in revision 18701: http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/lib/rake.rb?r1=18701&r2=18700&pathrev=18701 Looks like a dirty hack, but it adds the proper quotes around it: irb(main):002:0> Gem.ruby => "C:/Program Files (x86)/Ruby18/bin/ruby.exe" irb(main):003:0> Gem.ruby.sub(/.*\s.*/m, '"\&"') => "\"C:/Program Files (x86)/Ruby18/bin/ruby.exe\"" And on Linux (ubuntu): irb(main):002:0> Gem.ruby => "/usr/bin/ruby" irb(main):003:0> Gem.ruby.sub(/.*\s.*/m, '"\&"') => "/usr/bin/ruby" I just tried the gem install hpricot scenario and overcome that issue, but presented a new one related to make and path with spaces :-D (That is not RubyGems fault, heheh) Comments about this? Maybe I'm missing something on the cleverness of the #sub functionality... Thanks in advance for your time, -- 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 florian.ebeling at gmail.com Wed Aug 20 04:58:19 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Wed, 20 Aug 2008 10:58:19 +0200 Subject: [Rubygems-developers] r1841 --destdir behaviour In-Reply-To: <71166b3b0808191542k5c32f0d4sfeef8cc39d426bde@mail.gmail.com> References: <71166b3b0808191542k5c32f0d4sfeef8cc39d426bde@mail.gmail.com> Message-ID: <5cbbe4ae0808200158g3f86ba14l72c48c1b1f5716b6@mail.gmail.com> On Wed, Aug 20, 2008 at 12:42 AM, Luis Lavena wrote: > On Mon, Aug 18, 2008 at 10:21 PM, Richard Brown wrote: >> Hi, I wrote the initial patch for --destdir support, and I have a >> couple of issues with r1841, I did email Luis and say I would have a >> look at the end of last month, but I've been a little tied up, sorry. >> > > Glad to have you back :-D > >> It uses RbConfig::TOPDIR, which on my x86_64 machine is nil, because >> of the way mkconfig generates TOPDIR. (It has a hardcoded 'lib' in it, >> my ruby is installed to 'lib64'. It looks like using >> RbConfig:CONFIG['prefix'] would be a better choice. >> > > Since there was no documentation on the expected results I just came > up with something that I was able to understand. > For the me idea was that --destdir will generate the same tree > hierarchy used by ruby and it's components, but having as parent > folder a different one. > > so: > > --destdir=/foo/bar > > will prepend /foo/bar to the /lib/ruby/gems/1.8 and related folder structure... > > I think was a wrong assumption. > >> This patch has also changed the behaviour of --destdir, and I'm not >> sure if this is intentional or not. My intent in adding --destdir was >> to replicate the functionality of >> >> make DESTDIR="/image" install >> >> So setup.rb --destdir="/foo" would install to >> "/foo/usr/lib64/ruby/site_ruby/1.8" with this revision it would now be >> installed to "/foo/lib64/ruby/site_ruby/1.8", which is incorrect. >> > > The thing with that is /usr is not part of the ruby installation > structure, but the underliying OS/distro installation structure. /usr > has no meaning on Windows (XP, x64): Then idea of destdir is to "install" to a certain location and then wrap this up as a binary package (or sometimes to a depot location, like in MacPorts). So the path has to contain the full PREFIX. Obviously this does not make a lot of sense on Windows with it's multi-device setup. I don't know what would be the right thing to do in that environment with this option. I guess you don't really need it. A good place to start reading about destdir might be this here: http://www.gnu.org/prep/standards/html_node/DESTDIR.html Florian -- Florian Ebeling florian.ebeling at gmail.com From thewoolleyman at gmail.com Thu Aug 21 03:27:19 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 00:27:19 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall Message-ID: I've been using 1.3.0 off trunk for a few days. There seem to be some bugs, haven't had time to look into them. Let me know if you want tickets opened. First problem: I tried to "force" my gem home and gem path to always be ~/.gem, by editing it in .gemrc. This seemed to have no immediate effect, the system location was still used and reported in gem env. However, after a while (and a reboot I think), this change "took effect", and I suddenly no longer found any gems that were in my system location. This was what I originally wanted, but something must have been cached to prevent it from taking effect immediately. ANyway, I didn't want to reinstall everything, so I commented out gemhome and gempath in .gemrc. I'm not sure what was cached where, or the correct way to clear it. I didn't want to blow away my whole ~/.gem... Second Problem: I cannot uninstall a gem that was installed under ~/.gem. Even though I can see it installed there, both 'gem uninstall' and 'sudo gem uninstall' fail to find and uninstall it. Thanks, -- Chad From thewoolleyman at gmail.com Thu Aug 21 03:35:26 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 00:35:26 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: More info. I can install to ~/.gem as non-root, even without gemhome pointing to ~/.gem/... in .gemrc. However, I can only uninstall from there if I add an entry for gemhome pointing to ~/.gem in .gemrc. From martin.krauskopf at gmail.com Thu Aug 21 12:38:25 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 18:38:25 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Chad Woolley wrote: > More info. I can install to ~/.gem as non-root, even without gemhome > pointing to ~/.gem/... in .gemrc. > > However, I can only uninstall from there if I add an entry for gemhome > pointing to ~/.gem in .gemrc. Might be you forgot '-i' option? $ gem uni -i ~/.gem rake m. From thewoolleyman at gmail.com Thu Aug 21 14:35:20 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 11:35:20 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: On Thu, Aug 21, 2008 at 9:38 AM, Martin Krauskopf wrote: > Might be you forgot '-i' option? > > $ gem uni -i ~/.gem rake No, still can't uninstall it out of ~/.gem even with that option, and rubygems thinks it is not installed, even though it is there: chadmac:workspace woolley$ gem uninstall -i ~/.gem selenium-rails ERROR: While executing gem ... (Gem::InstallError) Unknown gem selenium-rails >= 0 chadmac:workspace woolley$ gem list selenium-rails *** LOCAL GEMS *** chadmac:workspace woolley$ gem uninstall -i ~/.gem selenium-rails ERROR: While executing gem ... (Gem::InstallError) Unknown gem selenium-rails >= 0 chadmac:workspace woolley$ ls ~/.gem/ruby/1.8/gems/selenium-rails-0.0.1 Manifest README.txt lib selenium-rails.gemspec chadmac:workspace woolley$ cat ~/.gemrc --- :sources: - http://gems.rubyforge.org - http://gems.github.com :update_sources: true :bulk_threshold: 1000 :verbose: true :benchmark: false #gemhome: /Users/woolley/.gem/ruby/1.8 #gempath: #- /Users/woolley/.gem/ruby/1.8 :backtrace: false chadmac:workspace woolley$ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.3.0 - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] - INSTALLATION DIRECTORY: /Library/Ruby/Gems/1.8 - RUBY EXECUTABLE: /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby - EXECUTABLE DIRECTORY: /usr/bin - RUBYGEMS PLATFORMS: - ruby - universal-darwin-9 - GEM PATHS: - /Library/Ruby/Gems/1.8 - /Users/woolley/.gem/ruby/1.8 - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org", "http://gems.github.com"] - REMOTE SOURCES: - http://gems.rubyforge.org - http://gems.github.com From martin.krauskopf at gmail.com Thu Aug 21 14:58:30 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 20:58:30 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Chad Woolley wrote: [...] > chadmac:workspace woolley$ gem uninstall -i ~/.gem selenium-rails > ERROR: While executing gem ... (Gem::InstallError) > Unknown gem selenium-rails >= 0 > chadmac:workspace woolley$ ls ~/.gem/ruby/1.8/gems/selenium-rails-0.0.1 This gem is in the ~/.gem/ruby/1.8 repository, not in the ~/.gem repo. $ gem uni -i ~/.gem/ruby/1.8 selenium-rails is the right one. Likely ~/.gem and ~/.gem/ruby/1.8 was somehow interchanged at some time. > chadmac:workspace woolley$ gem env [...] > - GEM PATHS: > - /Library/Ruby/Gems/1.8 > - /Users/woolley/.gem/ruby/1.8 > - /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8 [...] Then just strange, that 'gem list' does not see it. m. From thewoolleyman at gmail.com Thu Aug 21 15:06:38 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 12:06:38 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: On Thu, Aug 21, 2008 at 11:58 AM, Martin Krauskopf wrote: > $ gem uni -i ~/.gem/ruby/1.8 selenium-rails Doesn't work either: chadmac:workspace woolley$ gem uni -i ~/.gem/ruby/1.8 selenium-rails ERROR: While executing gem ... (Gem::InstallError) Unknown gem selenium-rails >= 0 chadmac:workspace woolley$ ls ~/.gem/ruby/1.8/gems/selenium-rails-0.0.1 Manifest README.txt lib selenium-rails.gemspec From martin.krauskopf at gmail.com Thu Aug 21 15:25:21 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 21:25:21 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Chad Woolley wrote: > On Thu, Aug 21, 2008 at 11:58 AM, Martin Krauskopf > wrote: >> $ gem uni -i ~/.gem/ruby/1.8 selenium-rails > > Doesn't work either: Then I do not know. Works for me (below). Just not sure how did you get there 1.3.0, for me trunk has 1.2.0.1861 (in 'gem env' below). Likely wait for somebody from dev (hmm, just revealed that you are there yourself :) ) team or try debug it yourself. $ gem in --no-ri --no-rdoc -i ~/.gem/ruby/1.8/ selenium-rails -v 0.0.1 Successfully installed selenium-rails-0.0.1 1 gem installed $ gem list selenium-rails *** LOCAL GEMS *** selenium-rails (0.0.1) $ gem uni -i ~/.gem/ruby/1.8/ selenium-rails Successfully uninstalled selenium-rails-0.0.1 $ gem env RubyGems Environment: - RUBYGEMS VERSION: 1.2.0.1861 - RUBY VERSION: 1.8.7 (2008-06-20 patchlevel 22) [i686-linux] - INSTALLATION DIRECTORY: /space/ruby/gem-repo - RUBY EXECUTABLE: /space/ruby/ruby-1.8.7-p22/bin/ruby - EXECUTABLE DIRECTORY: /space/ruby/gem-repo/bin - RUBYGEMS PLATFORMS: - ruby - x86-linux - GEM PATHS: - /space/ruby/gem-repo - /home/emdot/.gem/ruby/1.8 - /space/ruby/ruby-1.8.7-p22/lib/ruby/gems/1.8 - GEM CONFIGURATION: - :update_sources => true - :verbose => true - :benchmark => false - :backtrace => false - :bulk_threshold => 1000 - :sources => ["http://gems.rubyforge.org",\ "http://gems.rubyforge.org/yaml"] - REMOTE SOURCES: - http://gems.rubyforge.org m. From thewoolleyman at gmail.com Thu Aug 21 15:35:41 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 12:35:41 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: On Thu, Aug 21, 2008 at 12:25 PM, Martin Krauskopf wrote: > Then I do not know. Works for me (below). Just not sure how did you get > there 1.3.0, for me trunk has 1.2.0.1861 (in 'gem env' below). I manually changed the version to 1.3.0 before installing. How did you get the revision appended? When I install from trunk rev 1861, I end up with version 1.2.0 (no rev appended). Anyway, if it works for you I am probably in some inconsistent state due to mucking with ~/.gemrc. Yeah, I'm on the committers but clueless on this and don't have time to dig into the source. Just reporting it and waiting for Eric to comment... Thanks for the help, -- Chad From martin.krauskopf at gmail.com Thu Aug 21 15:43:20 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 21:43:20 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Chad Woolley wrote: > On Thu, Aug 21, 2008 at 12:25 PM, Martin Krauskopf > wrote: >> Then I do not know. Works for me (below). Just not sure how did you >> get there 1.3.0, for me trunk has 1.2.0.1861 (in 'gem env' below). > > I manually changed the version to 1.3.0 before installing. How did > you get the revision appended? When I install from trunk rev 1861, > I end up with version 1.2.0 (no rev appended). [...] I thought it was changed in trunk recently, but now I see that the difference is in the way of installation: $ cd .../sources/rubygems $ rake package $ cd pkg/rubygems-1.2.0 $ ruby setup.rb $ gem -v # => 1.2.0 but: $ cd .../sources/rubygems $ rake install $ gem -v # => 1.2.0.1861 m. From martin.krauskopf at gmail.com Thu Aug 21 15:49:31 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 21:49:31 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Martin Krauskopf wrote: > Chad Woolley wrote: > > On Thu, Aug 21, 2008 at 12:25 PM, Martin Krauskopf > > wrote: > >> Then I do not know. Works for me (below). Just not sure how did you > >> get there 1.3.0, for me trunk has 1.2.0.1861 (in 'gem env' below). > > > > I manually changed the version to 1.3.0 before installing. How did > > you get the revision appended? When I install from trunk rev 1861, > > I end up with version 1.2.0 (no rev appended). > [...] > > I thought it was changed in trunk recently, but now I see that the > difference is in the way of installation: [...] I've filed: http://rubyforge.org/tracker/index.php?func=detail&aid=21633&group_id=126&atid=575 I've asked here: http://permalink.gmane.org/gmane.comp.lang.ruby.gems.devel/2206 but without response. m. From thewoolleyman at gmail.com Thu Aug 21 15:56:02 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 12:56:02 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: On Thu, Aug 21, 2008 at 12:49 PM, Martin Krauskopf wrote: >> I thought it was changed in trunk recently, but now I see that the >> difference is in the way of installation: > > [...] > > I've filed: > > http://rubyforge.org/tracker/index.php?func=detail&aid=21633&group_id=126&atid=575 > > I've asked here: > > http://permalink.gmane.org/gmane.comp.lang.ruby.gems.devel/2206 > > but without response. AH, that is good to know. However, even 1.2.0.rev is not correct. It should really be 1.3.0.rev (in other words, bumped immediately after release). Otherwise, apps which call the API and need to perform version-specific logic branching still cannot tell the difference between 1.2 and 1.3 when running against trunk. -- Chad From martin.krauskopf at gmail.com Thu Aug 21 16:12:17 2008 From: martin.krauskopf at gmail.com (Martin Krauskopf) Date: Thu, 21 Aug 2008 22:12:17 +0200 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: Chad Woolley wrote: [...] > However, even 1.2.0.rev is not correct. It should really be 1.3.0.rev If next stable release is supposed to be 1.3.0 then trunk can't be 1.3.0.dev. It must be >1.2.0 & <1.3.0. So 1.2.0.rev seems to be more correct then 1.3.0.dev. > (in other words, bumped immediately after release). Otherwise, apps > which call the API and need to perform version-specific logic > branching still cannot tell the difference between 1.2 and 1.3 when > running against trunk. Such apps should not make such assumption, I think. Since trunk might become e.g. 2.0. So they should rather based the logic on the released version vs. the '>latest_stable_release' version, i.e. trunk. So current 1.2.0.rev works well. m. From thewoolleyman at gmail.com Thu Aug 21 16:53:24 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 13:53:24 -0700 Subject: [Rubygems-developers] problems with 1.3.0 non-root autoinstall In-Reply-To: References: Message-ID: On Thu, Aug 21, 2008 at 1:12 PM, Martin Krauskopf wrote: > If next stable release is supposed to be 1.3.0 then trunk can't be > 1.3.0.dev. It must be >1.2.0 & <1.3.0. So 1.2.0.rev seems to be more correct > then 1.3.0.dev. Right, if you insist on making the public releases end in zero. However, I'm proposing that the initial *public* release always be x.x.1, not x.x.0. > Such apps should not make such assumption, I think. Since trunk might become > e.g. 2.0. So they should rather based the logic on the released version vs. > the '>latest_stable_release' version, i.e. trunk. So current 1.2.0.rev works > well. It depends whether the project maintains a bugfix branch for the current release, such as Rails does. In that case, the feature you are depending on may only be in 1.3.0 edge version, but not in the 1.2.1 bugfix version. That means that your check for using the feature needs to be >= 1.3.0, not > 1.2.0. Now, rubygems doesn't usually do emergency bugfix releases. However, if there is ever the situation where the trunk (which is intended to be 1.3.0) is unreleasable, and there needs to be an emergency release (1.2.1) from a branch off the prior release (1.2.0), then having the trunk incremented to the next minor version (1.3.0) would make sense. -- Chad From thewoolleyman at gmail.com Thu Aug 21 18:57:59 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 21 Aug 2008 15:57:59 -0700 Subject: [Rubygems-developers] fyi - rubygems.org down - EOM Message-ID: From chad at chadfowler.com Thu Aug 21 19:03:53 2008 From: chad at chadfowler.com (Chad Fowler) Date: Thu, 21 Aug 2008 17:03:53 -0600 Subject: [Rubygems-developers] fyi - rubygems.org down - EOM In-Reply-To: References: Message-ID: Working on it. Ironically, it's messed up because I upgraded RubyGems :) Thanks! Chad On Thu, Aug 21, 2008 at 4:57 PM, Chad Woolley wrote: > > _______________________________________________ > 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 rbrown at exherbo.org Fri Aug 22 08:01:43 2008 From: rbrown at exherbo.org (Richard Brown) Date: Fri, 22 Aug 2008 13:01:43 +0100 Subject: [Rubygems-developers] r1841 --destdir behaviour In-Reply-To: <71166b3b0808191542k5c32f0d4sfeef8cc39d426bde@mail.gmail.com> References: <71166b3b0808191542k5c32f0d4sfeef8cc39d426bde@mail.gmail.com> Message-ID: On Tue, Aug 19, 2008 at 23:42, Luis Lavena wrote: > On Mon, Aug 18, 2008 at 10:21 PM, Richard Brown wrote: >> Hi, I wrote the initial patch for --destdir support, and I have a >> couple of issues with r1841, I did email Luis and say I would have a >> look at the end of last month, but I've been a little tied up, sorry. >> > > Glad to have you back :-D Thank you. Someone else has already covered destdir for me, in a way that makes more sense that what I had typed. > And this my rbconfig TOPDIR definition: > TOPDIR = File.dirname(__FILE__).chomp!("/lib/ruby/1.8/i386-mingw32") That line is generated from mkconfig.rb when compiling ruby: prefix = '/lib/ruby/' + RUBY_VERSION.sub(/\.\d+$/, '') + '/' + RUBY_PLATFORM print " TOPDIR = File.dirname(__FILE__).chomp!(#{prefix.dump})\n" Until recently ruby's autofoo used to be hardcoded to use lib, it's now possbile to specify a --libdir and install somewhere else, e.g. lib64. Doing that breaks the above bit of code. CONFIG["prefix"] = (TOPDIR || DESTDIR + "/usr") Because TOPDIR= uses chomp! when it doens't work it returns nil, so CONFIG['prefix'] will evaluate to DESTDIR + whatever was passed to configure in --prefix. DESTIDIR in rbconfig will be '' unless it's defined before requring rbconfig. Hope this helps. If you didn't already say, what's the problem with the installation on windows that needs solving? Regards, -- Richard Brown From mgreenly at gmail.com Sat Aug 23 22:22:50 2008 From: mgreenly at gmail.com (michael greenly) Date: Sat, 23 Aug 2008 21:22:50 -0500 Subject: [Rubygems-developers] gem search dies ungracefully Message-ID: Github is returning 503 'service temporarily unavailable' errors and 'gem search foo -r' dies ungacefully on it. *** REMOTE GEMS *** ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) bad response Service Temporarily Unavailable 503 ( http://gems.github.com/latest_specs.4.8) -- Michael Greenly http://blog.michaelgreenly.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thewoolleyman at gmail.com Sun Aug 24 08:39:02 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sun, 24 Aug 2008 05:39:02 -0700 Subject: [Rubygems-developers] mysql 2.7.3 is there but not installable? Message-ID: Bad mirror or cache? chadmac:rails woolley$ gem list mysql -r *** REMOTE GEMS *** mysql (2.7.3, 2.7) mysql_replication_adapter (0.4.0) mysql_retry_lost_connection (0.0.1) chadmac:rails woolley$ gem install mysql --version=2.7.3 ERROR: could not find gem mysql locally or in a repository chadmac:rails woolley$ sudo gem install mysql --version=2.7 Building native extensions. This could take a while... From florian.ebeling at gmail.com Tue Aug 26 06:18:06 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Tue, 26 Aug 2008 12:18:06 +0200 Subject: [Rubygems-developers] GemSpec Reference Message-ID: <5cbbe4ae0808260318w36854037m1b37890fbb539a0c@mail.gmail.com> The GemSpec reference at rubygems.org has a note that is auto-generated, but dates back to 2005. Where is the right place to look for current information on this? Does everybody read the source, or is it still current, even though a bit dated? Florian -- Florian Ebeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Wed Aug 27 07:35:14 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Wed, 27 Aug 2008 13:35:14 +0200 Subject: [Rubygems-developers] Why is spec.autorequire deprecated? Message-ID: <5cbbe4ae0808270435h4589f0c5wdf61db71b13f61ab@mail.gmail.com> I'm just writing a gem spec and I got a warning about Specification#autorequire being deprecated. Maybe I miss an important part, but isn't that the idea, to first require "rubygems" (if ruby 1.8), then the gem, and then be able to access classes etc? How is it meant to work otherwise? Florian -- Florian Ebeling florian.ebeling at gmail.com From halostatue at gmail.com Wed Aug 27 08:11:27 2008 From: halostatue at gmail.com (Austin Ziegler) Date: Wed, 27 Aug 2008 08:11:27 -0400 Subject: [Rubygems-developers] Why is spec.autorequire deprecated? In-Reply-To: <5cbbe4ae0808270435h4589f0c5wdf61db71b13f61ab@mail.gmail.com> References: <5cbbe4ae0808270435h4589f0c5wdf61db71b13f61ab@mail.gmail.com> Message-ID: <9e7db9110808270511h39597deds710c6724ba9c9b00@mail.gmail.com> On Wed, Aug 27, 2008 at 7:35 AM, Caspar Florian Ebeling wrote: > I'm just writing a gem spec and I got a warning about > Specification#autorequire being deprecated. Maybe I > miss an important part, but isn't that the idea, to first > require "rubygems" (if ruby 1.8), then the gem, and then > be able to access classes etc? How is it meant to work > otherwise? #autorequire is a bit dangerous and was probably a mistake from the beginning. What it did was required a file when the gem was activated. It worked like: require 'rubygems' require_gem 'pdf-writer' # this would be gem 'pdf-writer' these days, mostly The only difference these days is: require 'rubygems' require 'pdf/writer' # RubyGems automatically finds and activates the gem -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 florian.ebeling at gmail.com Wed Aug 27 08:12:47 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Wed, 27 Aug 2008 14:12:47 +0200 Subject: [Rubygems-developers] Why is spec.autorequire deprecated? In-Reply-To: <5cbbe4ae0808270435h4589f0c5wdf61db71b13f61ab@mail.gmail.com> References: <5cbbe4ae0808270435h4589f0c5wdf61db71b13f61ab@mail.gmail.com> Message-ID: <5cbbe4ae0808270512h712b6634m10663461698d7025@mail.gmail.com> On Wed, Aug 27, 2008 at 1:35 PM, Caspar Florian Ebeling wrote: > I'm just writing a gem spec and I got a warning about > Specification#autorequire being deprecated. Maybe I > miss an important part, but isn't that the idea, to first > require "rubygems" (if ruby 1.8), then the gem, and then > be able to access classes etc? How is it meant to work > otherwise? Ok, I just figured it out myself. The require means a file by that name, in whichever gem this might turn up. I was holding the wrong assumption that require GEMNAME was what happens, while it is actually only a common convention to supply one file named like the gem itself. Sorry for the noise. Florian -- Florian Ebeling florian.ebeling at gmail.com From florian.ebeling at gmail.com Wed Aug 27 09:05:58 2008 From: florian.ebeling at gmail.com (Caspar Florian Ebeling) Date: Wed, 27 Aug 2008 15:05:58 +0200 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir Message-ID: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> This seems to be a bug: $ mkdir gem_stage/ $ gem install --install-dir gem_stage --local externals-1.0.0.gem Successfully installed externals-1.0.0 1 gem installed Installing ri documentation for externals-1.0.0... Installing RDoc documentation for externals-1.0.0... $ gem uninstall externals --install-dir gem_stage ERROR: While executing gem ... (Gem::InstallError) Unknown gem externals >= 0 Basically, --install-dir seems to be ignored on uninstall. Florian -- Florian Ebeling florian.ebeling at gmail.com From thewoolleyman at gmail.com Wed Aug 27 16:36:05 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 27 Aug 2008 13:36:05 -0700 Subject: [Rubygems-developers] Is this a bug? Uninstall from --install-dir In-Reply-To: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> References: <5cbbe4ae0808270605y388b7404j550b9ca899d69266@mail.gmail.com> Message-ID: On Wed, Aug 27, 2008 at 6:05 AM, Caspar Florian Ebeling wrote: > This seems to be a bug: > > Basically, --install-dir seems to be ignored on uninstall. Yes, I've also seen strangeness with uninstall when things are not in the default locations. I had issues when overriding my gemhome and gempath in .gemrc.