From thewoolleyman at gmail.com  Tue Apr  1 06:06:16 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 1 Apr 2008 03:06:16 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
	<7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
	<e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>
Message-ID: <e3af97510804010306g10dea04areb82a3dbecfb83d@mail.gmail.com>

On Mon, Mar 31, 2008 at 3:29 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Mon, Mar 31, 2008 at 2:43 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  >  Caching bug.
>
>  Ticket: http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575
>

I'm having real issues with the changes made in rev 1673.  It does not
seem that the --all option always has an effect when listing gems,
sometimes you still get only the latest version, even if you pass
--all.   In GemInstaller, I have tests which exercise multi-version
multi-platform installs, and they break with the changes in this
revision.  If I revert this revision, everything works fine again.  An
example failing test is
http://geminstaller.rubyforge.org/svn/trunk/spec/functional/gem_runner_proxy_spec.rb,
"should return output of gem command"

If I add a call to 'reset' in Gem::SourceInfoCache.search, this also
fixes the problem, but I think that also defeats the
performance-improvement purpose of this revision.  I've spent a few
hours trying to figure out how to fix the problem without rolling back
the revision, but had no luck.  Trying to debug this caching code
makes my eyeballs bleed...

-- Chad

From tom at infoether.com  Tue Apr  1 10:04:07 2008
From: tom at infoether.com (Tom Copeland)
Date: Tue, 01 Apr 2008 10:04:07 -0400
Subject: [Rubygems-developers] [patch] indexer typo
Message-ID: <1207058647.25388.83.camel@localhost.localdomain>

$ svn diff lib/rubygems/indexer.rb 
Index: lib/rubygems/indexer.rb
===================================================================
--- lib/rubygems/indexer.rb     (revision 1682)
+++ lib/rubygems/indexer.rb     (working copy)
@@ -85,7 +85,7 @@
                 progress.updated spec.original_name
 
               rescue SignalException => e
-                alert_error "Recieved signal, exiting"
+                alert_error "Received signal, exiting"
                 raise
               rescue Exception => e
                 alert_error "Unable to process #{gemfile}\n#{e.message}
(#{e.class})\n\t#{e.backtrace.join "\n\t"}"

Thanks,

tom


From drbrain at segment7.net  Tue Apr  1 15:01:25 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 1 Apr 2008 12:01:25 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <e3af97510804010306g10dea04areb82a3dbecfb83d@mail.gmail.com>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
	<7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
	<e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>
	<e3af97510804010306g10dea04areb82a3dbecfb83d@mail.gmail.com>
Message-ID: <013D9868-9CF7-4516-A857-A576D1151800@segment7.net>

On Apr 1, 2008, at 03:06 AM, Chad Woolley wrote:
> On Mon, Mar 31, 2008 at 3:29 PM, Chad Woolley  
> <thewoolleyman at gmail.com> wrote:
>> On Mon, Mar 31, 2008 at 2:43 PM, Eric Hodel <drbrain at segment7.net>  
>> wrote:
>>> Caching bug.
>>
>> Ticket: http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575
>>
>
> I'm having real issues with the changes made in rev 1673.  It does not
> seem that the --all option always has an effect when listing gems,
> sometimes you still get only the latest version, even if you pass
> --all.   In GemInstaller, I have tests which exercise multi-version
> multi-platform installs, and they break with the changes in this
> revision.  If I revert this revision, everything works fine again.  An
> example failing test is
> http://geminstaller.rubyforge.org/svn/trunk/spec/functional/gem_runner_proxy_spec.rb 
> ,
> "should return output of gem command"
>
> If I add a call to 'reset' in Gem::SourceInfoCache.search, this also
> fixes the problem, but I think that also defeats the
> performance-improvement purpose of this revision.  I've spent a few
> hours trying to figure out how to fix the problem without rolling back
> the revision, but had no luck.  Trying to debug this caching code
> makes my eyeballs bleed...

Ok.  I've got one last test to run on the apple install problem, then  
I'll make this a top priority.  I already have your IM, so I'll ping  
you after lunch.

From thewoolleyman at gmail.com  Tue Apr  1 15:43:10 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 1 Apr 2008 12:43:10 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <013D9868-9CF7-4516-A857-A576D1151800@segment7.net>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
	<7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
	<e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>
	<e3af97510804010306g10dea04areb82a3dbecfb83d@mail.gmail.com>
	<013D9868-9CF7-4516-A857-A576D1151800@segment7.net>
Message-ID: <e3af97510804011243y5d63d016r4e9b2fc57f3ab8ad@mail.gmail.com>

On Tue, Apr 1, 2008 at 12:01 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  Ok.  I've got one last test to run on the apple install problem, then
>  I'll make this a top priority.  I already have your IM, so I'll ping
>  you after lunch.

Thanks!

From drbrain at segment7.net  Tue Apr  1 20:57:44 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 1 Apr 2008 17:57:44 -0700
Subject: [Rubygems-developers] Incrementing Gem::RubyGemsVersion on
	trunk?
In-Reply-To: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
References: <e3af97510803272202qde6de1bgc19b1234565457df@mail.gmail.com>
Message-ID: <EFB9CB30-DEA8-4A63-B809-B439F49E1986@segment7.net>

On Mar 27, 2008, at 22:02 PM, Chad Woolley wrote:
> For my project, I run CI regression testing against several rubygems
> versions, which are embedded in specs fixtures dir:
> http://ci.thewoolleyweb.com/
>
> This is all dynamically specified through the cc.rb project name and a
> RUBYGEMS_VERSION env var:
> http://geminstaller.rubyforge.org/svn/trunk/cruise_config.rb
>
> I would also like to include a SVN external to automatically test
> against the latest rubygems trunk (which is nice because cc.rb trunk
> now detects svn external checkins).  However, this is difficult since
> the rubygems_version.rb on trunk is hardcoded to the version of the
> latest release, and for my approach to work, the dir name and rubygems
> version must match.
>
> Would you be open to either one of these two options?
>
> 1. 'preemptively' increment Gem::RubyGemsVersion after each release,
> to have a higher "tiny" component.  For example, the trunk now would
> be "1.0.1.1", or "1.0.1.99" or whatever...
>
> or
>
> 2. Allow an environment var to be passed, which if set would append
> the current trunk revision as the tiny component (and if not set,
> would not touch the version).  Something like this (but cleaned
> up/extracted):
>
> RubyGemsVersion = '1.0.1' + (ENV['TRUNK_VERSION'] ? '.' + `svn log -q
> -rhead http://rubygems.rubyforge.org/svn/trunk`.scan(/ 
> r([0-9]*)/).first.first.to_s
> : "")
>
> Yeah, I know I can do this myself by rewriting the rubygems_version.rb
> file in the external before my CI build kicks off, but it would be
> nice to have it built in to RubyGems.

As a compromise of the solutions discussed in this thread, I set up  
`rake install` to overwrite rubygems_version.rb with data from  
`svnversion`.  Right now it doesn't know anything about installing  
RubyGems into other paths, but it could be easily taught to do the  
same as --prefix does.

From thewoolleyman at gmail.com  Wed Apr  2 04:13:25 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 2 Apr 2008 01:13:25 -0700
Subject: [Rubygems-developers] Is a remote list with --all supposed to
	be required to install older gem versions?
In-Reply-To: <013D9868-9CF7-4516-A857-A576D1151800@segment7.net>
References: <e3af97510803311259j179af83ck943d8520958a0e50@mail.gmail.com>
	<7AE38F39-B8FF-40FD-8C38-F1268126D8E5@segment7.net>
	<e3af97510803311529h23d2cb47yded2c49420165db4@mail.gmail.com>
	<e3af97510804010306g10dea04areb82a3dbecfb83d@mail.gmail.com>
	<013D9868-9CF7-4516-A857-A576D1151800@segment7.net>
Message-ID: <e3af97510804020113g2ab5f147ge54499926cf9ce08@mail.gmail.com>

On Tue, Apr 1, 2008 at 12:01 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  Ok.  I've got one last test to run on the apple install problem, then
>  I'll make this a top priority.  I already have your IM, so I'll ping
>  you after lunch.

I added the one-line fix you suggested, which seems to fix all the
problems, but broke a ton of seemingly-unrelated tests, so I couldn't
check in.  Patch (with no test fixes yet) on the ticket:

http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575

From weyus at att.net  Wed Apr  2 18:56:56 2008
From: weyus at att.net (Wes Gamble)
Date: Wed, 02 Apr 2008 17:56:56 -0500
Subject: [Rubygems-developers] Need help manually adding a gem to my local
	repository
Message-ID: <47F40F38.7080005@att.net>

I have a gem already installed, but I had to move it into place by hand 
from another machine because it isn't available on the remote repository 
where it is supposed to be.

Therefore the local gem index is unaware of it.

How can I either have the gem directories rescanned and rebuild the 
local index OR how can I manually edit whichever file(s) represent the 
local gem index to show that the gem is actually there when I do a "gem 
list"?

Thanks,
Wes

From drbrain at segment7.net  Thu Apr  3 19:24:07 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 3 Apr 2008 16:24:07 -0700
Subject: [Rubygems-developers] Need help manually adding a gem to my
	local repository
In-Reply-To: <47F40F38.7080005@att.net>
References: <47F40F38.7080005@att.net>
Message-ID: <823F9039-090C-4FA4-9C5C-13D1C93F41FF@segment7.net>

On Apr 2, 2008, at 15:56 PM, Wes Gamble wrote:
> I have a gem already installed, but I had to move it into place by  
> hand
> from another machine because it isn't available on the remote  
> repository
> where it is supposed to be.

The easy way is to copy the .gem file out of the cache/ directory and  
gem install that.

> Therefore the local gem index is unaware of it.
>
> How can I either have the gem directories rescanned and rebuild the
> local index OR how can I manually edit whichever file(s) represent the
> local gem index to show that the gem is actually there when I do a  
> "gem
> list"?

The local gem index is built from the specifications/ directory.   
Currently there isn't a command-line tool that will output a ruby- 
format gemspec.  You can pull a specification out of a .gem file with  
Gem::Format.

The files for the gem need to go in gems/#{spec.full_name}.

From drbrain at segment7.net  Thu Apr  3 19:35:54 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 3 Apr 2008 16:35:54 -0700
Subject: [Rubygems-developers] [patch] indexer typo
In-Reply-To: <1207058647.25388.83.camel@localhost.localdomain>
References: <1207058647.25388.83.camel@localhost.localdomain>
Message-ID: <9FB250F9-AADD-4705-8076-FAF71C068225@segment7.net>

On Apr 1, 2008, at 07:04 AM, Tom Copeland wrote:
> $ svn diff lib/rubygems/indexer.rb
> Index: lib/rubygems/indexer.rb

Committed.


From jos at catnook.com  Fri Apr  4 00:23:34 2008
From: jos at catnook.com (Jos Backus)
Date: Thu, 3 Apr 2008 21:23:34 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
Message-ID: <20080404042334.GA20210@lizzy.catnook.local>

    Hi,

Puppet (http://reductivelabs.com/trac/puppet) uses the `gem list' command as
part of its gem package provider. I'm thinking about fixing the provider to
use the RubyGems API instead of the command line tool as the command line tool
produces output that isn't strictly related to the local or remote gem list,
and incurs extra output parsing.

E.g for the local gem list case query_command.rb uses
Gem.source_index.search(name) to get a list of local gems. When calling it I
still see output related to updating the gem index. I'd like to avoid this
extra output; is that possible?

Also: the attached patch against 1.1.0 refactors output_query_results into two
methods, one that produces the list of gems with their versions and another
that outputs this list in the same format output_query_results does today.
This makes it easier to programmatically access the list of local and remote
gems.

In case I'm reinventing the wheel, please tell me so.

-- 
Jos Backus
jos at catnook.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: query_command.rb.diff
Type: text/x-diff
Size: 1499 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20080403/693d929b/attachment.bin 

From jos at catnook.com  Fri Apr  4 00:42:36 2008
From: jos at catnook.com (Jos Backus)
Date: Thu, 3 Apr 2008 21:42:36 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <20080404042334.GA20210@lizzy.catnook.local>
References: <20080404042334.GA20210@lizzy.catnook.local>
Message-ID: <20080404044236.GA21238@lizzy.catnook.local>

Slightly smaller patch.

-- 
Jos Backus
jos at catnook.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: query_command.rb.diff
Type: text/x-diff
Size: 1821 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rubygems-developers/attachments/20080403/d9551c16/attachment.bin 

From luislavena at gmail.com  Fri Apr  4 12:08:25 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 4 Apr 2008 13:08:25 -0300
Subject: [Rubygems-developers] Side effects of latest 1.1.0
Message-ID: <71166b3b0804040908w3299ab4dwb740d3a0f8493e31@mail.gmail.com>

Hello Guys,

I'm getting a few hits on some tickets regarding latest release (1.1.0):

win32-service requirement for 0.3.4 no longer in rubyforge gem repository
http://mongrel.rubyforge.org/ticket/27

This is cache related, as Chad Woolley described previously, but which
current solution breaks all the tests, as detailed in ticket #19228:

http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575

This just show up, but is possible other gems faces the same situation
we have here.

==

[#19274] Cannot retrieve gems after updating to 1.1.0 on Windows
http://rubyforge.org/tracker/index.php?func=detail&aid=19274&group_id=126&atid=575

This one is related to Errno::ECONNABORTED not being rescued by the
Remote Fetched, which I found after 1.1.0 release.

I know this was asked too many times by me, but Eric: _we_ do have a
release schedule for RubyGems? Just to give us enough room to test
rubygems in a sandboxed environment at least for 2 days to see if
there are major issues not found by the automated test suite.

Regards,
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Sat Apr  5 22:43:52 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sat, 5 Apr 2008 19:43:52 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <20080404042334.GA20210@lizzy.catnook.local>
References: <20080404042334.GA20210@lizzy.catnook.local>
Message-ID: <546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>

On Apr 3, 2008, at 21:23 PM, Jos Backus wrote:
> Puppet (http://reductivelabs.com/trac/puppet) uses the `gem list'  
> command as
> part of its gem package provider. I'm thinking about fixing the  
> provider to
> use the RubyGems API instead of the command line tool as the command  
> line tool
> produces output that isn't strictly related to the local or remote  
> gem list,
> and incurs extra output parsing.

If you're looking for the list of locally installed gems as strings,  
this is the best way:

Gem.source_index.map { |name, gemspec| name }

Gem::SourceIndex is Enumerable, so you can easily filter results if  
you need based on the gemspec object.

> E.g for the local gem list case query_command.rb uses
> Gem.source_index.search(name) to get a list of local gems. When  
> calling it I
> still see output related to updating the gem index. I'd like to  
> avoid this
> extra output; is that possible?

You shouldn't see anything about updating the index for a `gem list`  
or `gem query`, as those don't attempt to update the index.  (Only if  
the -r flag is given.)

> Also: the attached patch against 1.1.0 refactors  
> output_query_results into two
> methods, one that produces the list of gems with their versions and  
> another
> that outputs this list in the same format output_query_results does  
> today.
> This makes it easier to programmatically access the list of local  
> and remote
> gems.


I'd much rather improve the programmer API over adding extra things to  
Gem::Command subclasses, as those classes are at least one level of  
indirection away from whatever you probably want to do.

I can guide you towards the proper API calls to make if you have a  
specific goal, but I strongly recommend avoiding directly calling  
methods on Gem::Command subclasses.

From jos at catnook.com  Sun Apr  6 03:37:03 2008
From: jos at catnook.com (Jos Backus)
Date: Sun, 6 Apr 2008 00:37:03 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
References: <20080404042334.GA20210@lizzy.catnook.local>
	<546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
Message-ID: <20080406073703.GB19624@lizzy.catnook.local>

On Sat, Apr 05, 2008 at 07:43:52PM -0700, Eric Hodel wrote:
> On Apr 3, 2008, at 21:23 PM, Jos Backus wrote:
[snip]
> If you're looking for the list of locally installed gems as strings,  
> this is the best way:
> 
> Gem.source_index.map { |name, gemspec| name }
> 
> Gem::SourceIndex is Enumerable, so you can easily filter results if  
> you need based on the gemspec object.
 
Thanks Eric, looks like that will cover the local case just fine.

> > E.g for the local gem list case query_command.rb uses
> > Gem.source_index.search(name) to get a list of local gems. When  
> > calling it I
> > still see output related to updating the gem index. I'd like to  
> > avoid this
> > extra output; is that possible?
> 
> You shouldn't see anything about updating the index for a `gem list`  
> or `gem query`, as those don't attempt to update the index.  (Only if  
> the -r flag is given.)
 
Understood. However, I also need the remote case to work for Puppet as it has
the ability to install the `latest' gem, so I need to be able to retrieve the
names and versions of remote gems. Pointers appreciated.

> I'd much rather improve the programmer API over adding extra things to  
> Gem::Command subclasses, as those classes are at least one level of  
> indirection away from whatever you probably want to do.
 
Agreed. I'm still trying to familiarize myself with the code.

> I can guide you towards the proper API calls to make if you have a  
> specific goal, but I strongly recommend avoiding directly calling  
> methods on Gem::Command subclasses.

Okay, I'll refrain from doing that then.

-- 
Jos Backus
jos at catnook.com

From thewoolleyman at gmail.com  Sun Apr  6 14:13:06 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 6 Apr 2008 11:13:06 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <20080406073703.GB19624@lizzy.catnook.local>
References: <20080404042334.GA20210@lizzy.catnook.local>
	<546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
	<20080406073703.GB19624@lizzy.catnook.local>
Message-ID: <e3af97510804061113w50892951ifb2730f47d5bdb91@mail.gmail.com>

On Sun, Apr 6, 2008 at 12:37 AM, Jos Backus <jos at catnook.com> wrote:
>  Understood. However, I also need the remote case to work for Puppet as it has
>  the ability to install the `latest' gem, so I need to be able to retrieve the
>  names and versions of remote gems. Pointers appreciated.

Invoke GemRunner with the appropriate ['--list','--remote','etc...'] options.

For examples, look at GemInstaller:

http://geminstaller.rubyforge.org/svn/trunk/lib/geminstaller/gem_list_checker.rb

...which calls:
http://geminstaller.rubyforge.org/svn/trunk/lib/geminstaller/gem_command_manager.rb
(see GemCommandManager#list_remote_gem)

Could probably be improved, I have to do manual parsing of results.
An option to return a data structure would be better.

-- Chad

From jos at catnook.com  Sun Apr  6 15:29:27 2008
From: jos at catnook.com (Jos Backus)
Date: Sun, 6 Apr 2008 12:29:27 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <e3af97510804061113w50892951ifb2730f47d5bdb91@mail.gmail.com>
References: <20080404042334.GA20210@lizzy.catnook.local>
	<546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
	<20080406073703.GB19624@lizzy.catnook.local>
	<e3af97510804061113w50892951ifb2730f47d5bdb91@mail.gmail.com>
Message-ID: <20080406192927.GA26854@lizzy.catnook.local>

On Sun, Apr 06, 2008 at 11:13:06AM -0700, Chad Woolley wrote:
> Invoke GemRunner with the appropriate ['--list','--remote','etc...'] options.
> 
> For examples, look at GemInstaller:
> 
> http://geminstaller.rubyforge.org/svn/trunk/lib/geminstaller/gem_list_checker.rb
> 
> ...which calls:
> http://geminstaller.rubyforge.org/svn/trunk/lib/geminstaller/gem_command_manager.rb
> (see GemCommandManager#list_remote_gem)
> 
> Could probably be improved, I have to do manual parsing of results.
> An option to return a data structure would be better.
 
Thanks for the links, Chad. I'll be sure to take a look.

The downside is that it would require installing the geminstaller gem for
Puppet to support gems.

If I read the docs right there seems to be at least some overlap between it
and Puppet, as Puppet will (in theory) also manage gems and versions on
machines (depending on how well its gem package provider works, of course.

-- 
Jos Backus
jos at catnook.com

From drbrain at segment7.net  Sun Apr  6 16:59:15 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 6 Apr 2008 13:59:15 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <20080406073703.GB19624@lizzy.catnook.local>
References: <20080404042334.GA20210@lizzy.catnook.local>
	<546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
	<20080406073703.GB19624@lizzy.catnook.local>
Message-ID: <B6D2CBED-DBBE-41D5-8692-8AE024234861@segment7.net>

On Apr 6, 2008, at 00:37 AM, Jos Backus wrote:
> Understood. However, I also need the remote case to work for Puppet  
> as it has
> the ability to install the `latest' gem, so I need to be able to  
> retrieve the
> names and versions of remote gems. Pointers appreciated.

Gem::SourceInfoCache.search and search_with_source is what you want to  
look at.

From thewoolleyman at gmail.com  Sun Apr  6 16:59:13 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 6 Apr 2008 13:59:13 -0700
Subject: [Rubygems-developers] query_command.rb question and patch
In-Reply-To: <20080406192927.GA26854@lizzy.catnook.local>
References: <20080404042334.GA20210@lizzy.catnook.local>
	<546B8A44-26DD-4FE8-A10A-940C8989967D@segment7.net>
	<20080406073703.GB19624@lizzy.catnook.local>
	<e3af97510804061113w50892951ifb2730f47d5bdb91@mail.gmail.com>
	<20080406192927.GA26854@lizzy.catnook.local>
Message-ID: <e3af97510804061359p1e3891bcn868f8d4f981a3653@mail.gmail.com>

On Sun, Apr 6, 2008 at 12:29 PM, Jos Backus <jos at catnook.com> wrote:
>  The downside is that it would require installing the geminstaller gem for
>  Puppet to support gems.

That is true.  I can understand the desire to have no dependencies for
a system-management tool like Puppet.  Geminstaller itself has no
runtime dependencies (other than RubyGems itself).

Then again, the benefit of using a dependency is that you don't have
to re-invent the wheel.  In the case of Geminstaller, which is itself
a wrapper around Rubygems, a dependency can provide a level of
abstraction when the third party tool changes.  I also automatically
run my test suite against the latest trunk of RubyGems via svn
externals and cruise.rb, so I can proactively catch breakages and
coordinate with the RubyGems maintainers:

http://ci.thewoolleyweb.com/builds/geminstaller_trunk_using_rubygems_9-9-9

Anyway, I sent you a separate email off-list to discuss this.  In any
case, it looks like we can collaborate, if only to work on improving
the programmatic interface to RubyGems.

Good Luck,
-- Chad

From thewoolleyman at gmail.com  Sun Apr  6 17:11:59 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 6 Apr 2008 14:11:59 -0700
Subject: [Rubygems-developers] SourceInfoCache vs. SourceIndex (was:
	query_command.rb question and patch)
Message-ID: <e3af97510804061411n3e1d5fb7h88c9ffc96018c35e@mail.gmail.com>

On Sun, Apr 6, 2008 at 1:59 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  Gem::SourceInfoCache.search and search_with_source is what you want to
>  look at.

In RubyGems >1.1.0 (not >= due to current bugs), Is SourceInfoCache
supposed to be the only external programmatic interface for finding
both locally installed and remotely available specs?

In GemInstaller, I'm still using SourceIndex directly.  This is a
holdover because I originally wrote against RubyGems 0.8.11, which
only has SourceIndex (SourceInfoCache did not exist yet).

So, can I supposedly accomplish any local or remote spec query
(including platform-specific queries) using SourceInfoCache?

Thanks,
-- Chad

From stephen.bannasch at deanbrook.org  Sun Apr  6 19:52:11 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Sun, 6 Apr 2008 19:52:11 -0400
Subject: [Rubygems-developers] why rename gem to jgem for jruby?
Message-ID: <p06240812c41f0f5dbfdb@[192.168.1.114]>

Why is changing the name of the default exec format for the gem the default?

I separate all my Ruby installations so that the gems for 1.8, 1.9, and any of my JRuby installs are separate.

Updating to the latest rubygems installed gem as jgem in my JRuby install leaving the gem command that was here previously.

I've always recommended that people NOT mix gem installations in different versions of Ruby. In general how I accomplish that results in different bin directories for the different gem installs.

Gem.default_exec_format => => "j%s" on JRuby

There is this option:

  --no-format-executable

which would result in the new gem exec being named 'gem'.

I noticed this bug report:

[#16879] RubyGems should not install startup script as "jgem" by default on JRuby
http://rubyforge.org/tracker/index.php?func=detail&aid=16879&group_id=126&atid=575

Eric resolved it with this comment:

  It should not be the default, as that will break gem when multiple
  ruby implementations are installed.

Is this common.

I've been responding to people who ask why isn't every command prefixed with 'j' in JRuby like this -- am I wrong?

At 5:50 PM -0400 4/6/08, Stephen Bannasch wrote:
>At 8:47 AM +0000 4/6/08, M C wrote:
>>4) Please re-consider the naming of rake, spec, gem and ri tasks in the bin directory. I would like to co-exist with a normal ruby installation so the first thing I normally do after installing jruby is to rename them all to jrake, jspec, jgem, jri etc. so that I f.x. get MRI's gem when I type "gem" and jruby's gem when I type "jgem". The topic has been brought up before and I know there is resistance to this I just never understood why ?
>
>The renaming would have to be integrated into rubygems -- any gem can install a command line program so your list: jrake, jspec, jgem, jri ... etc would have to also include any other command line program installed by rubygems running under jruby -- jrails, jhaml ... etc.
>
>Some gems compile libraries as part of their install. Hpricot installed under MRI compiles native C libraries while under JRuby it uses a Java library distributed in a jar. In general once Gems that require native code (I'm included Java code as one of the native code examples) are installed they expect to only be used with that os/arch.
>
>Coexistence for me means that none of my MRI and JRuby gems or libraries overlap and that when I want to, for example run rake in JRuby I use: jruby -S rake.
>
>In the past when I wanted to work in JRuby I used to put the path JRUBY_HOME/bin as the first element in my $PATH environmental variable.  This would allow me to run  all the command line ruby programs installed by gems by just typing the names -- but it made it much harder to switch back and forth between C Ruby and JRuby.
>
>Now I use the guidelines described here:
>
>  http://wiki.jruby.org/wiki/Getting_Started
>


From stephen.bannasch at deanbrook.org  Mon Apr  7 00:43:05 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Mon, 7 Apr 2008 00:43:05 -0400
Subject: [Rubygems-developers] gem update --system --no-format-executable
	doesn't work
Message-ID: <p06240814c41f4c20fdb8@[192.168.1.114]>

Using --no-format-executable to keep gem named 'gem' doesn't work 
when running gem update --system.

This command in JRuby:

   $ jruby -S gem update --system --no-format-executable

Installs a gem named jgem.

I've got a trunk checkout of rubygems (r1694) and made the following 
change to see if I could get the update_command to interpret the 
--no-format-executable option but I was unable to build from trunk on 
a MacOS 10.5.2 system

First problem building was with lack of certificates and then after I 
commented out the cert stuff in the Spec in Rakefile I got this error:

   $ rake gem
   ...
   undefined method `write' for "rubygems-update-1.1.0.gem":String

Haven't figured out the cause of that yet.

Anyways here's the change I was trying to test:

$ svn diff lib/rubygems/commands/update_command.rb
Index: lib/rubygems/commands/update_command.rb
===================================================================
--- lib/rubygems/commands/update_command.rb	(revision 1694)
+++ lib/rubygems/commands/update_command.rb	(working copy)
@@ -117,6 +117,7 @@
      args.push '--prefix', Gem.prefix unless Gem.prefix.nil?
      args << '--no-rdoc' unless options[:generate_rdoc]
      args << '--no-ri' unless options[:generate_ri]
+    args << '--no-format-executable' if options[:no_format_executable]

      update_dir = File.join Gem.dir, 'gems', "rubygems-update-#{version}"

I think that might make this command install gem as 'gem':

   $ jruby -S gem update --system --no-format-executable

I can however get an updated rubygems gem command installed as 'gem' 
if I do the two step update like this:

   $ jruby -S gem install rubygems-update
   $ jruby -S update_rubygems --no-format-executable

From thewoolleyman at gmail.com  Mon Apr  7 01:44:45 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 6 Apr 2008 22:44:45 -0700
Subject: [Rubygems-developers] Side effects of latest 1.1.0
In-Reply-To: <71166b3b0804040908w3299ab4dwb740d3a0f8493e31@mail.gmail.com>
References: <71166b3b0804040908w3299ab4dwb740d3a0f8493e31@mail.gmail.com>
Message-ID: <e3af97510804062244s56cd91aubbb13c416b291665@mail.gmail.com>

On Fri, Apr 4, 2008 at 9:08 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  I know this was asked too many times by me, but Eric: _we_ do have a
>  release schedule for RubyGems? Just to give us enough room to test
>  rubygems in a sandboxed environment at least for 2 days to see if
>  there are major issues not found by the automated test suite.

I think the trunk is stable now, and a release should be planned for
early next week.  I don't know of anything in trunk that is more
broken than 1.1.0, and the caching bugs are fixed AFAIK, at least
passing all my tests.

Also, I believe the Rails config.gem stuff has dependencies on
>=1.1.0, so the sooner a new release is out, the less the 1.1.0
caching bugs propogate.

-- Chad

From jftucker at gmail.com  Mon Apr  7 11:04:27 2008
From: jftucker at gmail.com (James Tucker)
Date: Mon, 7 Apr 2008 16:04:27 +0100
Subject: [Rubygems-developers] gem server, gem shortlist links
Message-ID: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>

They're broken as of 1.1.0, I use this feature a lot. The link tags  
should link to a local anchor, instead they link to a postfix-url.

Here's a patch:

Index: server.rb
===================================================================
--- server.rb	(revision 1695)
+++ server.rb	(working copy)
@@ -51,7 +51,7 @@
          <h1>Summary</h1>
    <p>There are <%=values["gem_count"]%> gems installed:</p>
    <p>
-  <%= values["specs"].map { |v| "<a href=\"#{v["name"]} 
\">#{v["name"]}</a>" }.join ', ' %>.
+  <%= values["specs"].map { |v| "<a href=\"##{v["name"]} 
\">#{v["name"]}</a>" }.join ', ' %>.
    <h1>Gems</h1>

    <dl>


Easy mistake to make, thanks for all the hard work guys.

I'd have written a test, but there's no infrastructure for testing it  
that I could see in the test suite, and it's a very very small fix. :-)

From jftucker at gmail.com  Mon Apr  7 11:18:58 2008
From: jftucker at gmail.com (James Tucker)
Date: Mon, 7 Apr 2008 16:18:58 +0100
Subject: [Rubygems-developers] gem server, gem shortlist links
In-Reply-To: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>
References: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>
Message-ID: <A67B2945-62A6-4DD4-BF42-4B4C384F1BD6@gmail.com>

Sorry for the double post...

I just realized that my rubyforge account may allow me to commit this?

May / Should I?

On 7 Apr 2008, at 16:04, James Tucker wrote:
> They're broken as of 1.1.0, I use this feature a lot. The link tags  
> should link to a local anchor, instead they link to a postfix-url.
>
> Here's a patch:
>
> Index: server.rb
> ===================================================================
> --- server.rb	(revision 1695)
> +++ server.rb	(working copy)
> @@ -51,7 +51,7 @@
>        <h1>Summary</h1>
>  <p>There are <%=values["gem_count"]%> gems installed:</p>
>  <p>
> -  <%= values["specs"].map { |v| "<a href=\"#{v["name"]} 
> \">#{v["name"]}</a>" }.join ', ' %>.
> +  <%= values["specs"].map { |v| "<a href=\"##{v["name"]} 
> \">#{v["name"]}</a>" }.join ', ' %>.
>  <h1>Gems</h1>
>
>  <dl>
>
>
> Easy mistake to make, thanks for all the hard work guys.
>
> I'd have written a test, but there's no infrastructure for testing  
> it that I could see in the test suite, and it's a very very small  
> fix. :-)


From stephen.bannasch at deanbrook.org  Mon Apr  7 11:21:39 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Mon, 7 Apr 2008 11:21:39 -0400
Subject: [Rubygems-developers] how about a
	--differentiate-executable-gem-command option
Message-ID: <p06240816c41f57d7bc95@[192.168.1.114]>

I'd much rather have the default name for the gem command be 'gem' 
and have differentiated gem commands names created when something 
like this option is passed:

   --differentiate-executable-gem-command

There are already many questions from people installing JRuby who 
have ended up in a mess by installing gems for Jruby in the same 
place gems for MRI are installed -- changing the default gem name to 
jgem will just prolong the time it takes for them to realize they've 
screwed up without giving any obvious benefit.



From charles.nutter at Sun.COM  Mon Apr  7 11:28:22 2008
From: charles.nutter at Sun.COM (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 10:28:22 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <476AFBB5.1090604@sun.com>
References: <476AFBB5.1090604@sun.com>
Message-ID: <47FA3D96.1020103@sun.com>

Charles Oliver Nutter wrote:
> 1. jgem?
> 
> I saw this during the 1.0.0 install:
> 
> install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem
> 
> Why jgem? We've been shipping with just 'gem'.

It took me a couple months to notice this had been closed without being 
fixed:

http://rubyforge.org/tracker/index.php?func=detail&aid=16879&group_id=126&atid=575

I disgree that 'jgem' should be the default, since many people that run 
JRuby run only JRuby, tutorials state 'gem' as the command, and people 
are used to typing 'gem'. If people are using both JRuby and Ruby and 
want to avoid naming conflicts, they can add an alias easily enough or 
juggle PATH entries. But JRuby is "just another Ruby impl" and shouldn't 
have a different command name for installing gems.

Can we please have the 'gem' name as default when installing on JRuby?

- Charlie

From me at susanpotter.net  Mon Apr  7 11:59:44 2008
From: me at susanpotter.net (Susan Potter)
Date: Mon, 7 Apr 2008 10:59:44 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FA3D96.1020103@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
Message-ID: <1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>

>  I disgree that 'jgem' should be the default, since many people that run
>  JRuby run only JRuby, tutorials state 'gem' as the command, and people
>  are used to typing 'gem'. If people are using both JRuby and Ruby and
>  want to avoid naming conflicts, they can add an alias easily enough or
>  juggle PATH entries. But JRuby is "just another Ruby impl" and shouldn't
>  have a different command name for installing gems.
>
>  Can we please have the 'gem' name as default when installing on JRuby?
What about those of us that need to use both Ruby and JRuby?  Yes, I
know PATH is the answer, but very cumbersome.

The problem with your argument above is that JRuby's main binary is
actually called jruby, so I would argue that it is far more consistent
to say jgem.

That is my two cents.
Susan

From luislavena at gmail.com  Mon Apr  7 12:03:52 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 7 Apr 2008 13:03:52 -0300
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FA3D96.1020103@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
Message-ID: <71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>

On Mon, Apr 7, 2008 at 12:28 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Charles Oliver Nutter wrote:
>  > 1. jgem?
>  >
>  > I saw this during the 1.0.0 install:
>  >
>  > install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem
>  >
>  > Why jgem? We've been shipping with just 'gem'.
>
>  It took me a couple months to notice this had been closed without being
>  fixed:
>
>
>  http://rubyforge.org/tracker/index.php?func=detail&aid=16879&group_id=126&atid=575
>
>  I disgree that 'jgem' should be the default, since many people that run
>  JRuby run only JRuby, tutorials state 'gem' as the command, and people
>  are used to typing 'gem'. If people are using both JRuby and Ruby and
>  want to avoid naming conflicts, they can add an alias easily enough or
>  juggle PATH entries. But JRuby is "just another Ruby impl" and shouldn't
>  have a different command name for installing gems.
>
>  Can we please have the 'gem' name as default when installing on JRuby?
>

Charlie:

I can point you to several posts of people with messed PATH and ended
with problems installing gem, just a few weeks back, here on this
list:

http://rubyforge.org/pipermail/rubygems-developers/2008-March/003633.html

I got several mails to my inbox about Mongrel too, and some "new" ones
for One-Click Installer...

So the thing is: if JRuby uses RubyGems, and 'ruby' executable is
labeled 'jruby', why not name rubygems 'jgem'?

In any case, there should be a warning or something if another ruby
implementation is in the PATH...

I don't know how to fix this and makes everybody happy...
-- 
Luis Lavena
Multimedia systems
-
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 jftucker at gmail.com  Mon Apr  7 12:39:44 2008
From: jftucker at gmail.com (James Tucker)
Date: Mon, 7 Apr 2008 17:39:44 +0100
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
Message-ID: <DECDE963-F7E6-4D1A-A911-E1E1102F78E3@gmail.com>


On 7 Apr 2008, at 17:03, Luis Lavena wrote:
> On Mon, Apr 7, 2008 at 12:28 PM, Charles Oliver Nutter
> <charles.nutter at sun.com> wrote:
>> Charles Oliver Nutter wrote:
>>> 1. jgem?
>>>
>>> I saw this during the 1.0.0 install:
>>>
>>> install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/ 
>>> bin/jgem
>>>
>>> Why jgem? We've been shipping with just 'gem'.
>>
>> Can we please have the 'gem' name as default when installing on  
>> JRuby?
>>
>
> Charlie:
>
> http://rubyforge.org/pipermail/rubygems-developers/2008-March/003633.html
>
> So the thing is: if JRuby uses RubyGems, and 'ruby' executable is
> labeled 'jruby', why not name rubygems 'jgem'?
>
> In any case, there should be a warning or something if another ruby
> implementation is in the PATH...

On *nix systems, 0.9.5 moved to gem<version>, which also caused  
various things to break for mixed package manager vs. gem update -- 
system configurations.

Nonetheless that seemed like a sensible thing to do, so maybe it's  
good to move toward one that parallels the interpreter or platform  
more specifically than 'major.minor ruby version'?

> I don't know how to fix this and makes everybody happy...

I don't know that it would make everyone happy, but printing the  
interpreter path or general system configuration details in a header  
for runs of the command might help (me, and maybe you).

From charles.nutter at sun.com  Mon Apr  7 13:49:27 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 12:49:27 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
Message-ID: <47FA5EA7.5030302@sun.com>

Luis Lavena wrote:
> Charlie:
> 
> I can point you to several posts of people with messed PATH and ended
> with problems installing gem, just a few weeks back, here on this
> list:
> 
> http://rubyforge.org/pipermail/rubygems-developers/2008-March/003633.html
> 
> I got several mails to my inbox about Mongrel too, and some "new" ones
> for One-Click Installer...
> 
> So the thing is: if JRuby uses RubyGems, and 'ruby' executable is
> labeled 'jruby', why not name rubygems 'jgem'?

Because Rails installs as 'rails', Rake installs as 'rake', RSpec 
installs as 'spec', and so on. Unless we're going to consistently add a 
prefix or suffix to all installed scripts, this is only going to be 
confusing.

Besides, if someone really needs JRuby's 'gem' script to be 'jgem', it 
can be aliased or symlinked trivially, or you can run "jruby -S gem" to 
pick up the one associated with your current JRuby version. JRuby 
doesn't install its executables in a global path, so you can change 
anything you want.

FWIW, I'm going to continue including a 'gem' script with JRuby releases 
no matter what, since that's the command everyone uses and I want it to 
work.

> In any case, there should be a warning or something if another ruby
> implementation is in the PATH...
> 
> I don't know how to fix this and makes everybody happy...

Make it 'gem' in all cases, and people can add aliases as they desire. I 
really don't think it should be different for different impls, since 
it's the same library, the same code, the same logic. It should be 'gem'.

- Charlie

From charles.nutter at sun.com  Mon Apr  7 13:52:48 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 12:52:48 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
Message-ID: <47FA5F70.2050609@sun.com>

Susan Potter wrote:
>>  I disgree that 'jgem' should be the default, since many people that run
>>  JRuby run only JRuby, tutorials state 'gem' as the command, and people
>>  are used to typing 'gem'. If people are using both JRuby and Ruby and
>>  want to avoid naming conflicts, they can add an alias easily enough or
>>  juggle PATH entries. But JRuby is "just another Ruby impl" and shouldn't
>>  have a different command name for installing gems.
>>
>>  Can we please have the 'gem' name as default when installing on JRuby?
> What about those of us that need to use both Ruby and JRuby?  Yes, I
> know PATH is the answer, but very cumbersome.

PATH is one answer.
aliasing 'jgem' to 'jruby -S gem' is another.
linking 'gem' to jruby/bin/gem' is another.
running 'jruby -S gem' is another.

I don't think there's really that much difficulty running gem with JRuby 
when Ruby is in path, especially with the -S option.

And we ship with jirb, but that's mostly out of tradition now and 
because it's not something installed externally like rubygems or gems 
themselves.

> The problem with your argument above is that JRuby's main binary is
> actually called jruby, so I would argue that it is far more consistent
> to say jgem.

The amount of confusion that would arise from JRuby including a "ruby" 
script would be pretty bad, especially since we're talking about two 
completely different codebases. That doesn't apply to RubyGems, since 
it's identical in both Ruby and JRuby. It should use the same executable 
name, 'gem', in both cases, since it's the same code.

Or if you think it should be 'jgem', then perhaps 'jrails', 'jrake', 
'jspec', 'jmerb' and so on are also consistent? Seems a little absurd to me.

- Charlie

From stephen.bannasch at deanbrook.org  Mon Apr  7 13:58:42 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Mon, 7 Apr 2008 13:58:42 -0400
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
Message-ID: <p06240818c41fff94eca8@[192.168.1.114]>

At 1:03 PM -0300 4/7/08, Luis Lavena wrote:
>On Mon, Apr 7, 2008 at 12:28 PM, Charles Oliver Nutter
><charles.nutter at sun.com> wrote:
>> Charles Oliver Nutter wrote:
>>  > 1. jgem?
>>  >
>>  > I saw this during the 1.0.0 install:
>>  >
>>  > install -c -m 0755 /tmp/gem /Users/headius/NetBeansProjects/jruby/bin/jgem
>>  >
>>  > Why jgem? We've been shipping with just 'gem'.
>>
>>  It took me a couple months to notice this had been closed without being
>>  fixed:
>>
>>
>>  http://rubyforge.org/tracker/index.php?func=detail&aid=16879&group_id=126&atid=575
>>
>>  I disgree that 'jgem' should be the default, since many people that run
>>  JRuby run only JRuby, tutorials state 'gem' as the command, and people
>>  are used to typing 'gem'. If people are using both JRuby and Ruby and
>>  want to avoid naming conflicts, they can add an alias easily enough or
>>  juggle PATH entries. But JRuby is "just another Ruby impl" and shouldn't
>>  have a different command name for installing gems.
>>
>>  Can we please have the 'gem' name as default when installing on JRuby?
>>
>
>Charlie:
>
>I can point you to several posts of people with messed PATH and ended
>with problems installing gem, just a few weeks back, here on this
>list:
>
>http://rubyforge.org/pipermail/rubygems-developers/2008-March/003633.html

Changing the name to jgem will just delay the mess Daniel was getting into for a little while.

Daniels problem was that he was running the jruby gem when he thought he was running the mri gem. This is presumably because he had modified the windows equivalent of PATH so that the path to jruby.home/bin came ahead of the MRI one.

Changing the name to jgem fixes that confusion ... but as long as people want to run two or more versions of a  ruby vm moving the alternate.ruby.vm/bin path to the top of the PATH list is going to be fragile.

Almost nobody will type jgem when they intend to type gem but by putting alternate.ruby.vm/bin first on the PATH they could then easily type some other installed ruby command which would then run in the alternate.ruby.vm without noticing.

In general MRI Ruby either comes installed in a system or can be installed as a system package -- in general I think that's the Ruby that should run when someone types gem, rake, ri, etc.

When you want to run alternate.ruby.vm/bin/gem first make sure that alternate.ruby.vm/bin is on the PATH at the end and type this instead:

  $ alternate.ruby.vm -S gem
  $ alternate.ruby.vm -S rake
  $ alternate.ruby.vm -S ri

If that's too much typing make an alias

  jgem=jruby -S gem

If you want to only use alternate.ruby.vm and you want to treat it in effect as your system ruby for a while construct an install architecture so the whole thing can be switched easily.

So for example:

  /usr/bin/ruby

could be a symbolic link pointing to

  /usr/bin/ruby_mri_1.8.6
  /usr/bin/ruby_mri_1.9
  /usr/bin/jruby_1.1

And all the rest of the environment variables are setup accordingly when you switch ruby vms.

I haven't heard about anybody who is running two or more ruby vms and wants them to share the same local gem local cache.

If you have to separate the gem caches then you'll need to separate the ruby.vm/bin directories -- unless you apply the renaming commands to every gem installed (and rename the existing gems commands when rubygems is updated).

I like having multiple vms and being in a program directory and being able to type:

  ruby test_my_app.rb
  jruby -S test_my_app.rb

and know for sure what gems and libraries will be used.

>I got several mails to my inbox about Mongrel too, and some "new" ones
>for One-Click Installer...
>
>So the thing is: if JRuby uses RubyGems, and 'ruby' executable is
>labeled 'jruby', why not name rubygems 'jgem'?
>
>In any case, there should be a warning or something if another ruby
>implementation is in the PATH...

>I don't know how to fix this and makes everybody happy...

Maybe this method could help achieve a larger goal:

def find_all_gem_commands(gem_command='gem')
  gem_command_locations = ENV['PATH'].split(':').find_all {|path| File.exists?(path + File::SEPARATOR + gem_command)}.uniq
  gem_command_locations =  gem_command_locations.collect {|path| path + File::SEPARATOR + gem_command}
  gem_commands = {}
  gem_command_locations.each do |location|
    gem_commands[location]=File.open(location) {|f| f.gets.strip}[/\w*$/]
  end
  gem_commands
end

find_all_gem_commands
=> {"/usr/bin/gem"=>"ruby", "/Users/stephen/dev/jruby_trunk/jruby/bin/gem"=>"jruby"}

find_all_gem_commands('rake')
=> {"/Users/stephen/dev/jruby_trunk/jruby/bin/rake"=>"jruby", "/usr/bin/rake"=>"ruby"}

From me at susanpotter.net  Mon Apr  7 15:48:01 2008
From: me at susanpotter.net (Susan Potter)
Date: Mon, 7 Apr 2008 14:48:01 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FA5EA7.5030302@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
Message-ID: <1076b0d90804071248v5a4cf2ebv87defd798c7951ae@mail.gmail.com>

>  Because Rails installs as 'rails', Rake installs as 'rake', RSpec
>  installs as 'spec', and so on. Unless we're going to consistently add a
>  prefix or suffix to all installed scripts, this is only going to be
>  confusing.
Actually that is for the Rails and RSpec projects to decide
themselves.  We are all separate projects remember:)  We cannot
dictate what separate projects do.  RubyGems is a little more than
just Rails or RSpec.  It is used in virtually every Rubyforge project
to some extent (and if you are using RubyGems you will agree that it's
importance supersedes that of Rails or Rspec which is not used in
virtually every project).

>  Besides, if someone really needs JRuby's 'gem' script to be 'jgem', it
>  can be aliased or symlinked trivially, or you can run "jruby -S gem" to
>  pick up the one associated with your current JRuby version. JRuby
>  doesn't install its executables in a global path, so you can change
>  anything you want.
You are trivializing the problem as explained in the ticket and on the
mailing list.  However, I will admit I am not on Windows (thankfully)
so I do not see the larger issues that others have reported.  However
I agree with the following statement from Stephen Bannasch.....

> Changing the name to jgem will just delay the mess Daniel was getting into for a little while.
Yes, but it might buy RubyGems time to sort the mess out.  It is a
large problem and cannot be treated as something that only requires a
minor fix like others have trivialized it above.

If JRuby people are so hung up on keeping it as gem instead of
renaming it to jgem, then let us address this appropriately instead of
suggesting quick fix solutions that keep it named 'gem', BUT still
postpone the same mess for later anyway AND give some people grief in
the near-term.  Thankfully I am not affected by this anymore and my
solution was to stop using JRuby (yay!) at work, but I know people on
my old team are bitten by these issues all the time in the Java/JRuby
world.

Thanks,
Susan

From drbrain at segment7.net  Mon Apr  7 16:26:32 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 13:26:32 -0700
Subject: [Rubygems-developers] gem update --system
	--no-format-executable doesn't work
In-Reply-To: <p06240814c41f4c20fdb8@[192.168.1.114]>
References: <p06240814c41f4c20fdb8@[192.168.1.114]>
Message-ID: <A54B64C7-8813-4018-B66A-9D384F7E956C@segment7.net>

On Apr 6, 2008, at 21:43 PM, Stephen Bannasch wrote:
> Using --no-format-executable to keep gem named 'gem' doesn't work
> when running gem update --system.
>
> [...]
>
> Anyways here's the change I was trying to test:
>
> $ svn diff lib/rubygems/commands/update_command.rb
> Index: lib/rubygems/commands/update_command.rb
> ===================================================================
> --- lib/rubygems/commands/update_command.rb	(revision 1694)
> +++ lib/rubygems/commands/update_command.rb	(working copy)
> @@ -117,6 +117,7 @@
>      args.push '--prefix', Gem.prefix unless Gem.prefix.nil?
>      args << '--no-rdoc' unless options[:generate_rdoc]
>      args << '--no-ri' unless options[:generate_ri]
> +    args << '--no-format-executable' if  
> options[:no_format_executable]
>
>      update_dir = File.join Gem.dir, 'gems', "rubygems-update- 
> #{version}"
>

This looks good, I will commit it.

> I think that might make this command install gem as 'gem':
>
>   $ jruby -S gem update --system --no-format-executable
>
> I can however get an updated rubygems gem command installed as 'gem'
> if I do the two step update like this:
>
>   $ jruby -S gem install rubygems-update
>   $ jruby -S update_rubygems --no-format-executable

Since the existing RubyGems doesn't pass this along, this is what  
you'll need until it's in an installed version.

From me at susanpotter.net  Mon Apr  7 16:27:59 2008
From: me at susanpotter.net (Susan Potter)
Date: Mon, 7 Apr 2008 15:27:59 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FA5F70.2050609@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
	<47FA5F70.2050609@sun.com>
Message-ID: <1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>

>  PATH is one answer.
>  aliasing 'jgem' to 'jruby -S gem' is another.
>  linking 'gem' to jruby/bin/gem' is another.
>  running 'jruby -S gem' is another.
BTW the problem under discussion isn't on Linux/BSD or other UNIX
systems it is on Windows, I hope you are aware that we are talking
about the following?

See:
http://rubyforge.org/pipermail/rubygems-developers/2008-March/003635.html
and
http://rubyforge.org/pipermail/rubygems-developers/2008-March/003636.html

The problem is that the JRuby gem was always running even when the MRI
binary path was in front of it in the PATH variable on Windows.  The
only solution is to create aliases the other way: to alias
/full/path/to/c/ruby/gem to rgem, which is the converse of your
solution and still ends up with people using different names for
different implementations locally.  So scripts, etc. need to take this
in consideration anyway, and promotes a non-uniform way of doing
things just to get things working like we would expectg.

I am no longer on Windows, so I cannot comment, but the PATH
switch/aliasing is a PITA either even on Linux.  Nobody needs to tell
me Windows is not ideal for most open source development that isn't
based on .NET or related MS products/languages, but millions of
businesses make their developers use it.

In theory you are right, there shouldn't be different names for
different implementation versions of RubyGems when it is ultimately
the same underlying source, however, in practice developers caught out
with these issues on Windows are the ones that send tons of emails
requesting support to RubyGems.  Finger pointing to RubyGems rather
than JRuby, when in fact it appears to be a JRuby fault, not RubyGems.
 Isn't this right Luis?  In addition, I see RubyGems as an extension
(not necessarily as in Ruby/C extension, just in the general meaning
of "extension") to a Ruby implementation than just another gem, so I
would argue that it could go either way.

Has anyone contacted JRuby about these issues and know what the status
of their fix is and when it is expected to be released?  If it isn't
resolved or planned to be shortly is the RubyGems project willing to
take the hit for a JRuby issue that they do not deem important to
solve?

Just curious
Susan

From me at susanpotter.net  Mon Apr  7 16:29:40 2008
From: me at susanpotter.net (Susan Potter)
Date: Mon, 7 Apr 2008 15:29:40 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
	<47FA5F70.2050609@sun.com>
	<1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>
Message-ID: <1076b0d90804071329t7dde6b65g8d289dcee9581f9a@mail.gmail.com>

I didn't really mean to say the *only* solution is, but using the full
path to the MRI gem is not a useful solution generally, except
possibly in scripts (maybe).

From luislavena at gmail.com  Mon Apr  7 16:43:54 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 7 Apr 2008 17:43:54 -0300
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
	<47FA5F70.2050609@sun.com>
	<1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>
Message-ID: <71166b3b0804071343v6def5b5cw95b262c5243eb08c@mail.gmail.com>

On Mon, Apr 7, 2008 at 5:27 PM, Susan Potter <me at susanpotter.net> wrote:
> >  PATH is one answer.
>  >  aliasing 'jgem' to 'jruby -S gem' is another.
>  >  linking 'gem' to jruby/bin/gem' is another.
>  >  running 'jruby -S gem' is another.
>  BTW the problem under discussion isn't on Linux/BSD or other UNIX
>  systems it is on Windows, I hope you are aware that we are talking
>  about the following?
>
>  See:
>  http://rubyforge.org/pipermail/rubygems-developers/2008-March/003635.html
>  and
>  http://rubyforge.org/pipermail/rubygems-developers/2008-March/003636.html
>

I'll like to add that _this can happen under Linux/BSD too_

If jRuby 'gem' script overwrites MRI one, or in cae you installed
jruby in not a default path (and altered $PATH), then you will face
the same situation described on those emails.

>  The problem is that the JRuby gem was always running even when the MRI
>  binary path was in front of it in the PATH variable on Windows.  The
>  only solution is to create aliases the other way: to alias
>  /full/path/to/c/ruby/gem to rgem, which is the converse of your
>  solution and still ends up with people using different names for
>  different implementations locally.  So scripts, etc. need to take this
>  in consideration anyway, and promotes a non-uniform way of doing
>  things just to get things working like we would expectg.
>

There is a order of precedence for the batch files scripts:

>set PATHEXT
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.RB;.RBW

If you was running with a older (pre 1.0 version of rubygems) or older
One-Click installer, the stub scripts generated by Windows were
'.cmd', and JRuby ships with '.bat' files, which got higher precedence
over .cmd files.

So, "in the wild", is quite common this situation. Under latest -
updated scenarios shouldn't happen, unless JRuby is set in front of
the PATH.

>  I am no longer on Windows, so I cannot comment, but the PATH
>  switch/aliasing is a PITA either even on Linux.  Nobody needs to tell
>  me Windows is not ideal for most open source development that isn't
>  based on .NET or related MS products/languages, but millions of
>  businesses make their developers use it.
>

Indeed

>  In theory you are right, there shouldn't be different names for
>  different implementation versions of RubyGems when it is ultimately
>  the same underlying source, however, in practice developers caught out
>  with these issues on Windows are the ones that send tons of emails
>  requesting support to RubyGems.  Finger pointing to RubyGems rather
>  than JRuby, when in fact it appears to be a JRuby fault, not RubyGems.
>   Isn't this right Luis?

On the spot! I got several mails related to Mongrel, mongrel_service
and some gems under One-Click that failed due NetBeans installation of
jRuby or being jRuby set on the PATH "under unknown circumstances".

>  Has anyone contacted JRuby about these issues and know what the status
>  of their fix is and when it is expected to be released?  If it isn't
>  resolved or planned to be shortly is the RubyGems project willing to
>  take the hit for a JRuby issue that they do not deem important to
>  solve?
>

I guess Charles is the right person to ask, since he is part of JRuby team.

Taking responsibility, latest One-Click Installer (1.8.6-26) ships
with .bat files instead of original .cmd ones, and new rubygems
updates will generate the correct .bat file too.

On other projects, I cannot comment or provide more than I'm doing
right now, and even with all that, there are 2 to 5 issues about this
weekly or so.

Regards,
-- 
Luis Lavena
Multimedia systems
-
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 me at susanpotter.net  Mon Apr  7 16:55:31 2008
From: me at susanpotter.net (Susan Potter)
Date: Mon, 7 Apr 2008 15:55:31 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804071343v6def5b5cw95b262c5243eb08c@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<1076b0d90804070859q5f4b2606t10c2a1f7b905e774@mail.gmail.com>
	<47FA5F70.2050609@sun.com>
	<1076b0d90804071327h652fea8dq5d18ceb0575c89d9@mail.gmail.com>
	<71166b3b0804071343v6def5b5cw95b262c5243eb08c@mail.gmail.com>
Message-ID: <1076b0d90804071355q7282c76we3bb7698f6b902b6@mail.gmail.com>

>  I'll like to add that _this can happen under Linux/BSD too_
Thanks for the clarification.  I will admit I just assumed it had to
be something related to Windows due to my inherent biases:)

From drbrain at segment7.net  Mon Apr  7 17:23:36 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 14:23:36 -0700
Subject: [Rubygems-developers] Side effects of latest 1.1.0
In-Reply-To: <71166b3b0804040908w3299ab4dwb740d3a0f8493e31@mail.gmail.com>
References: <71166b3b0804040908w3299ab4dwb740d3a0f8493e31@mail.gmail.com>
Message-ID: <17C7E4B0-D93E-4A81-A537-0E07F57116B2@segment7.net>

On Apr 4, 2008, at 09:08 AM, Luis Lavena wrote:
> Hello Guys,
>
> I'm getting a few hits on some tickets regarding latest release  
> (1.1.0):
>
> win32-service requirement for 0.3.4 no longer in rubyforge gem  
> repository
> http://mongrel.rubyforge.org/ticket/27
>
> This is cache related, as Chad Woolley described previously, but which
> current solution breaks all the tests, as detailed in ticket #19228:
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=19228&group_id=126&atid=575
>
> This just show up, but is possible other gems faces the same situation
> we have here.

It seems that this has been fixed, trunk installs mongrel_service just  
fine:

$ rm -r ~/tmp/gems
$ rake rungem -- install -i ~/tmp/gems --platform=mswin32  
mongrel_service --no-ri --no-rdoc
[...]
Successfully installed gem_plugin-0.2.3
Successfully installed cgi_multipart_eof_fix-2.5.0
Successfully installed mongrel-1.1.4-x86-mswin32-60
Successfully installed win32-service-0.5.2-x86-mswin32
Successfully installed mongrel_service-0.3.4-x86-mswin32
5 gems installed
$

> ==
>
> [#19274] Cannot retrieve gems after updating to 1.1.0 on Windows
> http://rubyforge.org/tracker/index.php?func=detail&aid=19274&group_id=126&atid=575
>
> This one is related to Errno::ECONNABORTED not being rescued by the
> Remote Fetched, which I found after 1.1.0 release.
>
> I know this was asked too many times by me, but Eric: _we_ do have a
> release schedule for RubyGems? Just to give us enough room to test
> rubygems in a sandboxed environment at least for 2 days to see if
> there are major issues not found by the automated test suite.

I have a few more changes to make, then we can wait for feedback on  
trunk for two days before releasing 1.1.1.

From drbrain at segment7.net  Mon Apr  7 17:26:40 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 14:26:40 -0700
Subject: [Rubygems-developers] gem server, gem shortlist links
In-Reply-To: <A67B2945-62A6-4DD4-BF42-4B4C384F1BD6@gmail.com>
References: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>
	<A67B2945-62A6-4DD4-BF42-4B4C384F1BD6@gmail.com>
Message-ID: <0C905509-6239-4141-B2F4-A8A0DEF4F32D@segment7.net>

On Apr 7, 2008, at 08:18 AM, James Tucker wrote:
> Sorry for the double post...
>
> I just realized that my rubyforge account may allow me to commit this?
>
> May / Should I?

Only if you've been added to the project, which I don't think you have.

From drbrain at segment7.net  Mon Apr  7 17:32:04 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 14:32:04 -0700
Subject: [Rubygems-developers] gem server, gem shortlist links
In-Reply-To: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>
References: <ED4B8841-C738-4CA2-8950-1FCC3F9831AB@gmail.com>
Message-ID: <4D19FA93-ED45-44AC-A478-7F6832458EDB@segment7.net>

On Apr 7, 2008, at 08:04 AM, James Tucker wrote:
> They're broken as of 1.1.0, I use this feature a lot. The link tags
> should link to a local anchor, instead they link to a postfix-url.
>
> Here's a patch:

Committed.

> I'd have written a test, but there's no infrastructure for testing it
> that I could see in the test suite, and it's a very very small  
> fix. :-)

Yes, unfortunately :(

From drbrain at segment7.net  Mon Apr  7 18:19:27 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 15:19:27 -0700
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FA5EA7.5030302@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
Message-ID: <1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>

On Apr 7, 2008, at 10:49 AM, Charles Oliver Nutter wrote:
> Luis Lavena wrote:
>> I can point you to several posts of people with messed PATH and ended
>> with problems installing gem, just a few weeks back, here on this
>> list:
>>
>> http://rubyforge.org/pipermail/rubygems-developers/2008-March/003633.html
>>
>> I got several mails to my inbox about Mongrel too, and some "new"  
>> ones
>> for One-Click Installer...
>>
>> So the thing is: if JRuby uses RubyGems, and 'ruby' executable is
>> labeled 'jruby', why not name rubygems 'jgem'?
>
> Because Rails installs as 'rails', Rake installs as 'rake', RSpec
> installs as 'spec', and so on. Unless we're going to consistently  
> add a
> prefix or suffix to all installed scripts, this is only going to be
> confusing.
>
> Besides, if someone really needs JRuby's 'gem' script to be 'jgem', it
> can be aliased or symlinked trivially, or you can run "jruby -S gem"  
> to
> pick up the one associated with your current JRuby version. JRuby
> doesn't install its executables in a global path, so you can change
> anything you want.
>
> FWIW, I'm going to continue including a 'gem' script with JRuby  
> releases
> no matter what, since that's the command everyone uses and I want it  
> to
> work.

I'm willing to change the default in a future minor release (not  
1.1.1), but primarily I think the problem is going to be user education.

Is there any particular reason why JRuby and Ruby can't use the same  
gem repository?  (Currently Rubinius does not, but after reading this  
thread, I think that may be a mistake).

AFAIK, RubyGems is smart enough to pick a JRuby-platform gem only for  
JRuby, and will Just Work if both the JRuby and non-JRuby platform  
gems are installed.

This would allow a single `gem` command to work for all ruby  
implementations.

From drbrain at segment7.net  Mon Apr  7 18:20:28 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Mon, 7 Apr 2008 15:20:28 -0700
Subject: [Rubygems-developers] RubyGems 1.1.1 outstanding issues?
Message-ID: <17E21E04-DC22-415E-B8F1-E03348BA5256@segment7.net>

Are there any further outstanding issues for a RubyGems 1.1.1?

If no further issues are discovered, I will release 1.1.1 Wednesday  
afternoon.

From luislavena at gmail.com  Mon Apr  7 18:52:57 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 7 Apr 2008 19:52:57 -0300
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
Message-ID: <71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>

On Mon, Apr 7, 2008 at 7:19 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Apr 7, 2008, at 10:49 AM, Charles Oliver Nutter wrote:
>
>
>  >
>  > FWIW, I'm going to continue including a 'gem' script with JRuby
>  > releases
>  > no matter what, since that's the command everyone uses and I want it
>  > to
>  > work.
>
>  I'm willing to change the default in a future minor release (not
>  1.1.1), but primarily I think the problem is going to be user education.
>
>  Is there any particular reason why JRuby and Ruby can't use the same
>  gem repository?  (Currently Rubinius does not, but after reading this
>  thread, I think that may be a mistake).
>

I think the problem is related to RbConfig and where it supposed to
find gems on:

  - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]
  - INSTALLATION DIRECTORY: C:/Ruby/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: C:/Ruby/bin/ruby.exe
  - GEM PATHS:
    - C:/Ruby/lib/ruby/gems/1.8

===

  - RUBY VERSION: 1.8.6 (2008-03-28 patchlevel 6360) [java]
  - INSTALLATION DIRECTORY: C:/JRuby/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: C:/JRuby/bin/jruby.bat.exe
  - GEM PATHS:
     - C:/JRuby/lib/ruby/gems/1.8

The thing is neither of Ruby implementation are aware of each other.

PS: bikeshed?

-- 
Luis Lavena
Multimedia systems
-
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 charles.nutter at sun.com  Mon Apr  7 20:13:26 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 19:13:26 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
Message-ID: <47FAB8A6.3030008@sun.com>

Eric Hodel wrote:
> I'm willing to change the default in a future minor release (not  
> 1.1.1), but primarily I think the problem is going to be user education.

Why not 1.1.1? This isn't a lot of effort, is it? And we're already 
modifying our built-in install of RubyGems to use 'gem', so it's 
actually the jgem that's confusing people. I think this should go out in 
1.1.1.

> Is there any particular reason why JRuby and Ruby can't use the same  
> gem repository?  (Currently Rubinius does not, but after reading this  
> thread, I think that may be a mistake).

No particular reason...it works, we just don't really recommend it. If 
the automatic platform-gem-picking works seamlessly, it could certainly 
be just fine...but I haven't had much chance to play with that 
(especially installing the same gems into the same repository with the 
same index and RubyGems knowing to install two different platform 
versions of the same gem).

It's also fairly common for people to have multiple JRuby copies around, 
and pretty easy to do so. So keeping the gems within the JRuby subdirs 
is more convenient for isolating them. But like I say, sharing a gem 
repo may work just fine...we don't do anything that would prevent it.

- Charlie

From charles.nutter at sun.com  Mon Apr  7 20:25:38 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 19:25:38 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1076b0d90804071248v5a4cf2ebv87defd798c7951ae@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1076b0d90804071248v5a4cf2ebv87defd798c7951ae@mail.gmail.com>
Message-ID: <47FABB82.2010404@sun.com>

Susan Potter wrote:
> Actually that is for the Rails and RSpec projects to decide
> themselves.  We are all separate projects remember:)  We cannot
> dictate what separate projects do.  RubyGems is a little more than
> just Rails or RSpec.  It is used in virtually every Rubyforge project
> to some extent (and if you are using RubyGems you will agree that it's
> importance supersedes that of Rails or Rspec which is not used in
> virtually every project).

Sure, most of them use RubyGems...but that doesn't change at all in 
JRuby because they still require 'rubygems', call "gem 'whatever'" in 
code. In fact just about all use of RubyGems in JRuby is identical to 
the use of RubyGems in standard Ruby...so the 'jgem' thing is the 
anomaly here.

> You are trivializing the problem as explained in the ticket and on the
> mailing list.  However, I will admit I am not on Windows (thankfully)
> so I do not see the larger issues that others have reported.  However
> I agree with the following statement from Stephen Bannasch.....

The ticket only talked about avoiding conflicts between JRuby and 
regular Ruby, which is largely a red herring since *every* other app 
people install with RubyGems will conflict too and be called a lot more 
often (you don't install gems nearly as often as you run the scripts 
they install).

>> Changing the name to jgem will just delay the mess Daniel was getting into for a little while.
> Yes, but it might buy RubyGems time to sort the mess out.  It is a
> large problem and cannot be treated as something that only requires a
> minor fix like others have trivialized it above.

JRuby is just another Ruby implementation, and users of JRuby should be 
able to just run the same commands they would with the C implementation. 
If they want to install RubyGems as "jgem" or rename any of the other 
scripts that get installed, so be it. But JRuby is Ruby...and the naming 
of the 'gem' script should not be different when RubyGems in JRuby is 
otherwise almost identical to that installed in standard Ruby.

And since we've been shipping with RubyGems in JRuby for well over a 
year with the script named 'gem', the change *after* that time to 
install as 'jgem' is a real problem.

> If JRuby people are so hung up on keeping it as gem instead of
> renaming it to jgem, then let us address this appropriately instead of
> suggesting quick fix solutions that keep it named 'gem', BUT still
> postpone the same mess for later anyway AND give some people grief in
> the near-term.  Thankfully I am not affected by this anymore and my
> solution was to stop using JRuby (yay!) at work, but I know people on
> my old team are bitten by these issues all the time in the Java/JRuby
> world.

Note that the change to jgem was made intentionally (for unknown 
reasons?) without ever talking to the JRuby team in the first place. And 
we would have said "no, please don't do it." Your comment about "stop 
using JRuby (yay!)" seems to show that you don't really care about 
making things easier for JRuby users.

Besides, there would still be a flag to install as 'jgem' and numerous 
other ways to isolate JRuby from standard Ruby. This is a minor point, 
I'm really not sure why it's a big deal to just make it 'gem' everywhere.

- Charlie

From laurent.sansonetti at gmail.com  Mon Apr  7 20:38:50 2008
From: laurent.sansonetti at gmail.com (Laurent Sansonetti)
Date: Mon, 7 Apr 2008 17:38:50 -0700
Subject: [Rubygems-developers] [PATCH] gem unpack fails in gem isn't in
	the default repository
In-Reply-To: <1be7247c0801150748l2266ce3fy94857bf68bb89468@mail.gmail.com>
References: <1be7247c0801150748l2266ce3fy94857bf68bb89468@mail.gmail.com>
Message-ID: <1be7247c0804071738t64bba3b1tb61145bd16a1de13@mail.gmail.com>

Hi,

I completely forgot about this one but I just received a duplicate bug
report :)

Would it be possible to fix that in the upcoming release? I am pretty
sure it's a safe change.

Laurent

On Tue, Jan 15, 2008 at 8:48 AM, Laurent Sansonetti
<laurent.sansonetti at gmail.com> wrote:
> Hi,
>
>  Currently with trunk, gem unpack fails if you pass it a gem that isn't
>  in the default gems repository, but another repository.
>
>  It is the case in Mac OS X 10.5, where there are 2 repositories, but
>  all pre-installed gems being in the non-default one.
>
>  $ ruby -r rubygems -e "p Gem.dir, Gem.path"
>  "/Library/Ruby/Gems/1.8"
>  ["/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8",
>  "/Library/Ruby/Gems/1.8"]
>
>  $ gem unpack termios
>  ERROR:  While executing gem ... (Gem::Exception)
>     Cannot load gem at
>  [/Library/Ruby/Gems/1.8/cache/termios-0.9.4.gem] in /Volumes/Data
>
>  The following patch fixes the problem.
>
>  $ gem unpack termios
>  Unpacked gem: '/Volumes/Data/termios-0.9.4'
>
>  Laurent
>
>  Index: lib/rubygems/commands/unpack_command.rb
>  ===================================================================
>  --- lib/rubygems/commands/unpack_command.rb     (revision 1594)
>  +++ lib/rubygems/commands/unpack_command.rb     (working copy)
>  @@ -73,7 +73,7 @@
>      # Furthermore, the name match must be exact (ignoring case).
>      if gemname =~ /^#{selected.name}$/i
>        filename = selected.full_name + '.gem'
>  -      return File.join(Gem.dir, 'cache', filename)
>  +      return Gem.path.map { |d| File.join(d, 'cache', filename)
>  }.find { |p| File.exist?(p) }
>      else
>        return nil
>      end
>

From thewoolleyman at gmail.com  Mon Apr  7 21:14:50 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Mon, 7 Apr 2008 18:14:50 -0700
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FAB8A6.3030008@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<47FAB8A6.3030008@sun.com>
Message-ID: <e3af97510804071814u12ddb886ge34949a3122dfa25@mail.gmail.com>

On Mon, Apr 7, 2008 at 5:13 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Eric Hodel wrote:
>  > I'm willing to change the default in a future minor release (not
>  > 1.1.1), but primarily I think the problem is going to be user education.
>
>  Why not 1.1.1? This isn't a lot of effort, is it?

1.1.1 is already essentially frozen, and there are some caching bugs
in 1.1.0 that need to get fixed.  I'd rather not delay.

>  > Is there any particular reason why JRuby and Ruby can't use the same
>  > gem repository?  (Currently Rubinius does not, but after reading this
>  > thread, I think that may be a mistake).
>
>  No particular reason...it works, we just don't really recommend it. If
>  the automatic platform-gem-picking works seamlessly, it could certainly
>  be just fine...but I haven't had much chance to play with that
>  (especially installing the same gems into the same repository with the
>  same index and RubyGems knowing to install two different platform
>  versions of the same gem).

I'm not really famialiar with these Jruby issues, but from a high
level the single repository definitely seems like the proper solution.
 These are all essentially just different platforms, but they are all
RubyGems.  It is better to hide the complexity in the
platform-handling code of rubygems rather than expose the user to
confusing (and seemingly unresolvable?) issues with different
executables.  Less fragmentation in the standard ruby package
management tools and repositories is a Good Thing for the Ruby
community as a whole.

As for multiple platform support in RubyGems, I think that is fairly
solid already, and any bugs or deficiencies that are found can be
fixed.  I just fixed a bug yesterday in this area, which allows
multiplatform mswin-platform and compiled ruby gems of the same
version and name to be repeatedly installed and uninstalled on OSx as
part of my test suite.  I also have pretty thorough functional tests
in GemInstaller (ci.thewoolleyweb.com) which exercise RubyGems'
ability to handle multi-level, multiplatform dependency chains of
gems, and they all pass on Linux, Mac, and Windows.

-- Chad W.

From charles.nutter at sun.com  Mon Apr  7 22:24:59 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 21:24:59 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <e3af97510804071814u12ddb886ge34949a3122dfa25@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<47FAB8A6.3030008@sun.com>
	<e3af97510804071814u12ddb886ge34949a3122dfa25@mail.gmail.com>
Message-ID: <47FAD77B.7030806@sun.com>

Chad Woolley wrote:
> On Mon, Apr 7, 2008 at 5:13 PM, Charles Oliver Nutter
> <charles.nutter at sun.com> wrote:
>> Eric Hodel wrote:
>>  > I'm willing to change the default in a future minor release (not
>>  > 1.1.1), but primarily I think the problem is going to be user education.
>>
>>  Why not 1.1.1? This isn't a lot of effort, is it?
> 
> 1.1.1 is already essentially frozen, and there are some caching bugs
> in 1.1.0 that need to get fixed.  I'd rather not delay.
> 
>>  > Is there any particular reason why JRuby and Ruby can't use the same
>>  > gem repository?  (Currently Rubinius does not, but after reading this
>>  > thread, I think that may be a mistake).
>>
>>  No particular reason...it works, we just don't really recommend it. If
>>  the automatic platform-gem-picking works seamlessly, it could certainly
>>  be just fine...but I haven't had much chance to play with that
>>  (especially installing the same gems into the same repository with the
>>  same index and RubyGems knowing to install two different platform
>>  versions of the same gem).
> 
> I'm not really famialiar with these Jruby issues, but from a high
> level the single repository definitely seems like the proper solution.
>  These are all essentially just different platforms, but they are all
> RubyGems.  It is better to hide the complexity in the
> platform-handling code of rubygems rather than expose the user to
> confusing (and seemingly unresolvable?) issues with different
> executables.  Less fragmentation in the standard ruby package
> management tools and repositories is a Good Thing for the Ruby
> community as a whole.

I agree it would be useful, but I think it's just as useful to have it 
be separate. After all, it seems a little wierd to have JRuby hooked up 
to a repository that might contain gems it can't run and for which 
there's no equivalent port. But perhaps that's just me...I like to only 
have the gems installed I'm using, and frequently have a couple 
different JRuby instances to use for different purposes. But then again, 
I'm doing lots of demos and active JRuby dev...so there's a lot of churn.

At any rate, it ought to work fine, but the jgem thing seems to me 
totally unrelated. gem install should be gem install, whether on JRuby 
or MatzRuby.

- Charlie

From charles.nutter at sun.com  Mon Apr  7 23:13:20 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 07 Apr 2008 22:13:20 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <e3af97510804071814u12ddb886ge34949a3122dfa25@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<47FAB8A6.3030008@sun.com>
	<e3af97510804071814u12ddb886ge34949a3122dfa25@mail.gmail.com>
Message-ID: <47FAE2D0.5090200@sun.com>

Chad Woolley wrote:
> 1.1.1 is already essentially frozen, and there are some caching bugs
> in 1.1.0 that need to get fixed.  I'd rather not delay.

BTW, that's certainly fair. 1.1.2 perhaps? We can update JRuby to 
1.1/1.1.1 and manually make the change for now, so nobody gets bitten by it.

- Charlie

From stephen.bannasch at deanbrook.org  Tue Apr  8 00:04:50 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Tue, 8 Apr 2008 00:04:50 -0400
Subject: [Rubygems-developers] improved find_all_gem_commands.rb
Message-ID: <p0624081ac4201bb08359@[192.168.1.114]>

Now works on MacOS, Linux, and Windows -- finds all occurrences of 
any specific gem command for all paths in PATH.

improved, see: http://pastie.org/176659

Could perhaps be combined with other info from Gem.platforms, etc. to 
provide more intelligent multi-VM local Gem repository management.

Examples:

MacOS 10.5.2

   find_all_gem_commands
   => [{"ruby"=>"/usr/bin/gem"}, 
{"jruby"=>"/Users/stephen/dev/jruby_trunk/jruby/bin/gem"}]

   find_all_gem_commands('rails')
   => [{"ruby"=>"/usr/bin/rails"}, 
{"jruby"=>"/Users/stephen/dev/jruby_trunk/jruby/bin/rails"}]

Windows:

   find_all_gem_commands
   => [{"ruby.exe"=>"D:\\re\\ruby\\bin/gem"}, 
{"ruby.exe"=>"D:\\cygwin\\bin/gem"}, 
{"jruby"=>"D:\\work\\jruby-dev\\jruby\\bin/gem"}]


From stephen.bannasch at deanbrook.org  Tue Apr  8 00:05:00 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Tue, 8 Apr 2008 00:05:00 -0400
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
Message-ID: <p0624081fc42097477cb3@[192.168.1.114]>

At 3:19 PM -0700 4/7/08, Eric Hodel wrote:
>Is there any particular reason why JRuby and Ruby can't use the same 
>gem repository?  (Currently Rubinius does not, but after reading this 
>thread, I think that may be a mistake).
>
>AFAIK, RubyGems is smart enough to pick a JRuby-platform gem only for 
>JRuby, and will Just Work if both the JRuby and non-JRuby platform 
>gems are installed.

I'll normally want to keep separate local repositories but ...

If I use the same gem repository for MRI 1.8.6 and JRuby what should happen when I am working in JRuby and install a gem like Hpricot that would normally compile a native C library when installed under MRI.

Hpricot comes with compiled Java class files in a jar which are used if  RUBY_PLATFORM =~ /java/ so there is nothing special to compile when installing it in JRuby.

But the general case for this kind of gem could include Java compilation when installed in JRuby and native C compilation when installed in 1.8 or 1.9.

While you don't normally have to do distributed compilation of Java code there could be a benefit if there are differences in performance between different versions of Java.

So that begs the reverse question -- what should happen when I install a Gem under MRI that compiles a native C library but also should compile a native Java library if installed for JRuby.

What should MRI do when asked to install a Gem that only works on Java? As long as there is no native compilation this should still work ...

Perhaps the platform-specific install tasks could be lazy ...

Scenario: when installing a Gem with JRuby and MRI 1.8.x native installation tasks under MRI only he MRI 1.8.x tasks are performed. The first time the Gem is accessed from JRuby he JRuby install tasks are performed.


I don't know enough about how Rubinius or Ruby 1.9 work with gems to include them in these questions.

If one local repository could work with multiple Ruby VMs it would certainly be nice.

From thewoolleyman at gmail.com  Tue Apr  8 06:04:27 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 8 Apr 2008 03:04:27 -0700
Subject: [Rubygems-developers] what environment is required for extconf.rb
	to work?
Message-ID: <e3af97510804080304j315b6958q32e95a69af8eae10@mail.gmail.com>

I am having failures when building compiled gems as part of a
cruise.rb builder process.  Errors look like this:

  ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb

When I run extconf manually, though, it works.  I suspect this is due
to cruise not passing along some required environment info.

Any idea what this might be, or how I can get more debugging info?

Thanks,
-- Chad

From me at susanpotter.net  Tue Apr  8 15:56:39 2008
From: me at susanpotter.net (Susan Potter)
Date: Tue, 8 Apr 2008 14:56:39 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FABB82.2010404@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1076b0d90804071248v5a4cf2ebv87defd798c7951ae@mail.gmail.com>
	<47FABB82.2010404@sun.com>
Message-ID: <1076b0d90804081256o1fb6516bka08dd02cfd5b2adf@mail.gmail.com>

>  Note that the change to jgem was made intentionally (for unknown
>  reasons?) without ever talking to the JRuby team in the first place. And
>  we would have said "no, please don't do it." Your comment about "stop
>  using JRuby (yay!)" seems to show that you don't really care about
>  making things easier for JRuby users.
Please do tell me what *I* care about based on a comment simply
meaning I do not have the issues anymore that my former co-workers to.
 If this is a contest about which one of us is willing to stoop
lower....I am not interested in playing games.

From nicksieger at gmail.com  Tue Apr  8 16:51:27 2008
From: nicksieger at gmail.com (Nick Sieger)
Date: Tue, 8 Apr 2008 13:51:27 -0700
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
Message-ID: <f0b861390804081351h7b9ac097k96837853ec9e6648@mail.gmail.com>

On Mon, Apr 7, 2008 at 3:52 PM, Luis Lavena <luislavena at gmail.com> wrote:
>
>  PS: bikeshed?
>

Totally. The thing is, all this discussion is focused around JRuby,
but s/JRuby/Ruby 1.9/ and you still have the same problem. Just
sayin'.

/Nick

From drbrain at segment7.net  Tue Apr  8 17:21:26 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 8 Apr 2008 14:21:26 -0700
Subject: [Rubygems-developers] [PATCH] gem unpack fails in gem isn't in
	the default repository
In-Reply-To: <1be7247c0804071738t64bba3b1tb61145bd16a1de13@mail.gmail.com>
References: <1be7247c0801150748l2266ce3fy94857bf68bb89468@mail.gmail.com>
	<1be7247c0804071738t64bba3b1tb61145bd16a1de13@mail.gmail.com>
Message-ID: <D17999D7-CEF5-4F37-8687-30B4F702CD7D@segment7.net>

On Apr 7, 2008, at 17:38 PM, Laurent Sansonetti wrote:
> Hi,
>
> I completely forgot about this one but I just received a duplicate bug
> report :)
>
> Would it be possible to fix that in the upcoming release? I am pretty
> sure it's a safe change.

A similar change has been made.

From jim.weirich at gmail.com  Tue Apr  8 17:36:55 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Tue, 8 Apr 2008 17:36:55 -0400
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <f0b861390804081351h7b9ac097k96837853ec9e6648@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<f0b861390804081351h7b9ac097k96837853ec9e6648@mail.gmail.com>
Message-ID: <4C909BCD-9CA3-4654-A63A-C6F1E5F7CD94@gmail.com>


On Apr 8, 2008, at 4:51 PM, Nick Sieger wrote:
> On Mon, Apr 7, 2008 at 3:52 PM, Luis Lavena <luislavena at gmail.com>  
> wrote:
>>
>> PS: bikeshed?
>>
>
> Totally. The thing is, all this discussion is focused around JRuby,
> but s/JRuby/Ruby 1.9/ and you still have the same problem. Just
> sayin'.

Or Rubinius ... the jxxx naming convention is a stop-gap measure at  
best.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From luislavena at gmail.com  Tue Apr  8 17:46:53 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 8 Apr 2008 18:46:53 -0300
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <4C909BCD-9CA3-4654-A63A-C6F1E5F7CD94@gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<f0b861390804081351h7b9ac097k96837853ec9e6648@mail.gmail.com>
	<4C909BCD-9CA3-4654-A63A-C6F1E5F7CD94@gmail.com>
Message-ID: <71166b3b0804081446k4c59e46au9c220e8bc3469f7b@mail.gmail.com>

On Tue, Apr 8, 2008 at 6:36 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
>  Or Rubinius ... the jxxx naming convention is a stop-gap measure at
>  best.
>

jruby -S gem install bikeshed

For those who didn't noticed: the command line explicitly tell you:
dude, you're using jruby here, ok?

-- 
Luis Lavena
Multimedia systems
-
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 stephen.bannasch at deanbrook.org  Tue Apr  8 22:55:46 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Tue, 8 Apr 2008 22:55:46 -0400
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804081446k4c59e46au9c220e8bc3469f7b@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<f0b861390804081351h7b9ac097k96837853ec9e6648@mail.gmail.com>
	<4C909BCD-9CA3-4654-A63A-C6F1E5F7CD94@gmail.com>
	<71166b3b0804081446k4c59e46au9c220e8bc3469f7b@mail.gmail.com>
Message-ID: <p06240827c421dc7e4606@[192.168.1.114]>

At 6:46 PM -0300 4/8/08, Luis Lavena wrote:
>On Tue, Apr 8, 2008 at 6:36 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>>
>>  Or Rubinius ... the jxxx naming convention is a stop-gap measure at
>>  best.
>>
>
>jruby -S gem install bikeshed
>
>For those who didn't noticed: the command line explicitly tell you:
>dude, you're using jruby here, ok?

While this thread started about renaming gem to jgem for jruby it quickly became a more general thread on whether it makes sense to rename gem at all and whether local gem repositories can be or even should be shared.

I assumed Jim was referring more generally to the renaming of the installed gem based on the name of the installed ruby

For example here's some of the possible new names for 'gem':

%w{ruby jruby rubinius rbx ruby1.9 ironruby}.collect {|ruby_name| Gem::ConfigMap[:RUBY_INSTALL_NAME]=ruby_name; Gem.default_exec_format % "gem"}

=> ["gem", "jgem", "rubinius", "rbx", "gem1.9", "irongem"]

see: defaults.rb:

# Deduce Ruby's --program-prefix and --program-suffix from its install name.
def self.default_exec_format
  baseruby = ConfigMap[:BASERUBY] || 'ruby'
  ConfigMap[:RUBY_INSTALL_NAME].sub(baseruby, '%s') rescue '%s'
end

From ryand-ruby at zenspider.com  Wed Apr  9 21:24:24 2008
From: ryand-ruby at zenspider.com (Ryan Davis)
Date: Wed, 9 Apr 2008 18:24:24 -0700
Subject: [Rubygems-developers] improved find_all_gem_commands.rb
In-Reply-To: <p0624081ac4201bb08359@[192.168.1.114]>
References: <p0624081ac4201bb08359@[192.168.1.114]>
Message-ID: <5AD4D3D0-4D2B-4877-8B5B-007692B1BCA5@zenspider.com>


On Apr 7, 2008, at 21:04 , Stephen Bannasch wrote:
> improved, see: http://pastie.org/176659

I'm confused... improved upon what?


From stephen.bannasch at deanbrook.org  Wed Apr  9 23:49:34 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Wed, 9 Apr 2008 23:49:34 -0400
Subject: [Rubygems-developers] improved find_all_gem_commands.rb
In-Reply-To: <5AD4D3D0-4D2B-4877-8B5B-007692B1BCA5@zenspider.com>
References: <p0624081ac4201bb08359@[192.168.1.114]>
	<5AD4D3D0-4D2B-4877-8B5B-007692B1BCA5@zenspider.com>
Message-ID: <p06240800c4233b38a35e@[192.168.1.114]>

>On Apr 7, 2008, at 21:04 , Stephen Bannasch wrote:
>> improved, see: http://pastie.org/176659
>
>I'm confused... improved upon what?

On the previous example I posted previously. See this posting in the middle of a long meandering thread:

http://rubyforge.org/pipermail/rubygems-developers/2008-April/003697.html

This code is not useful by itself. It is possible it could be useful as part of a larger effort for rubygems to help users deal better with the issues of local gem repositories when used with multiple ruby VMs.

Instead of spending the time writing a paragraph about what could be done I wrote a paragraph of code to share the idea.

At least for the near-term future when alternate ruby VMs are installed (ruby1.9, jruby, rubinuis) they should have separate local gem repositories lib and binary paths.

However currently the installation mechanisms for the alternate ruby VMs don't make this a simple or obvious choice. Users who are not careful can screw up their local gem repositories by installing a Gem that tries and fails to install a native C librarie when they are running JRuby. When users start getting into this kind of trouble the data produced by this method 'could' be useful to warn someone -- but I haven't thought the rest of this through yet.

From drbrain at segment7.net  Thu Apr 10 16:47:37 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 10 Apr 2008 13:47:37 -0700
Subject: [Rubygems-developers] what environment is required for
	extconf.rb to work?
In-Reply-To: <e3af97510804080304j315b6958q32e95a69af8eae10@mail.gmail.com>
References: <e3af97510804080304j315b6958q32e95a69af8eae10@mail.gmail.com>
Message-ID: <AA242F16-71B7-453E-A97F-BE8DB4A46697@segment7.net>

On Apr 8, 2008, at 03:04 AM, Chad Woolley wrote:
> I am having failures when building compiled gems as part of a
> cruise.rb builder process.  Errors look like this:
>
>  ERROR: Failed to build gem native extension. /usr/local/bin/ruby  
> extconf.rb
>
> When I run extconf manually, though, it works.  I suspect this is due
> to cruise not passing along some required environment info.
>
> Any idea what this might be, or how I can get more debugging info?

Does the cruise.rb run as a daemon with a restricted environment?  My  
best guess is that it may depend on some LD_* environment variables  
that don't get set/are removed when run through cruiser.rb.

From drbrain at segment7.net  Thu Apr 10 17:19:27 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 10 Apr 2008 14:19:27 -0700
Subject: [Rubygems-developers] RubyGems 1.1.1 tonight
Message-ID: <86E16888-86C0-4317-B0B6-6565174B470F@segment7.net>

If there are no objections, I'll release RubyGems 1.1.1 later tonight  
(Pacific Time).

From drbrain at segment7.net  Thu Apr 10 17:33:21 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 10 Apr 2008 14:33:21 -0700
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FAB8A6.3030008@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<47FAB8A6.3030008@sun.com>
Message-ID: <DD5A339A-38E9-412D-8132-FCE094255D59@segment7.net>

On Apr 7, 2008, at 17:13 PM, Charles Oliver Nutter wrote:
> Eric Hodel wrote:
>> I'm willing to change the default in a future minor release (not
>> 1.1.1), but primarily I think the problem is going to be user  
>> education.
>
> Why not 1.1.1? This isn't a lot of effort, is it? And we're already
> modifying our built-in install of RubyGems to use 'gem', so it's
> actually the jgem that's confusing people. I think this should go  
> out in
> 1.1.1.

Because the third . is a bugfix release, and this is a difference of  
opinion, not a bug.

From luislavena at gmail.com  Thu Apr 10 18:59:45 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 10 Apr 2008 19:59:45 -0300
Subject: [Rubygems-developers] what environment is required for
	extconf.rb to work?
In-Reply-To: <e3af97510804080304j315b6958q32e95a69af8eae10@mail.gmail.com>
References: <e3af97510804080304j315b6958q32e95a69af8eae10@mail.gmail.com>
Message-ID: <71166b3b0804101559v5ba576bdsa8fffd881bc5cbe@mail.gmail.com>

On Tue, Apr 8, 2008 at 7:04 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> I am having failures when building compiled gems as part of a
>  cruise.rb builder process.  Errors look like this:
>
>   ERROR: Failed to build gem native extension. /usr/local/bin/ruby extconf.rb
>
>  When I run extconf manually, though, it works.  I suspect this is due
>  to cruise not passing along some required environment info.
>
>  Any idea what this might be, or how I can get more debugging info?
>

The builders of CC.rb are being launched externally or run inside the
dashboard (rails) process? If so, you need to check if the user used
by the daemonize process have access to that stuff (www or something
like that).

I ended splitting these two, fire the builders manually and the
dashboard with -w (without-builders param).

HTH,
-- 
Luis Lavena
Multimedia systems
-
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  Thu Apr 10 19:06:15 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 10 Apr 2008 20:06:15 -0300
Subject: [Rubygems-developers] RubyGems 1.1.1 tonight
In-Reply-To: <86E16888-86C0-4317-B0B6-6565174B470F@segment7.net>
References: <86E16888-86C0-4317-B0B6-6565174B470F@segment7.net>
Message-ID: <71166b3b0804101606s1b2abf35oa205b877b5e2428f@mail.gmail.com>

On Thu, Apr 10, 2008 at 6:19 PM, Eric Hodel <drbrain at segment7.net> wrote:
> If there are no objections, I'll release RubyGems 1.1.1 later tonight
>  (Pacific Time).

None from my side, been using svn trunk for the past days without issues.

Both builds (mswin32 and mingw32) ended without glitches here, but
want to hear back from Chad about GemInstaller integration process.

Chad?
-- 
Luis Lavena
Multimedia systems
-
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 Apr 10 22:44:39 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 10 Apr 2008 19:44:39 -0700
Subject: [Rubygems-developers] RubyGems 1.1.1 tonight
In-Reply-To: <71166b3b0804101606s1b2abf35oa205b877b5e2428f@mail.gmail.com>
References: <86E16888-86C0-4317-B0B6-6565174B470F@segment7.net>
	<71166b3b0804101606s1b2abf35oa205b877b5e2428f@mail.gmail.com>
Message-ID: <e3af97510804101944g7a84a20q7a666a0a5e32a166@mail.gmail.com>

On Thu, Apr 10, 2008 at 4:06 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Thu, Apr 10, 2008 at 6:19 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  > If there are no objections, I'll release RubyGems 1.1.1 later tonight
>  >  (Pacific Time).
>
>  None from my side, been using svn trunk for the past days without issues.
>
>  Both builds (mswin32 and mingw32) ended without glitches here, but
>  want to hear back from Chad about GemInstaller integration process.
>
>  Chad?

My tests are green against trunk, do it!

From charles.nutter at sun.com  Fri Apr 11 14:53:29 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Fri, 11 Apr 2008 13:53:29 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <DD5A339A-38E9-412D-8132-FCE094255D59@segment7.net>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<47FAB8A6.3030008@sun.com>
	<DD5A339A-38E9-412D-8132-FCE094255D59@segment7.net>
Message-ID: <47FFB3A9.20805@sun.com>

Eric Hodel wrote:
> On Apr 7, 2008, at 17:13 PM, Charles Oliver Nutter wrote:
>> Eric Hodel wrote:
>>> I'm willing to change the default in a future minor release (not
>>> 1.1.1), but primarily I think the problem is going to be user  
>>> education.
>> Why not 1.1.1? This isn't a lot of effort, is it? And we're already
>> modifying our built-in install of RubyGems to use 'gem', so it's
>> actually the jgem that's confusing people. I think this should go  
>> out in
>> 1.1.1.
> 
> Because the third . is a bugfix release, and this is a difference of  
> opinion, not a bug.

I consider it a bug, since it breaks running "gem install something" on 
JRuby :)

- Charlie

From charles.nutter at sun.com  Fri Apr 11 15:03:08 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Fri, 11 Apr 2008 14:03:08 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
Message-ID: <47FFB5EC.4060506@sun.com>

Luis Lavena wrote:
> PS: bikeshed?

I'm getting really tired of people calling bikeshed on discussions just 
because there's a difference of opinion not getting resolved. It is NOT 
a bikeshed for us to want "jgem" changed back to "gem" since it directly 
affects JRuby users and we never asked for it to happen. We've run and 
shipped RubyGems with JRuby for two years, always with the 'gem' command.

The 'jgem' command name causes the following problems:

- If people install RubyGems manually into JRuby, walkthroughs, 
tutorials, and scripts that expect the 'gem' command to exist will fail 
to work.
- If people update JRuby, they'll have an old 'gem' command (the one we 
ship) alongside the newer 'jgem' command (installed by RubyGems).

It should be changed back to 'gem' and if there are discussions to be 
had about how to avoid collisions or about how to share gem stores then 
those discussions should include the implementers, rather than being 
done in a vacuum and forced upon them.

As a representative of the JRuby implementers, *I do not want it to be 
'jgem'*. Please change it back to 'gem' for JRuby installs.

- Charlie

From charles.nutter at sun.com  Fri Apr 11 15:42:50 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Fri, 11 Apr 2008 14:42:50 -0500
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FFB5EC.4060506@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<47FFB5EC.4060506@sun.com>
Message-ID: <47FFBF3A.1070303@sun.com>

Charles Oliver Nutter wrote:
> As a representative of the JRuby implementers, *I do not want it to be 
> 'jgem'*. Please change it back to 'gem' for JRuby installs.

Hey, we've been discussing on the JRuby IRC channel a bit and I think 
there's a compromise we could reach here.

Our issue is that we want "gem" to work to install gems as it always has.

The 'jgem' fix is designed to provide a specific name for JRuby (and 
other names for other impls) to allow you to know which impl you're 
installing gems against.

When RubyGems updates now, the problem is that it both installs a 'jgem' 
script and recommends that the 'gem' script be removed. That violates 
our desire to have 'gem' always work, but it's not directly because of 
'jgem' existing.

So one possible solution seems to be for us to make our 'gem' script 
just point at/invoke 'jgem', and for rubygems to not recommend removing 
the 'gem' script. Then we can have our 'gem' script forever, RubyGems 
updating 'jgem' will still work correctly, and people that want to use 
'jgem' can still do so.

Action items:

JRuby: make 'gem' script just invoke 'jgem' script
RubyGems: disable the recommendation to delete the 'gem' script

Thoughts?

- Charlie

From luislavena at gmail.com  Fri Apr 11 17:35:46 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 11 Apr 2008 18:35:46 -0300
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FFB5EC.4060506@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<47FFB5EC.4060506@sun.com>
Message-ID: <71166b3b0804111435x2b24dfc3odf1924623f07a857@mail.gmail.com>

On Fri, Apr 11, 2008 at 4:03 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> Luis Lavena wrote:
>  > PS: bikeshed?
>
>  I'm getting really tired of people calling bikeshed on discussions just
>  because there's a difference of opinion not getting resolved. It is NOT
>  a bikeshed for us to want "jgem" changed back to "gem" since it directly
>  affects JRuby users and we never asked for it to happen. We've run and
>  shipped RubyGems with JRuby for two years, always with the 'gem' command.
>

You aren't the only one that get tired of starting discussion on
topics that end with things like "mine is better than yours"... and
start a manhood competition...

>  The 'jgem' command name causes the following problems:
>
>  - If people install RubyGems manually into JRuby, walkthroughs,
>  tutorials, and scripts that expect the 'gem' command to exist will fail
>  to work.
>  - If people update JRuby, they'll have an old 'gem' command (the one we
>  ship) alongside the newer 'jgem' command (installed by RubyGems).
>

On lot of references I see 'jruby -S gem' or 'jruby -S rake' ... none
of them explicitly indicates "gem" rake or any other script.

Why? because most of the time gem, rake and the wrappers stubs clash
with MRI ruby installation (take in consideration FHS/*nix
installation, where files got installed In /usr/bin or things like
that, not Windows).

I personally have no trouble with JRuby implementation of gem being
called gem, jgem or awesome_gem, what will really annoys me is start
getting huge amount of support tickets and mails about NetBeans
bundled jRuby interfering with MRI ruby installation, and blaming
mongrel, one-click installer or any other thing I do.

I just said bikeshed since we keep discussing about it, but we don't
get to something that provide real value (37 mails can indicate that).

>  It should be changed back to 'gem' and if there are discussions to be
>  had about how to avoid collisions or about how to share gem stores then
>  those discussions should include the implementers, rather than being
>  done in a vacuum and forced upon them.
>

Until out patches got accepted in RubyGems, we used to replace the
generated stub scripts gem creates with our own set of batch files.

I'll better suggest leave rubygem executable as 'gem', and state it
clearly when it runs, the ruby and rubygems version and platform
implementation.

>  As a representative of the JRuby implementers, *I do not want it to be
>  'jgem'*. Please change it back to 'gem' for JRuby installs.
>

/me talking as the dumb and stubborn One-Click Installer maintainer.

-- 
Luis Lavena
Multimedia systems
-
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 stephen.bannasch at deanbrook.org  Fri Apr 11 17:40:34 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Fri, 11 Apr 2008 17:40:34 -0400
Subject: [Rubygems-developers] Questions on 1.0.0 on JRuby
In-Reply-To: <47FFBF3A.1070303@sun.com>
References: <476AFBB5.1090604@sun.com> <47FA3D96.1020103@sun.com>
	<71166b3b0804070903s60194d82me1327e0c207a3cf4@mail.gmail.com>
	<47FA5EA7.5030302@sun.com>
	<1F990242-4837-49ED-903F-1F844BED16F7@segment7.net>
	<71166b3b0804071552r736c2376s1454e5d3636f722b@mail.gmail.com>
	<47FFB5EC.4060506@sun.com> <47FFBF3A.1070303@sun.com>
Message-ID: <p06240804c42586607ae7@[63.138.152.170]>

At 2:42 PM -0500 4/11/08, Charles Oliver Nutter wrote:
>Charles Oliver Nutter wrote:
>> As a representative of the JRuby implementers, *I do not want it to be
>> 'jgem'*. Please change it back to 'gem' for JRuby installs.
>
>Hey, we've been discussing on the JRuby IRC channel a bit and I think
>there's a compromise we could reach here.
>
>Our issue is that we want "gem" to work to install gems as it always has.
>
>The 'jgem' fix is designed to provide a specific name for JRuby (and
>other names for other impls) to allow you to know which impl you're
>installing gems against.
>
>When RubyGems updates now, the problem is that it both installs a 'jgem'
>script and recommends that the 'gem' script be removed. That violates
>our desire to have 'gem' always work, but it's not directly because of
>'jgem' existing.
>
>So one possible solution seems to be for us to make our 'gem' script
>just point at/invoke 'jgem', and for rubygems to not recommend removing
>the 'gem' script. Then we can have our 'gem' script forever, RubyGems
>updating 'jgem' will still work correctly, and people that want to use
>'jgem' can still do so.
>
>Action items:
>
>JRuby: make 'gem' script just invoke 'jgem' script
>RubyGems: disable the recommendation to delete the 'gem' script
>
>Thoughts?

My suggestion below is based on the initial assumption that jruby (as an alternate ruby VM) is installed in a manner in which there are separate lib gem and bin directories from the standard system Ruby. In addition IF a path to JRUBY_HOME/bin is put on the PATH env variable it is only put after a path reference to any system Ruby and it's associated system bin/ directory.

I haven't seen evidence that any other install strategy for an alternate Ruby VM will work. Nobody has yet described how a shared gem repository could work reliably when native code is involved under the current implementations.

It is the responsibility of JRuby (and packagers of JRuby) to make this separation of gem, bin, and lib directories from any other installed Ruby VM the likely outcome of various install processes.

Assuming an install as described above I suggest keeping the installed gem command as 'gem' for all alternate Ruby VMs and possibly adding a jgem command to the standard system location for bin commands. The jgem command would execute:

  /path/to/jruby/bin/jruby -S gem

This way anytime you are expecting to be using MRI (or another standard system Ruby VM) typing gem will do what you expect.

To run the JRuby gem you can type:

  jgem

OR if you have added JRUBY_HOME/bin to your path you can also type:

  jruby -S gem

If my conclusion about keeping separate gem, bin, and lib directories is correct for alternate Ruby VMs AND the actual installation of multiple Ruby VMs on multiple platforms can be introspected in a reliable way THEN it **might** be useful for RubyGems to refuse to upgrade itself or install a gem in a mixed repository without using some type of --force parameter.

From thewoolleyman at gmail.com  Sat Apr 12 18:03:13 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 12 Apr 2008 15:03:13 -0700
Subject: [Rubygems-developers] Gem uninstall not working on windows w/1.1.1?
Message-ID: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>

Haven't tried to debug this.  I can provide more info if it is not reproducible:

C:\>gem --version
1.1.1

C:\>gem list mongrel

*** LOCAL GEMS ***

mongrel (1.0.1)

C:\>gem uninstall mongrel
INFO:  In order to remove mongrel, please execute:
        gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8

C:\>gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8
INFO:  In order to remove mongrel, please execute:
        gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8

From luislavena at gmail.com  Sun Apr 13 00:18:06 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 13 Apr 2008 01:18:06 -0300
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
Message-ID: <71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>

On Sat, Apr 12, 2008 at 7:03 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Haven't tried to debug this.  I can provide more info if it is not reproducible:
>
>  C:\>gem --version
>  1.1.1
>
>  C:\>gem list mongrel
>
>  *** LOCAL GEMS ***
>
>  mongrel (1.0.1)
>
>  C:\>gem uninstall mongrel
>  INFO:  In order to remove mongrel, please execute:
>         gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8
>
>  C:\>gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8
>  INFO:  In order to remove mongrel, please execute:
>         gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8


Could reproduce this:

RubyGems Environment:
  - RUBYGEMS VERSION: 1.1.1
  - RUBY VERSION: 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]
  - INSTALLATION DIRECTORY:
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-111/lib/ruby/gems/1.8
  - RUBY EXECUTABLE:
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-111/bin/ruby.exe
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mswin32-60
  - GEM PATHS:
     - D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-111/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org


gem list mongrel

*** LOCAL GEMS ***

mongrel (1.1.4)

gem uninstall mongrel

uccessfully uninstalled mongrel-1.1.4-x86-mswin32-60
Remove executables:
        mongrel_rails

in addition to the gem? [Yn]
Removing mongrel_rails

====

Maybe there is something in GEM_HOME or GEM_PATH affecting your results?

-- 
Luis Lavena
Multimedia systems
-
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  Sun Apr 13 00:47:34 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sat, 12 Apr 2008 21:47:34 -0700
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
	<71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
Message-ID: <e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>

Here is my gem env:

C:\>gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.1.1
  - RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
  - INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mswin32-60
  - GEM PATHS:
     - c:/ruby/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org

From luislavena at gmail.com  Sun Apr 13 01:00:00 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 13 Apr 2008 02:00:00 -0300
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
	<71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
	<e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>
Message-ID: <71166b3b0804122200l150b9174l751fa441c9dc6734@mail.gmail.com>

On Sun, Apr 13, 2008 at 1:47 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Here is my gem env:
>

On my previous mail I meant to say "couldn't reproduce"...

Can you tell me if the mongrel gem is pre-1.x ?

Please check the path and directory name the gem got installed.

gem which mongrel

Regards,
-- 
Luis Lavena
Multimedia systems
-
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  Sun Apr 13 06:55:26 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 13 Apr 2008 03:55:26 -0700
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <71166b3b0804122200l150b9174l751fa441c9dc6734@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
	<71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
	<e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>
	<71166b3b0804122200l150b9174l751fa441c9dc6734@mail.gmail.com>
Message-ID: <e3af97510804130355n701c6c9cy7ce8d78de515a517@mail.gmail.com>

On Sat, Apr 12, 2008 at 10:00 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  Can you tell me if the mongrel gem is pre-1.x ?
>
>  Please check the path and directory name the gem got installed.
>
>  gem which mongrel

OK.  Here is the --debug output from uninstall as well.

I suspect this is because I've been reinstalling different old
versions of RubyGems back through 0.8.11, and something bad got left
over.  I'm just going to blow it away and reinstall.  If you want, I
can zip up my ruby dir and let you look at it first.

C:\>gem which mongrel
(checking gem mongrel-1.0.1-x86-mswin32 for mongrel)
c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/lib/mongrel.rb

C:\>gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8 --debug
Exception `NameError' at
c:/ruby/lib/ruby/site_ruby/1.8/rubygems/command_manager.rb:133 -
uninitialized constant Gem::Commands::Un
installCommand
Exception `Gem::GemNotInHomeException' at
c:/ruby/lib/ruby/site_ruby/1.8/rubygems/uninstaller.rb:142 - Gem is
not installed in dir
ectory c:/ruby/lib/ruby/gems/1.8
INFO:  In order to remove mongrel, please execute:
        gem uninstall mongrel --install-dir=c:/ruby/lib/ruby/gems/1.8

From luislavena at gmail.com  Sun Apr 13 07:24:13 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 13 Apr 2008 08:24:13 -0300
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <e3af97510804130355n701c6c9cy7ce8d78de515a517@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
	<71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
	<e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>
	<71166b3b0804122200l150b9174l751fa441c9dc6734@mail.gmail.com>
	<e3af97510804130355n701c6c9cy7ce8d78de515a517@mail.gmail.com>
Message-ID: <71166b3b0804130424y381a5825sce21a100827131eb@mail.gmail.com>

On Sun, Apr 13, 2008 at 7:55 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Sat, Apr 12, 2008 at 10:00 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  Can you tell me if the mongrel gem is pre-1.x ?
>  >
>  >  Please check the path and directory name the gem got installed.
>  >
>  >  gem which mongrel
>
>  OK.  Here is the --debug output from uninstall as well.
>
>  I suspect this is because I've been reinstalling different old
>  versions of RubyGems back through 0.8.11, and something bad got left
>  over.  I'm just going to blow it away and reinstall.  If you want, I
>  can zip up my ruby dir and let you look at it first.
>

Please, send me a 7zip directly so I can check what is interfering there.

>  C:\>gem which mongrel
>  (checking gem mongrel-1.0.1-x86-mswin32 for mongrel)
>  c:/ruby/lib/ruby/gems/1.8/gems/mongrel-1.0.1-mswin32/lib/mongrel.rb

(maybe is older platform, as I can see from your output).

Thank you.

-- 
Luis Lavena
Multimedia systems
-
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  Sun Apr 13 08:47:18 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Sun, 13 Apr 2008 05:47:18 -0700
Subject: [Rubygems-developers] Gem uninstall not working on windows
	w/1.1.1?
In-Reply-To: <71166b3b0804130424y381a5825sce21a100827131eb@mail.gmail.com>
References: <e3af97510804121503r1a4f0a59r6f752e68af2a2803@mail.gmail.com>
	<71166b3b0804122118n3e0d1d48i9e4b66c67b0a7152@mail.gmail.com>
	<e3af97510804122147s749a58a2w3e50402308bec25f@mail.gmail.com>
	<71166b3b0804122200l150b9174l751fa441c9dc6734@mail.gmail.com>
	<e3af97510804130355n701c6c9cy7ce8d78de515a517@mail.gmail.com>
	<71166b3b0804130424y381a5825sce21a100827131eb@mail.gmail.com>
Message-ID: <e3af97510804130547l8b6de25hd59fcac20736026b@mail.gmail.com>

On Sun, Apr 13, 2008 at 4:24 AM, Luis Lavena <luislavena at gmail.com> wrote:
>  Please, send me a 7zip directly so I can check what is interfering there.

OK, I'll arrange it with you off list.  Thanks.

From builder at mmediasys.com  Tue Apr 15 15:15:44 2008
From: builder at mmediasys.com (Integration Builder)
Date: Tue, 15 Apr 2008 16:15:44 -0300
Subject: [Rubygems-developers] [CruiseControl] rubygems-mswin32 build 1704.1
	fixed
Message-ID: <4804fee035390_fb813de3a61ae@edicion01.tmail>

The build has been fixed.

  Note: if you set Configuration.dashboard_url in config/site_config.rb, you'd see a link to the build page here.

CHANGES
-------
New revision 1704 detected
Revision 1704 committed by drbrain on 2008-04-15 00:40:42
Add Gem::RemoteFetcher::fetcher= with lib/rubygems/test_utilities.rb
  A /trunk/lib/rubygems/test_utilities.rb
  M /trunk/test/test_gem_dependency_installer.rb
  M /trunk/test/test_gem_remote_fetcher.rb
  M /trunk/test/gemutilities.rb
  M /trunk/test/test_gem_commands_sources_command.rb
Revision 1703 committed by drbrain on 2008-04-14 23:59:58
Expose FakeFetcher, TempIO via rubygems/test_utilities.rb

  M /trunk/test/test_gem_dependency_installer.rb
  M /trunk/test/gemutilities.rb
  M /trunk/ChangeLog



BUILD LOG
---------
D:/Users/Luis/.cruise/projects/rubygems-mswin32/work Luis$ ruby -e "require 'rubygems' rescue nil; require 'rake'; load 'D:/Users/Luis/tools/ccrb/tasks/cc_build.rake'; ARGV << '--nosearch' << 'cc:build'; Rake.application.run; ARGV.clear"  
(in D:/Users/Luis/.cruise/projects/rubygems-mswin32/work)
[CruiseControl] Invoking Rake task "test"
Loaded suite D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader
Started
...............................................................D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/openssl/x509.rb:24: warning: instance variable @config not initialized
................................D:/Users/Luis/ruby/ruby-186-p114-VC6-rubygems-110/lib/ruby/1.8/rdoc/parsers/parse_c.rb:204: warning: method redefined; discarding old progress
...WARNING:  Unable to use symlinks on Windows, installing wrapper
.WARNING:  Unable to use symlinks on Windows, installing wrapper
.WARNING:  Unable to use symlinks on Windows, installing wrapper
..............................................................WARNING:  Unable to use symlinks on Windows, installing wrapper
.............WARNING:  Unable to use symlinks on Windows, installing wrapper
..WARNING:  Unable to use symlinks on Windows, installing wrapper
................................................................................................................................................................................................................................................................................................................................................................................................................................
Finished in 59.188 seconds.

593 tests, 1771 assertions, 0 failures, 0 errors


PROJECT SETTINGS
----------------
# Project-specific configuration for CruiseControl.rb

Project.configure do |project|
  
  project.email_notifier.emails = ['rubygems-developers at rubyforge.org', 'rubyinstaller-devel at rubyforge.org']
  
  project.scheduler.polling_interval = 5.minutes

end


From avatar at spellboundnet.com  Wed Apr 16 22:05:01 2008
From: avatar at spellboundnet.com (Donavan Pantke)
Date: Wed, 16 Apr 2008 22:05:01 -0400
Subject: [Rubygems-developers] Gem autoloading problems
Message-ID: <200804162205.01918.avatar@spellboundnet.com>

So, we were messing around with Passenger for rails recently, and ran into 
some behavior that I think needs to be addressed, but I'm not sure how.

Gems, I think as of 1.0, automatically activates a gem's dependencies based on 
what its spec says. However, the gem itself has no control over this. This 
makes life really hard on systems that need specific handling. In the case of 
Passenger, the rails gem is loaded based on the version requested, and more 
than one can be loaded (the process forks before rails gets loaded, allowing 
multiple versions to be in memory and accessible). However, if the gemspec 
has rails in it, activating passenger means that rails automatically gets 
activated, and so any further rails activation with a different version 
fails. However, the gemspec is entirely correct in that it needs 
_some_version of rails, but it really needs to do the activating of the 
dependency itself.

The first question I have is, what mechanism can be made available to avert 
activating a dependent gem until the gem actually needs it?

The next, bigger question IMO is, what should be the default? I can think of 
code paths where loading by default would make it really difficult for people 
needing deferred loading, but I may be overestimating the scope. 

So what do you guys think? I can help to write up the code, but I wanted input 
on what to write. :)

Thanks!
Donavan

From avatar at spellboundnet.com  Wed Apr 16 23:11:36 2008
From: avatar at spellboundnet.com (Donavan Pantke)
Date: Wed, 16 Apr 2008 23:11:36 -0400
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <200804162205.01918.avatar@spellboundnet.com>
References: <200804162205.01918.avatar@spellboundnet.com>
Message-ID: <200804162311.36356.avatar@spellboundnet.com>

On Wednesday 16 April 2008 10:05:01 pm Donavan Pantke wrote:
> So, we were messing around with Passenger for rails recently, and ran into 
> some behavior that I think needs to be addressed, but I'm not sure how.
> 
> Gems, I think as of 1.0, automatically activates a gem's dependencies based 
on 
> what its spec says. However, the gem itself has no control over this. This 
> makes life really hard on systems that need specific handling. In the case 
of 
> Passenger, the rails gem is loaded based on the version requested, and more 
> than one can be loaded (the process forks before rails gets loaded, allowing 
> multiple versions to be in memory and accessible). However, if the gemspec 
> has rails in it, activating passenger means that rails automatically gets 
> activated, and so any further rails activation with a different version 
> fails. However, the gemspec is entirely correct in that it needs 
> _some_version of rails, but it really needs to do the activating of the 
> dependency itself.
> 
> The first question I have is, what mechanism can be made available to avert 
> activating a dependent gem until the gem actually needs it?

I took a look back, and prior RubyGems had an autorequire option, that was 
false by default. However, this behavior is not only true by default, but 
there's no longer even a way of disabling it.

I'm thinking that given the new codebase, the best way of carrying forward 
this behavior is by extending Gem::Dependency and add_dependency to allow for 
disabling autoloading. This way the developer could control autoloading on a 
per-dependency basis. This handles especially well the case where a gem has 
to turn off certain dependencies, but more often than not autoloading is 
fine.

 
> 
> The next, bigger question IMO is, what should be the default? I can think of 
> code paths where loading by default would make it really difficult for 
people 
> needing deferred loading, but I may be overestimating the scope. 
> 
> So what do you guys think? I can help to write up the code, but I wanted 
input 
> on what to write. :)
> 

Thanks!
Donavan


From drbrain at segment7.net  Thu Apr 17 23:23:47 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Thu, 17 Apr 2008 20:23:47 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <200804162311.36356.avatar@spellboundnet.com>
References: <200804162205.01918.avatar@spellboundnet.com>
	<200804162311.36356.avatar@spellboundnet.com>
Message-ID: <8FB88458-E8A9-403D-9AB3-55F86E6DB93D@segment7.net>

On Apr 16, 2008, at 20:11 PM, Donavan Pantke wrote:
> On Wednesday 16 April 2008 10:05:01 pm Donavan Pantke wrote:
>> So, we were messing around with Passenger for rails recently, and  
>> ran into
>> some behavior that I think needs to be addressed, but I'm not sure  
>> how.
>>
>> Gems, I think as of 1.0, automatically activates a gem's  
>> dependencies based
>> on what its spec says.

AFAIK, this has always been true.  I checked back to 0.9.0 as that's  
the oldest tag I have checked out.

>> However, the gem itself has no control over this. This
>> makes life really hard on systems that need specific handling. In  
>> the case
>> of Passenger, the rails gem is loaded based on the version  
>> requested, and more
>> than one can be loaded (the process forks before rails gets loaded,  
>> allowing
>> multiple versions to be in memory and accessible). However, if the  
>> gemspec
>> has rails in it, activating passenger means that rails  
>> automatically gets
>> activated, and so any further rails activation with a different  
>> version
>> fails. However, the gemspec is entirely correct in that it needs
>> _some_version of rails, but it really needs to do the activating of  
>> the
>> dependency itself.

Can it not fork and exec if it is going through the setup of Rails for  
each child anyway?

>> The first question I have is, what mechanism can be made available  
>> to avert
>> activating a dependent gem until the gem actually needs it?
>
> I took a look back, and prior RubyGems had an autorequire option,  
> that was
> false by default. However, this behavior is not only true by  
> default, but
> there's no longer even a way of disabling it.

autorequire is a separate feature from before RubyGems hooking into  
Kernel#require.  It has nothing to do with activation of dependencies.

> I'm thinking that given the new codebase, the best way of carrying  
> forward
> this behavior is by extending Gem::Dependency and add_dependency to  
> allow for
> disabling autoloading.

Even with such a feature it is too easy to run into the same problem.

Given gems a-1, a-2 and b-1 that depends on any version of a, and a/ 
some_file.rb existing in both versions of gem a.

In b/some_file.rb:

require 'a/some_file'

In myapp.rb:

gem_but_not_dependencies 'b'

# at this point, only b-1 is activated.

require 'b/some_file'

# at this point, b-1 and a-2 are both activated,
# because b/some_file.rb required a/some_file.rb

gem 'a', '1' # raises exception

> This way the developer could control autoloading on a
> per-dependency basis.

A user of RubyGems can already control which gem gets activated with  
Kernel#gem.  However, it is up to the user to activate the gems they  
need in dependency order.  `gem lock` can help with this.

> This handles especially well the case where a gem has
> to turn off certain dependencies, but more often than not  
> autoloading is
> fine.

AFAIK, this case has never come up before...

From thewoolleyman at gmail.com  Fri Apr 18 01:38:17 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 17 Apr 2008 22:38:17 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <8FB88458-E8A9-403D-9AB3-55F86E6DB93D@segment7.net>
References: <200804162205.01918.avatar@spellboundnet.com>
	<200804162311.36356.avatar@spellboundnet.com>
	<8FB88458-E8A9-403D-9AB3-55F86E6DB93D@segment7.net>
Message-ID: <e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>

On Thu, Apr 17, 2008 at 8:23 PM, Eric Hodel <drbrain at segment7.net> wrote:
>  A user of RubyGems can already control which gem gets activated with
>  Kernel#gem.  However, it is up to the user to activate the gems they
>  need in dependency order.  `gem lock` can help with this.

Try GemInstaller.  It should be able to provide all the control you
need over gem activation, and autoinstall all required versions as
well.  If you can't make it do what you need, let me know.

-- Chad

From drbrain at segment7.net  Fri Apr 18 04:01:01 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 18 Apr 2008 01:01:01 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>
References: <200804162205.01918.avatar@spellboundnet.com>
	<200804162311.36356.avatar@spellboundnet.com>
	<8FB88458-E8A9-403D-9AB3-55F86E6DB93D@segment7.net>
	<e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>
Message-ID: <797F39FE-CC34-47F9-B3A7-FA2D401A8186@segment7.net>

On Apr 17, 2008, at 22:38 PM, Chad Woolley wrote:
> On Thu, Apr 17, 2008 at 8:23 PM, Eric Hodel <drbrain at segment7.net>  
> wrote:
>> A user of RubyGems can already control which gem gets activated with
>> Kernel#gem.  However, it is up to the user to activate the gems they
>> need in dependency order.  `gem lock` can help with this.
>
> Try GemInstaller.  It should be able to provide all the control you
> need over gem activation, and autoinstall all required versions as
> well.  If you can't make it do what you need, let me know.

This problem is, given a-1, a-2, and b-1 which depends on any a:

gem 'b'

fork {
   gem 'a', '1' # raises as a-2 is active
}

The solutions I see are:

Don't list 'a' as a dependency.

exec after fork to clear memory.

Be careful not to require any files from 'a' and remove 'a' from the  
set of active gems.  (Hard)

From avatar at spellboundnet.com  Fri Apr 18 09:07:08 2008
From: avatar at spellboundnet.com (Donavan Pantke)
Date: Fri, 18 Apr 2008 09:07:08 -0400
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <797F39FE-CC34-47F9-B3A7-FA2D401A8186@segment7.net>
References: <200804162205.01918.avatar@spellboundnet.com>
	<e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>
	<797F39FE-CC34-47F9-B3A7-FA2D401A8186@segment7.net>
Message-ID: <200804180907.08704.avatar@spellboundnet.com>

On Friday 18 April 2008 04:01:01 am Eric Hodel wrote:
> On Apr 17, 2008, at 22:38 PM, Chad Woolley wrote:
> > On Thu, Apr 17, 2008 at 8:23 PM, Eric Hodel <drbrain at segment7.net>  
> > wrote:
> >> A user of RubyGems can already control which gem gets activated with
> >> Kernel#gem.  However, it is up to the user to activate the gems they
> >> need in dependency order.  `gem lock` can help with this.
> >
> > Try GemInstaller.  It should be able to provide all the control you
> > need over gem activation, and autoinstall all required versions as
> > well.  If you can't make it do what you need, let me know.
> 
> This problem is, given a-1, a-2, and b-1 which depends on any a:
> 
> gem 'b'
> 
> fork {
>    gem 'a', '1' # raises as a-2 is active
> }

Correct. I also tested to ensure that the behavior was consistent, and it was 
all the way back to 0.9.0, and it is consistent as you suggested. Sorry bout 
that.


> 
> The solutions I see are:
> 
> Don't list 'a' as a dependency.
Easy to do, but at that point the metadata doesn't describe the data well.

> 
> exec after fork to clear memory.
Well, since the entire point of preloading in this case is to avoid an exec 
and the memory overhead associated with loading the libraries again, that 
doesn't work well.

> 
> Be careful not to require any files from 'a' and remove 'a' from the  
> set of active gems.  (Hard)

Actually, some of this harkens back to an earlier thread about categories of 
dependencies and their handling. In this case, the desired behavior of 
add_dependency in the specification was to influence the installer to ensure 
that the right gems with the right versions were installed. Installed, but 
not necessarily activated. My suggestion right away is just to remove the 
dependency, but this may make a small, easy to implement portion of the 
system. The code should be much simpler because we're not really complicating 
things much.

I'll see what I can come up with.

Thanks!
Donavan
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> 



From thewoolleyman at gmail.com  Fri Apr 18 13:29:36 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 18 Apr 2008 10:29:36 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <200804180907.08704.avatar@spellboundnet.com>
References: <200804162205.01918.avatar@spellboundnet.com>
	<e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>
	<797F39FE-CC34-47F9-B3A7-FA2D401A8186@segment7.net>
	<200804180907.08704.avatar@spellboundnet.com>
Message-ID: <e3af97510804181029m13f876daw6fe0d92fe25b30b9@mail.gmail.com>

On Fri, Apr 18, 2008 at 6:07 AM, Donavan Pantke
<avatar at spellboundnet.com> wrote:
> On Friday 18 April 2008 04:01:01 am Eric Hodel wrote:
>  > Be careful not to require any files from 'a' and remove 'a' from the
>  > set of active gems.  (Hard)

Is this hard primarily because you have to follow the entire
dependency tree of A?

>
>  Actually, some of this harkens back to an earlier thread about categories of
>  dependencies and their handling. In this case, the desired behavior of
>  add_dependency in the specification was to influence the installer to ensure
>  that the right gems with the right versions were installed. Installed, but
>  not necessarily activated. My suggestion right away is just to remove the
>  dependency, but this may make a small, easy to implement portion of the
>  system. The code should be much simpler because we're not really complicating
>  things much.

Different categories of dependencies would help here.  The prior
thread was test vs. build vs. production.  This seems to be yet
another axis - install-time dependencies vs. run-time dependencies.  I
wonder what is the status of this work (Susan?)

If you/we don't want to tackle redefining what dependencies mean in
gemspecs, you can always verify installation manually.  In other
words, don't put the rails (a) dependency in your passenger (b)
gemspec, but still validate at Passenger runtime that SOME version of
rails (a) is installed.  GemInstaller could help here - just ship a
geminstaller.yml which defines passenger's required rails version, and
call GemInstaller.install at passenger start-time - and allow
geminstaller to auto-install or throw an exception if installation
fails.  You could implement this same approach from scratch in to
avoid a dependency on GemInstaller.  You can also look at Rails
itself, which just added similar auto-install behavior that can be
called from rake tasks, which is probably a lot simpler than
GemInstaller's code at this point (I still need to rip out all the
pre-1.0 rubygems legacy support and clean things up...)

Good luck,
-- Chad

From drbrain at segment7.net  Fri Apr 18 16:56:44 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Fri, 18 Apr 2008 13:56:44 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <200804180907.08704.avatar@spellboundnet.com>
References: <200804162205.01918.avatar@spellboundnet.com>
	<e3af97510804172238o3073f202xe66d647c451afaca@mail.gmail.com>
	<797F39FE-CC34-47F9-B3A7-FA2D401A8186@segment7.net>
	<200804180907.08704.avatar@spellboundnet.com>
Message-ID: <F2E8C6EC-7F29-448C-B6DE-F9AFDC1DF16C@segment7.net>

On Apr 18, 2008, at 06:07 AM, Donavan Pantke wrote:
> On Friday 18 April 2008 04:01:01 am Eric Hodel wrote:
>> On Apr 17, 2008, at 22:38 PM, Chad Woolley wrote:
>>> On Thu, Apr 17, 2008 at 8:23 PM, Eric Hodel <drbrain at segment7.net>
>>> wrote:
>>>> A user of RubyGems can already control which gem gets activated  
>>>> with
>>>> Kernel#gem.  However, it is up to the user to activate the gems  
>>>> they
>>>> need in dependency order.  `gem lock` can help with this.
>>>
>>> Try GemInstaller.  It should be able to provide all the control you
>>> need over gem activation, and autoinstall all required versions as
>>> well.  If you can't make it do what you need, let me know.
>>
>> This problem is, given a-1, a-2, and b-1 which depends on any a:
>>
>> gem 'b'
>>
>> fork {
>>   gem 'a', '1' # raises as a-2 is active
>> }
>
> Correct. I also tested to ensure that the behavior was consistent,  
> and it was
> all the way back to 0.9.0, and it is consistent as you suggested.  
> Sorry bout
> that.
>
>> The solutions I see are:
>>
>> Don't list 'a' as a dependency.
> Easy to do, but at that point the metadata doesn't describe the data  
> well.
>
>> exec after fork to clear memory.
> Well, since the entire point of preloading in this case is to avoid  
> an exec
> and the memory overhead associated with loading the libraries again,  
> that
> doesn't work well.

How well does this work?  Doesn't the garbage collector touch the  
majority of your pages the first time it runs un-sharing most of the  
memory saved?  I've never actually measured it, but common knowledge  
seems to be that fork() to save memory via COW usually doesn't save  
much with Ruby.

>> Be careful not to require any files from 'a' and remove 'a' from the
>> set of active gems.  (Hard)
>
> Actually, some of this harkens back to an earlier thread about  
> categories of
> dependencies and their handling. In this case, the desired behavior of
> add_dependency in the specification was to influence the installer  
> to ensure
> that the right gems with the right versions were installed.  
> Installed, but
> not necessarily activated.

I'm not coming up with a good solution that fails in a sensible way.   
Your usecase is unique in this respect, and I think RubyGems simply  
fails it.  :)

> My suggestion right away is just to remove the
> dependency, but this may make a small, easy to implement portion of  
> the
> system. The code should be much simpler because we're not really  
> complicating
> things much.

I think most people know that Passenger requires Rails, so this may be  
the best solution. :)



From avatar at spellboundnet.com  Sat Apr 19 10:22:00 2008
From: avatar at spellboundnet.com (Donavan Pantke)
Date: Sat, 19 Apr 2008 10:22:00 -0400
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <F2E8C6EC-7F29-448C-B6DE-F9AFDC1DF16C@segment7.net>
References: <200804162205.01918.avatar@spellboundnet.com>
	<200804180907.08704.avatar@spellboundnet.com>
	<F2E8C6EC-7F29-448C-B6DE-F9AFDC1DF16C@segment7.net>
Message-ID: <200804191022.00742.avatar@spellboundnet.com>

On Friday 18 April 2008 04:56:44 pm Eric Hodel wrote:
> On Apr 18, 2008, at 06:07 AM, Donavan Pantke wrote:
> > On Friday 18 April 2008 04:01:01 am Eric Hodel wrote:
> >> On Apr 17, 2008, at 22:38 PM, Chad Woolley wrote:
> >>> On Thu, Apr 17, 2008 at 8:23 PM, Eric Hodel <drbrain at segment7.net>
> >>> wrote:
> >>>> A user of RubyGems can already control which gem gets activated  
> >>>> with
> >>>> Kernel#gem.  However, it is up to the user to activate the gems  
> >>>> they
> >>>> need in dependency order.  `gem lock` can help with this.
> >>>
> >>> Try GemInstaller.  It should be able to provide all the control you
> >>> need over gem activation, and autoinstall all required versions as
> >>> well.  If you can't make it do what you need, let me know.
> >>
> >> This problem is, given a-1, a-2, and b-1 which depends on any a:
> >>
> >> gem 'b'
> >>
> >> fork {
> >>   gem 'a', '1' # raises as a-2 is active
> >> }
> >
> > Correct. I also tested to ensure that the behavior was consistent,  
> > and it was
> > all the way back to 0.9.0, and it is consistent as you suggested.  
> > Sorry bout
> > that.
> >
> >> The solutions I see are:
> >>
> >> Don't list 'a' as a dependency.
> > Easy to do, but at that point the metadata doesn't describe the data  
> > well.
> >
> >> exec after fork to clear memory.
> > Well, since the entire point of preloading in this case is to avoid  
> > an exec
> > and the memory overhead associated with loading the libraries again,  
> > that
> > doesn't work well.
> 
> How well does this work?  Doesn't the garbage collector touch the  
> majority of your pages the first time it runs un-sharing most of the  
> memory saved?  I've never actually measured it, but common knowledge  
> seems to be that fork() to save memory via COW usually doesn't save  
> much with Ruby.

Not to get too far OT, but Hongli Lai has come up with a patch for MRI Ruby 
that moves the mark table outside the heap space itself, so GC becomes much 
more COW friendly. Part of the advantages with Passenger and the GC patch is 
that multiple versions of Rails can be loaded in child threads, then a 
GC.start is called right before a fork(), so the heaps have a much longer 
lifespan with COW.

> 
> >> Be careful not to require any files from 'a' and remove 'a' from the
> >> set of active gems.  (Hard)
> >
> > Actually, some of this harkens back to an earlier thread about  
> > categories of
> > dependencies and their handling. In this case, the desired behavior of
> > add_dependency in the specification was to influence the installer  
> > to ensure
> > that the right gems with the right versions were installed.  
> > Installed, but
> > not necessarily activated.
> 
> I'm not coming up with a good solution that fails in a sensible way.   
> Your usecase is unique in this respect, and I think RubyGems simply  
> fails it.  :)

Well, although this usecase is unique for now, with interpreters that handle 
memory better, and more frameworks like passenger come along, it may not that 
way for long.

That being said, what scenarios are you thinking of that would make sensible 
failing hard? My initial plan is to simply make it such that the activation 
code skips dependencies specified as install_only. DependencyInstaller will 
continue as normal. Am I missing something here?


> 
> > My suggestion right away is just to remove the
> > dependency, but this may make a small, easy to implement portion of  
> > the
> > system. The code should be much simpler because we're not really  
> > complicating
> > things much.
> 
> I think most people know that Passenger requires Rails, so this may be  
> the best solution. :)

Possibly, but if we can make the situation better and more seemless.... :)

> 
> 
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> 



From drbrain at segment7.net  Sun Apr 20 04:56:50 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 20 Apr 2008 01:56:50 -0700
Subject: [Rubygems-developers] Gem autoloading problems
In-Reply-To: <200804191022.00742.avatar@spellboundnet.com>
References: <200804162205.01918.avatar@spellboundnet.com>
	<200804180907.08704.avatar@spellboundnet.com>
	<F2E8C6EC-7F29-448C-B6DE-F9AFDC1DF16C@segment7.net>
	<200804191022.00742.avatar@spellboundnet.com>
Message-ID: <A15CDBA0-F707-4475-98A3-38954BC88EC8@segment7.net>

On Apr 19, 2008, at 07:22 AM, Donavan Pantke wrote:
> On Friday 18 April 2008 04:56:44 pm Eric Hodel wrote:
>> I'm not coming up with a good solution that fails in a sensible way.
>> Your usecase is unique in this respect, and I think RubyGems simply
>> fails it.  :)
>
> Well, although this usecase is unique for now, with interpreters  
> that handle
> memory better, and more frameworks like passenger come along, it may  
> not that
> way for long.
>
> That being said, what scenarios are you thinking of that would make  
> sensible
> failing hard? My initial plan is to simply make it such that the  
> activation
> code skips dependencies specified as install_only.  
> DependencyInstaller will
> continue as normal. Am I missing something here?

Adding a feature (dependency types) to fix this would be sensible.

I can't figure out how to do it without doing something like that.

From luislavena at gmail.com  Tue Apr 22 16:51:15 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 22 Apr 2008 17:51:15 -0300
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
Message-ID: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>

Hello guys,

Some of you are aware of the new implementation of One-Click
Installer, which is based on MinGW (GCC) instead of current one based
in VC6.

Besides the huge noise around this, the move to MinGW is to ease the
path of tools, extensions and gem available in *nix to be usable on
Windows.

Right now, i386-mswin32 (VC6) cannot be considered deprecated, since
lot of tools include patches to support it an even considered it the
only Windows platform. Also, until most of the tools properly builds
with the new version, both will be maintained.

Anyway, after this brief introduction, I want to ask and share
something we (Gordon Thiesfeld and I) were discussing on rubyinstaller
development list [1]: merge rubygems generated scripts and stubs into
one and only file (gemname.bat).

Right now RubyGems generates the Windows stubs that call the extension
less files (which contains the actual ruby script).

This is good for running gems from the command line, but fails when
using backticks or system calls from Ruby, since the look up method
used in Ruby prioritize extension less files over executable
(.bat/.cmd/.exe/.com) files. That's one of the reasons we are forced
to add '.bat' to every rake or system call that fires other commands
already installed by other gems.

Ruby bundled scripts workaround this merging both stub (.bat) and
script into the same file.

Another workaround will be hack what currently Ruby does, but that
will require a lot of approval which I see will not came soon (or
ever).

Doing this right now breaks lot of tests, since the presumption of
having two separate scripts will be gone... but this solves a lot of
problems, also reduce the issues when providing patches for other
projects too, since we can disregard the '.bat' regexp at some places.

What do you guys think?

[1] http://rubyforge.org/pipermail/rubyinstaller-devel/2008-April/000292.html
-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Tue Apr 22 19:51:56 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 22 Apr 2008 16:51:56 -0700
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
Message-ID: <BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>

On Apr 22, 2008, at 13:51 PM, Luis Lavena wrote:
> Anyway, after this brief introduction, I want to ask and share
> something we (Gordon Thiesfeld and I) were discussing on rubyinstaller
> development list [1]: merge rubygems generated scripts and stubs into
> one and only file (gemname.bat).

Does this mean `gem install rake` would only produce a `rake.bat`  
instead of both `rake` and `rake.bat`?

Or `gem install tinderbox` (which has two executables) would have a  
`tinderbox.bat` that could invoke either executables via a subcommand?

(Would it be beneficial to add something like `gem execute rake` that  
would run the rake executable?)

> Right now RubyGems generates the Windows stubs that call the extension
> less files (which contains the actual ruby script).
>
> This is good for running gems from the command line, but fails when
> using backticks or system calls from Ruby, since the look up method
> used in Ruby prioritize extension less files over executable
> (.bat/.cmd/.exe/.com) files. That's one of the reasons we are forced
> to add '.bat' to every rake or system call that fires other commands
> already installed by other gems.
>
> Ruby bundled scripts workaround this merging both stub (.bat) and
> script into the same file.

Ok, I think you mean the former.

> Another workaround will be hack what currently Ruby does, but that
> will require a lot of approval which I see will not came soon (or
> ever).

Whose approval?

> Doing this right now breaks lot of tests, since the presumption of
> having two separate scripts will be gone... but this solves a lot of
> problems, also reduce the issues when providing patches for other
> projects too, since we can disregard the '.bat' regexp at some places.
>
> What do you guys think?
>
> [1] http://rubyforge.org/pipermail/rubyinstaller-devel/2008-April/000292.html


From luislavena at gmail.com  Tue Apr 22 23:52:05 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 23 Apr 2008 00:52:05 -0300
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
Message-ID: <71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>

On Tue, Apr 22, 2008 at 8:51 PM, Eric Hodel <drbrain at segment7.net> wrote:
> On Apr 22, 2008, at 13:51 PM, Luis Lavena wrote:
>  > Anyway, after this brief introduction, I want to ask and share
>  > something we (Gordon Thiesfeld and I) were discussing on rubyinstaller
>  > development list [1]: merge rubygems generated scripts and stubs into
>  > one and only file (gemname.bat).
>
>  Does this mean `gem install rake` would only produce a `rake.bat`
>  instead of both `rake` and `rake.bat`?
>
>  Or `gem install tinderbox` (which has two executables) would have a
>  `tinderbox.bat` that could invoke either executables via a subcommand?
>
>  (Would it be beneficial to add something like `gem execute rake` that
>  would run the rake executable?)
>

`gem install rake` will generate only `rake.bat` instead of `rake` and
`rake.bat`

That solves the problem of tools that need to add '.bat' when calling
stuff installed by rubygems under windows. (RubyInline and rubygems
itself for mkrf).

>
>  > Right now RubyGems generates the Windows stubs that call the extension
>  > less files (which contains the actual ruby script).
>  >
>  > This is good for running gems from the command line, but fails when
>  > using backticks or system calls from Ruby, since the look up method
>  > used in Ruby prioritize extension less files over executable
>  > (.bat/.cmd/.exe/.com) files. That's one of the reasons we are forced
>  > to add '.bat' to every rake or system call that fires other commands
>  > already installed by other gems.
>  >
>  > Ruby bundled scripts workaround this merging both stub (.bat) and
>  > script into the same file.
>
>  Ok, I think you mean the former.
>

You're correct :-)

>  > Another workaround will be hack what currently Ruby does, but that
>  > will require a lot of approval which I see will not came soon (or
>  > ever).
>
>  Whose approval?
>

ruby-core and ruby developers. It will require change the way
dln_find_1 (dln.c:1690) since is the responsible to look for rake.*
and prioritize rake (extensionless) over rake.bat.

The problem is around lines is the execution workflow, when asked for
'rake' it will find it at line 1785 and return it at that time, since
eaccess(fbuf, X_OK) will always return 0 on windows (there is no way
to know if a file is executable or not.

The actual check for the execution flag is actually processed starting
at 1802, but we never get there unless there is no file 'rake'
(extensionless).

What do you think will be best? fix the ruby behavior? or change how
rubygems create stuff.

I see quite difficult some of these changes get approved and included,
since I don't get a lot of positive reactions to my comments on
ruby-core (you can say I can be just a pain in the butt).

Thanks for your time replying this.
-- 
Luis Lavena
Multimedia systems
-
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  Wed Apr 23 11:44:18 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 23 Apr 2008 12:44:18 -0300
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
Message-ID: <71166b3b0804230844na532b65qbd8b0c331c770b40@mail.gmail.com>

On Wed, Apr 23, 2008 at 12:52 AM, Luis Lavena <luislavena at gmail.com> wrote:
>
>  ruby-core and ruby developers. It will require change the way
>  dln_find_1 (dln.c:1690) since is the responsible to look for rake.*
>  and prioritize rake (extensionless) over rake.bat.
>
>  The problem is around lines is the execution workflow, when asked for
>  'rake' it will find it at line 1785 and return it at that time, since
>  eaccess(fbuf, X_OK) will always return 0 on windows (there is no way
>  to know if a file is executable or not.
>
>  The actual check for the execution flag is actually processed starting
>  at 1802, but we never get there unless there is no file 'rake'
>  (extensionless).
>
>  What do you think will be best? fix the ruby behavior? or change how
>  rubygems create stuff.
>
>  I see quite difficult some of these changes get approved and included,
>  since I don't get a lot of positive reactions to my comments on
>  ruby-core (you can say I can be just a pain in the butt).
>

A better look at this make me think is better send this to ruby-core
and get this fixed instead. What current Ruby is doing doesn't work as
expected, at least not in Windows.

I'll try create a small example and provide a patch to ruby-core.

Thank you again for your time.

-- 
Luis Lavena
Multimedia systems
-
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 vsizikov at gmail.com  Thu Apr 24 09:02:13 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Thu, 24 Apr 2008 06:02:13 -0700 (PDT)
Subject: [Rubygems-developers] A couple of issues related to JRuby
Message-ID: <24d9930a-2124-4747-9ded-5d1703d1a183@k13g2000hse.googlegroups.com>

Hi folks,

There were a couple of bug reports against JRuby recently, related to
rubygems on Windows, and I'd like to double-check with you on them
first.

The issues are:
JRUBY-2431: Rubygems under JRuby doesn't install BAT executable files
on Windows
http://jira.codehaus.org/browse/JRUBY-2431

JRUBY-2432: Rubygems under JRuby detects the ruby executable name
incorrectly on Windows
http://jira.codehaus.org/browse/JRUBY-2432

The first issue due to fact that rubygems doesn't detect the Windows
platform on JRuby, since rubygems uses RUBY_PLATFORM, and in JRuby
case the value is "java".

This also leads to exceptions if --no-wrappers is used.

The fix is straightforward: in addition to RUBY_PLATFORM, to use
RbConfig's info to detect the platform.

The second issue is due to fact that RbConfig's ruby_install_name for
JRuby on Windows is jruby.bat (since we don't have the native binary,
only the bat file that starts java), and rubygems adds the "EXEEXT"
value thus producing: jruby.bat.exe

The fix is simple too: to check if the extension is already present
(and is equal to BAT or EXE), and only add the "EXEEXT" value in case
if no extension is present in ruby_install_name value).

Any concerns or comments? If that's OK, I'll send out a couple of
patches to resolve these issues.

Thanks,
  --Vladimir

From luislavena at gmail.com  Thu Apr 24 15:03:07 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Thu, 24 Apr 2008 16:03:07 -0300
Subject: [Rubygems-developers] A couple of issues related to JRuby
In-Reply-To: <24d9930a-2124-4747-9ded-5d1703d1a183@k13g2000hse.googlegroups.com>
References: <24d9930a-2124-4747-9ded-5d1703d1a183@k13g2000hse.googlegroups.com>
Message-ID: <71166b3b0804241203wf6906bau61b7c790c33a59c6@mail.gmail.com>

On Thu, Apr 24, 2008 at 10:02 AM, Vladimir Sizikov <vsizikov at gmail.com> wrote:
> Hi folks,
>
>  There were a couple of bug reports against JRuby recently, related to
>  rubygems on Windows, and I'd like to double-check with you on them
>  first.
>
>  The issues are:
>  JRUBY-2431: Rubygems under JRuby doesn't install BAT executable files
>  on Windows
>  http://jira.codehaus.org/browse/JRUBY-2431
>
>  JRUBY-2432: Rubygems under JRuby detects the ruby executable name
>  incorrectly on Windows
>  http://jira.codehaus.org/browse/JRUBY-2432
>
>  The first issue due to fact that rubygems doesn't detect the Windows
>  platform on JRuby, since rubygems uses RUBY_PLATFORM, and in JRuby
>  case the value is "java".
>
>  This also leads to exceptions if --no-wrappers is used.
>
>  The fix is straightforward: in addition to RUBY_PLATFORM, to use
>  RbConfig's info to detect the platform.
>
>  The second issue is due to fact that RbConfig's ruby_install_name for
>  JRuby on Windows is jruby.bat (since we don't have the native binary,
>  only the bat file that starts java), and rubygems adds the "EXEEXT"
>  value thus producing: jruby.bat.exe
>
>  The fix is simple too: to check if the extension is already present
>  (and is equal to BAT or EXE), and only add the "EXEEXT" value in case
>  if no extension is present in ruby_install_name value).
>
>  Any concerns or comments? If that's OK, I'll send out a couple of
>  patches to resolve these issues.
>

Hello Vladimir, I can take a look at those bug if not special
requirements are needed to setup JRuby for testing (already have JRE
installed).

Maybe we need add some tests for these cases into rubygems.

>  Thanks,
>   --Vladimir

Thanks to you for your time,

Regards,
-- 
Luis Lavena
Multimedia systems
-
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 vsizikov at gmail.com  Fri Apr 25 07:54:22 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Fri, 25 Apr 2008 13:54:22 +0200
Subject: [Rubygems-developers] A couple of issues related to JRuby
In-Reply-To: <71166b3b0804241203wf6906bau61b7c790c33a59c6@mail.gmail.com>
References: <24d9930a-2124-4747-9ded-5d1703d1a183@k13g2000hse.googlegroups.com>
	<71166b3b0804241203wf6906bau61b7c790c33a59c6@mail.gmail.com>
Message-ID: <3454c9680804250454w4a630570x1b26df3d2f39b23c@mail.gmail.com>

Hi Luis,

On Thu, Apr 24, 2008 at 9:03 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  Hello Vladimir, I can take a look at those bug if not special
>  requirements are needed to setup JRuby for testing (already have JRE
>  installed).

Thanks for the offer!
Yes, typical JRuby install process is straightforward:
http://wiki.jruby.org/wiki/Getting_Started

Just set JAVA_HOME to point to the correct version of Java installed,
and put the bin directory of JRuby in your PATH. After that, simlpe
'jruby' command would run JRuby. Use jruby -S gem, jruby -S rake,
jruby -S rails, etc to run the tools under JRuby.

I'll be happy to test/verify the changes. If you don't have enough
time/resources to handle the fixes, just let me know and I'll try to
come up with patches myself.

Thanks,
  --Vladimir

From jftucker at gmail.com  Fri Apr 25 07:58:16 2008
From: jftucker at gmail.com (James Tucker)
Date: Fri, 25 Apr 2008 12:58:16 +0100
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <71166b3b0804230844na532b65qbd8b0c331c770b40@mail.gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
	<71166b3b0804230844na532b65qbd8b0c331c770b40@mail.gmail.com>
Message-ID: <144F74B3-21ED-4763-9B31-20724653785A@gmail.com>


On 23 Apr 2008, at 16:44, Luis Lavena wrote:

> On Wed, Apr 23, 2008 at 12:52 AM, Luis Lavena <luislavena at gmail.com>  
> wrote:
>>
>> ruby-core and ruby developers. It will require change the way
>> dln_find_1 (dln.c:1690) since is the responsible to look for rake.*
>> and prioritize rake (extensionless) over rake.bat.
>>
>> The problem is around lines is the execution workflow, when asked for
>> 'rake' it will find it at line 1785 and return it at that time, since
>> eaccess(fbuf, X_OK) will always return 0 on windows (there is no way
>> to know if a file is executable or not.
>>
>> The actual check for the execution flag is actually processed  
>> starting
>> at 1802, but we never get there unless there is no file 'rake'
>> (extensionless).
>>
>> What do you think will be best? fix the ruby behavior? or change how
>> rubygems create stuff.
>>
>> I see quite difficult some of these changes get approved and  
>> included,
>> since I don't get a lot of positive reactions to my comments on
>> ruby-core (you can say I can be just a pain in the butt).
>>
>
> A better look at this make me think is better send this to ruby-core
> and get this fixed instead. What current Ruby is doing doesn't work as
> expected, at least not in Windows.
>
> I'll try create a small example and provide a patch to ruby-core.


assoc .=MaybeExecutable
ftype MaybeExecutable=c:\ruby\bin\ruby c:\pretend_posix\bin\execve %0 %*
set PATHEXT=.;%PATHEXT%

Or something like that. N.B. I got most of the way to the above  
working, and hit some problems (I was working off a network drive at  
the time, YMMV with more local drives, hopefully, the solution can  
work).

Also, git solved this problem by implementing some compatibility  
wrappers:

http://marc.info/?l=git&m=120413867221197&w=2

And the details of the Windows rules, at least CMD rules for launching  
apps are in some more detail here:

http://www.microsoft.com/technet/archive/winntas/deploy/prodspecs/shellscr.mspx?mfr=true

HTH


> Thank you again for your time.
>
> -- 
> Luis Lavena
> Multimedia systems
> -
> 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


From vsizikov at gmail.com  Fri Apr 25 08:02:52 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Fri, 25 Apr 2008 05:02:52 -0700 (PDT)
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com> 
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
Message-ID: <c74bdcfa-e0fd-4246-9649-37fe87085771@a1g2000hsb.googlegroups.com>

Hi Luis, Eric,

My original email seems to be lost (I sent it before subscribing to
the list),
so I'll just quickly repeat it (those parts that I remember :) )

On Apr 23, 5:52 am, "Luis Lavena" <luislav... at gmail.com> wrote:
> On Tue, Apr 22, 2008 at 8:51 PM, Eric Hodel <drbr... at segment7.net> wrote:
> > On Apr 22, 2008, at 13:51 PM, Luis Lavena wrote:
> >  Does this mean `gem install rake` would only produce a `rake.bat`
> >  instead of both `rake` and `rake.bat`?
>
> >  Or `gem install tinderbox` (which has two executables) would have a
> >  `tinderbox.bat` that could invoke either executables via a subcommand?
>
> >  (Would it be beneficial to add something like `gem execute rake` that
> >  would run the rake executable?)

Hmm, would things like ruby -S or jruby -S work for that purpose?

> `gem install rake` will generate only `rake.bat` instead of `rake` and
> `rake.bat`

This makes me uneasy a bit. I like the fact that on both Unix-like and
Windows platforms I have the same scripts (like rake, rails, gem) and
they are identical on both platforms, and easy to use with jruby -S
cmd
(they don't even need to executable, since Ruby would just run them as
scripts).

Removing the files with no extensions and leaving only bat files will
break both ruby -S and jruby -S.

Thanks,
  --Vladimir

From luislavena at gmail.com  Fri Apr 25 08:09:55 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 25 Apr 2008 09:09:55 -0300
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <144F74B3-21ED-4763-9B31-20724653785A@gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
	<71166b3b0804230844na532b65qbd8b0c331c770b40@mail.gmail.com>
	<144F74B3-21ED-4763-9B31-20724653785A@gmail.com>
Message-ID: <71166b3b0804250509r62e9073cia7ecdb3c775599f0@mail.gmail.com>

On Fri, Apr 25, 2008 at 8:58 AM, James Tucker <jftucker at gmail.com> wrote:
> >
> > A better look at this make me think is better send this to ruby-core
> > and get this fixed instead. What current Ruby is doing doesn't work as
> > expected, at least not in Windows.
> >
> > I'll try create a small example and provide a patch to ruby-core.
> >
>
>
>  assoc .=MaybeExecutable
>  ftype MaybeExecutable=c:\ruby\bin\ruby c:\pretend_posix\bin\execve %0 %*
>  set PATHEXT=.;%PATHEXT%
>
>  Or something like that. N.B. I got most of the way to the above working,
> and hit some problems (I was working off a network drive at the time, YMMV
> with more local drives, hopefully, the solution can work).
>
>  Also, git solved this problem by implementing some compatibility wrappers:
>
>  http://marc.info/?l=git&m=120413867221197&w=2
>

Well, what actually Git do is wrap the environment of msys around the
batch file to avoid having it in the PATH.

What we are facing is another problem here.

RubyGems generated 2 files for each executable script that is
installed, example:

rake
rake.bat

spec
spec.bat

When Ruby is doing lookup (dln_find_exe) it consider the first it
finds (rake) to be an executable, and not the later. Then it fails to
use cmd.exe to fire the script and that ended you with borked results.

In any case, Nobu committed a change in the lookup process that solved
this, so now is possible do system('rake') without worry about
platforms, .bat, .cmd or all that.

>  And the details of the Windows rules, at least CMD rules for launching apps
> are in some more detail here:
>
>
> http://www.microsoft.com/technet/archive/winntas/deploy/prodspecs/shellscr.mspx?mfr=true
>

Again, the problem wasn't cmd launching the file, but Ruby picking the
ruby script instead of the stub one.

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Fri Apr 25 08:13:08 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 25 Apr 2008 09:13:08 -0300
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <c74bdcfa-e0fd-4246-9649-37fe87085771@a1g2000hsb.googlegroups.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
	<c74bdcfa-e0fd-4246-9649-37fe87085771@a1g2000hsb.googlegroups.com>
Message-ID: <71166b3b0804250513x112ca4a8qb9e325d235b03449@mail.gmail.com>

On Fri, Apr 25, 2008 at 9:02 AM, Vladimir Sizikov <vsizikov at gmail.com> wrote:
>
>  > `gem install rake` will generate only `rake.bat` instead of `rake` and
>  > `rake.bat`
>
>  This makes me uneasy a bit. I like the fact that on both Unix-like and
>  Windows platforms I have the same scripts (like rake, rails, gem) and
>  they are identical on both platforms, and easy to use with jruby -S
>  cmd
>  (they don't even need to executable, since Ruby would just run them as
>  scripts).
>
>  Removing the files with no extensions and leaving only bat files will
>  break both ruby -S and jruby -S.
>

I understand your worry on this topic. but the actual problem was
dln_find_exe (dln.c) of current MRI.

It consider extensionless files (rake ruby script) before batch stub
(rake.bat) and when tried to use cmd.exe to run it, failed.

Nobu committed a fix for this into 1.8 yesterday and I tested it: work
out of the box without worrying about adding '.bat' to rubygems
scripts.

>  Thanks,
>   --Vladimir
>

Thanks to you and James for your feedback,
-- 
Luis Lavena
Multimedia systems
-
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 jftucker at gmail.com  Fri Apr 25 08:32:18 2008
From: jftucker at gmail.com (James Tucker)
Date: Fri, 25 Apr 2008 13:32:18 +0100
Subject: [Rubygems-developers] Reduce the gap between posix and Windows
In-Reply-To: <71166b3b0804250509r62e9073cia7ecdb3c775599f0@mail.gmail.com>
References: <71166b3b0804221351v33d16626u810124832b58572a@mail.gmail.com>
	<BEC0BB14-FC87-4DE6-8101-28CBBAEFE92F@segment7.net>
	<71166b3b0804222052m686087f7uf3632e079ddcc956@mail.gmail.com>
	<71166b3b0804230844na532b65qbd8b0c331c770b40@mail.gmail.com>
	<144F74B3-21ED-4763-9B31-20724653785A@gmail.com>
	<71166b3b0804250509r62e9073cia7ecdb3c775599f0@mail.gmail.com>
Message-ID: <C2E01768-6A79-4979-BB67-821736FF62FC@gmail.com>


On 25 Apr 2008, at 13:09, Luis Lavena wrote:

> On Fri, Apr 25, 2008 at 8:58 AM, James Tucker <jftucker at gmail.com>  
> wrote:
>>>
>> assoc .=MaybeExecutable
>> ftype MaybeExecutable=c:\ruby\bin\ruby c:\pretend_posix\bin\execve  
>> %0 %*
>> set PATHEXT=.;%PATHEXT%
>>
>> Or something like that. N.B. I got most of the way to the above  
>> working,
>> and hit some problems (I was working off a network drive at the  
>> time, YMMV
>> with more local drives, hopefully, the solution can work).
>>
>> Also, git solved this problem by implementing some compatibility  
>> wrappers:
>>
>> http://marc.info/?l=git&m=120413867221197&w=2
>>
>
> Well, what actually Git do is wrap the environment of msys around the
> batch file to avoid having it in the PATH.
>
> What we are facing is another problem here.

I didn't look at the ruby internals to see what was going on there, it  
appears you've prompted it to be altered in a suitable way.

I was more focusing on the fact that they interpret the shebang to  
look for scripts, as it kinda makes sense to me that it would be a  
good idea to try to make interpreted extension-less scripts actually  
executable on the platform. This is the reason I've been fiddling with  
PATHEXT and friends.

> RubyGems generated 2 files for each executable script that is
> installed, example:
>
> rake
> rake.bat
>
> spec
> spec.bat
>
> When Ruby is doing lookup (dln_find_exe) it consider the first it
> finds (rake) to be an executable, and not the later. Then it fails to
> use cmd.exe to fire the script and that ended you with borked results.

I see, `rake` is not at all executable on Windows however...

> In any case, Nobu committed a change in the lookup process that solved
> this, so now is possible do system('rake') without worry about
> platforms, .bat, .cmd or all that.

that's refreshing :D

From Daniel.Berger at qwest.com  Fri Apr 25 14:20:21 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Fri, 25 Apr 2008 13:20:21 -0500
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>

Hi,

I can't seem to get rid of an old pre-rubygems 1.0 sys-uname gem:

gem env

RubyGems Environment:
  - RUBYGEMS VERSION: 1.1.1
  - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
  - INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
  - RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86-mswin32-60
  - GEM PATHS:
     - c:/ruby/lib/ruby/gems/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - http://gems.rubyforge.org

C:\>gem uninstall sys-uname

Select gem to uninstall:
 1. sys-uname-0.8.1-x86-mswin32
 2. sys-uname-0.8.3
 3. All versions
> 1
INFO:  In order to remove sys-uname, please execute:
        gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8

C:\>gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8

Select gem to uninstall:
 1. sys-uname-0.8.1-x86-mswin32
 2. sys-uname-0.8.3
 3. All versions
> 1
INFO:  In order to remove sys-uname, please execute:
        gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8

I guess it's getting confused by the lack of the '-60' on the platform.

Regards,

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From luislavena at gmail.com  Fri Apr 25 15:05:22 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 25 Apr 2008 16:05:22 -0300
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <71166b3b0804251205g3b26e9d8k42a3fef9f71265d6@mail.gmail.com>

On Fri, Apr 25, 2008 at 3:20 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> Hi,
>
>  I can't seem to get rid of an old pre-rubygems 1.0 sys-uname gem:
>
>  gem env
>
>  RubyGems Environment:
>   - RUBYGEMS VERSION: 1.1.1
>   - RUBY VERSION: 1.8.6 (2007-09-24 patchlevel 111) [i386-mswin32]
>   - INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
>   - RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
>   - RUBYGEMS PLATFORMS:
>     - ruby
>     - x86-mswin32-60
>   - GEM PATHS:
>      - c:/ruby/lib/ruby/gems/1.8
>   - GEM CONFIGURATION:
>      - :update_sources => true
>      - :verbose => true
>      - :benchmark => false
>      - :backtrace => false
>      - :bulk_threshold => 1000
>   - REMOTE SOURCES:
>      - http://gems.rubyforge.org
>
>  C:\>gem uninstall sys-uname
>
>  Select gem to uninstall:
>   1. sys-uname-0.8.1-x86-mswin32
>   2. sys-uname-0.8.3
>   3. All versions
>  > 1
>  INFO:  In order to remove sys-uname, please execute:
>         gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8
>
>  C:\>gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8
>
>  Select gem to uninstall:
>   1. sys-uname-0.8.1-x86-mswin32
>   2. sys-uname-0.8.3
>   3. All versions
>  > 1
>  INFO:  In order to remove sys-uname, please execute:
>         gem uninstall sys-uname --install-dir=c:/ruby/lib/ruby/gems/1.8
>
>  I guess it's getting confused by the lack of the '-60' on the platform.
>

This is similar to what Chad Wolley reported a few weeks back:

http://rubyforge.org/pipermail/rubygems-developers/2008-April/003738.html

Cannot check the code right now, but those gems were installed
pre-0.9.5, so the platform is i386-mswin32 or mswin32 instead of the
'x86-mswin32' it is reporting.

can you test if requiring that specific gem actually works? just to
pinpoint if is only uninstaller that get's confused or is rubygems
itself.

>  Regards,
>

Thank you Dan,
-- 
Luis Lavena
Multimedia systems
-
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  Fri Apr 25 16:13:29 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 25 Apr 2008 13:13:29 -0700
Subject: [Rubygems-developers] "Default" Gem Repositories?
Message-ID: <e3af97510804251313j14b60516ucf3da4de980dcdf3@mail.gmail.com>

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/44c8a4095a8f04c6

If everyone has their own gem repo, then maybe it is a pointless to
try and avoid having separate repositories for JRuby gems, etc.

Is this something to be concerned about?

What is the future of gems.rubyforge.org?

What happens when newbies hear about a cool new gem, but don't know to
look elsewhere than gems.rubyforge.org?

Should the git repo go into the default .gemrc as a standard source?
If so, why?  If not, why?

Does this have any implications for caching/performance issues in rubygems?

-- Chad

From thewoolleyman at gmail.com  Fri Apr 25 16:17:11 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 25 Apr 2008 13:17:11 -0700
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <e3af97510804251317j72c1a05y516f067a066810ed@mail.gmail.com>

On Fri, Apr 25, 2008 at 11:20 AM, Berger, Daniel
<Daniel.Berger at qwest.com> wrote:
>  I guess it's getting confused by the lack of the '-60' on the platform.

Yeah, I think there are still a few edge cases in various commands
where platform matching isn't working completely right, especially if
you have installed gems that are not meant for the current platform.

If you have a reproducible case against 1.1.1, you should open a bug
with details.

-- Chad

From luislavena at gmail.com  Fri Apr 25 16:58:13 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 25 Apr 2008 17:58:13 -0300
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
In-Reply-To: <e3af97510804251317j72c1a05y516f067a066810ed@mail.gmail.com>
References: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
	<e3af97510804251317j72c1a05y516f067a066810ed@mail.gmail.com>
Message-ID: <71166b3b0804251358p7aa54e05v8e8297b88f2a7ede@mail.gmail.com>

On Fri, Apr 25, 2008 at 5:17 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Fri, Apr 25, 2008 at 11:20 AM, Berger, Daniel
>
> <Daniel.Berger at qwest.com> wrote:
>
> >  I guess it's getting confused by the lack of the '-60' on the platform.
>
>  Yeah, I think there are still a few edge cases in various commands
>  where platform matching isn't working completely right, especially if
>  you have installed gems that are not meant for the current platform.
>

Ok, I got it, still need to create a patch.

The error can be traced down to lib/rubygems/uninstaller.rb:178..182:

  def path_ok?(spec)
    match_path = File.join @gem_home, 'gems', spec.full_name

    match_path == spec.full_gem_path
  end

A pre-1.0 gem (mongrel 1.1.1) is trying to match spec.full_name to
full_gem_path:

spec.full_name => mongrel-1.1.1-x86-mswin32
spec.full_gem_path => {...} mongrel-1.1.1-mswin32

(I'm suppressing all the path there just to show the difference)

In this case, match_path will never match the full_gem_path.

>  If you have a reproducible case against 1.1.1, you should open a bug
>  with details.
>

Need to create a test case to reproduce this... couldn't locate a test
where I can hook up and duplicate our situation... never got used to
test/unit :-P

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Fri Apr 25 17:06:31 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 25 Apr 2008 18:06:31 -0300
Subject: [Rubygems-developers] "Default" Gem Repositories?
In-Reply-To: <e3af97510804251313j14b60516ucf3da4de980dcdf3@mail.gmail.com>
References: <e3af97510804251313j14b60516ucf3da4de980dcdf3@mail.gmail.com>
Message-ID: <71166b3b0804251406p10e4284cjde6ebb53701910d1@mail.gmail.com>

On Fri, Apr 25, 2008 at 5:13 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> http://groups.google.com/group/rubyonrails-core/browse_thread/thread/44c8a4095a8f04c6
>
>  If everyone has their own gem repo, then maybe it is a pointless to
>  try and avoid having separate repositories for JRuby gems, etc.
>

Mmm, since long time ago I was hosting my own repo at the office,
since we use pre-build gems for things that will require a compiler
(thats not only for our windows servers, but also linux ones).

>  Is this something to be concerned about?

The way they are asking for release gem requires the direct usage of a
gemspec file. By today, almost all the gems I know depend on a
Rakefiles instead to generate and workaround some issues related to
platform specific code, dependencies or even Version numbers.

Also, do releases of new gems just based on changes to gemspec doesn't
sounds right, at least to me.

>  What is the future of gems.rubyforge.org?
>
>  What happens when newbies hear about a cool new gem, but don't know to
>  look elsewhere than gems.rubyforge.org?

The publisher/developer of the new cool gem should state in his ann or
blog post: gem install cool_gem --source http://...

I think rubyforge gem repository is big enough to be considered the
main and central repository of gems.

>  Should the git repo go into the default .gemrc as a standard source?
>  If so, why?  If not, why?
>

I don't like gem install install things that didn't follow a good
release policy, if I want to play with hot stuff, I'll put my hands in
the kitchen myself, and not let rubygems do it for me.

>  Does this have any implications for caching/performance issues in rubygems?
>

I think is just another repository like you could have with one
installed locally via .gemrc.
(afaik)

-- 
Luis Lavena
Multimedia systems
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From drbrain at segment7.net  Sun Apr 27 01:37:49 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Sun, 27 Apr 2008 01:37:49 -0400
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
In-Reply-To: <71166b3b0804251358p7aa54e05v8e8297b88f2a7ede@mail.gmail.com>
References: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
	<e3af97510804251317j72c1a05y516f067a066810ed@mail.gmail.com>
	<71166b3b0804251358p7aa54e05v8e8297b88f2a7ede@mail.gmail.com>
Message-ID: <D14BB079-04D6-4643-BB37-0E16E623DAFE@segment7.net>

On Apr 25, 2008, at 16:58 PM, Luis Lavena wrote:
> On Fri, Apr 25, 2008 at 5:17 PM, Chad Woolley  
> <thewoolleyman at gmail.com> wrote:
>> On Fri, Apr 25, 2008 at 11:20 AM, Berger, Daniel
>>
>> <Daniel.Berger at qwest.com> wrote:
>>
>>> I guess it's getting confused by the lack of the '-60' on the  
>>> platform.
>>
>> Yeah, I think there are still a few edge cases in various commands
>> where platform matching isn't working completely right, especially if
>> you have installed gems that are not meant for the current platform.
>>
>
> Ok, I got it, still need to create a patch.
>
> The error can be traced down to lib/rubygems/uninstaller.rb:178..182:
>
>  def path_ok?(spec)
>    match_path = File.join @gem_home, 'gems', spec.full_name
>
>    match_path == spec.full_gem_path
>  end
>
> A pre-1.0 gem (mongrel 1.1.1) is trying to match spec.full_name to
> full_gem_path:
>
> spec.full_name => mongrel-1.1.1-x86-mswin32
> spec.full_gem_path => {...} mongrel-1.1.1-mswin32
>
> (I'm suppressing all the path there just to show the difference)
>
> In this case, match_path will never match the full_gem_path.

It should probably check original_name in addition to full_name.

>> If you have a reproducible case against 1.1.1, you should open a bug
>> with details.
>>
>
> Need to create a test case to reproduce this... couldn't locate a test
> where I can hook up and duplicate our situation... never got used to
> test/unit :-P

I haven't played much in the uninstaller, so I think there aren't many  
tests there :(

From luislavena at gmail.com  Sun Apr 27 22:10:52 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 27 Apr 2008 23:10:52 -0300
Subject: [Rubygems-developers] Problem trying to uninstall an old gem
In-Reply-To: <D14BB079-04D6-4643-BB37-0E16E623DAFE@segment7.net>
References: <7524A45A1A5B264FA4809E2156496CFB023D3204@ITOMAE2KM01.AD.QINTRA.COM>
	<e3af97510804251317j72c1a05y516f067a066810ed@mail.gmail.com>
	<71166b3b0804251358p7aa54e05v8e8297b88f2a7ede@mail.gmail.com>
	<D14BB079-04D6-4643-BB37-0E16E623DAFE@segment7.net>
Message-ID: <71166b3b0804271910x225f08f8p59faa2e13ae77ef6@mail.gmail.com>

On Sun, Apr 27, 2008 at 2:37 AM, Eric Hodel <drbrain at segment7.net> wrote:
> On Apr 25, 2008, at 16:58 PM, Luis Lavena wrote:
>
> >
> > In this case, match_path will never match the full_gem_path.
> >
>
>  It should probably check original_name in addition to full_name.
>

Something like this will work? (dunno if matches the standard.

=== modified file 'lib/rubygems/uninstaller.rb'
--- lib/rubygems/uninstaller.rb 2008-02-24 03:08:49 +0000
+++ lib/rubygems/uninstaller.rb 2008-04-28 02:04:36 +0000
@@ -176,9 +176,11 @@
   end

   def path_ok?(spec)
-    match_path = File.join @gem_home, 'gems', spec.full_name
-
-    match_path == spec.full_gem_path
+    match_path_full = File.join @gem_home, 'gems', spec.full_name
+    match_path_original = File.join @gem_home, 'gems', spec.original_name
+
+    match_path_full == spec.full_gem_path ||
+      match_path_original == spec.full_gem_path
   end

   def dependencies_ok?(spec)


Too verbose for my taste...

>
>
> >
> > > If you have a reproducible case against 1.1.1, you should open a bug
> > > with details.
> > >
> > >
> >
> > Need to create a test case to reproduce this... couldn't locate a test
> > where I can hook up and duplicate our situation... never got used to
> > test/unit :-P
> >
>
>  I haven't played much in the uninstaller, so I think there aren't many
> tests there :(
>


Don't worry. the above patch work:

i386-mswin32: 594 tests, 1774 assertions, 0 failures, 0 errors
i386-mingw32: 588 tests, 1745 assertions, 0 failures, 0 errors

Also installing and uninstalling the offending gems from Chad copy of
his ruby installation :-)

Regards,
-- 
Luis Lavena
Multimedia systems
-
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  Mon Apr 28 07:03:59 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 28 Apr 2008 08:03:59 -0300
Subject: [Rubygems-developers] A couple of issues related to JRuby
In-Reply-To: <3454c9680804250454w4a630570x1b26df3d2f39b23c@mail.gmail.com>
References: <24d9930a-2124-4747-9ded-5d1703d1a183@k13g2000hse.googlegroups.com>
	<71166b3b0804241203wf6906bau61b7c790c33a59c6@mail.gmail.com>
	<3454c9680804250454w4a630570x1b26df3d2f39b23c@mail.gmail.com>
Message-ID: <71166b3b0804280403t77a9f297ya81e2347b192558d@mail.gmail.com>

On Fri, Apr 25, 2008 at 8:54 AM, Vladimir Sizikov <vsizikov at gmail.com> wrote:
> Hi Luis,
>
>
>  On Thu, Apr 24, 2008 at 9:03 PM, Luis Lavena <luislavena at gmail.com> wrote:
>  >  Hello Vladimir, I can take a look at those bug if not special
>  >  requirements are needed to setup JRuby for testing (already have JRE
>  >  installed).
>
>  Thanks for the offer!
>  Yes, typical JRuby install process is straightforward:
>  http://wiki.jruby.org/wiki/Getting_Started
>
>  Just set JAVA_HOME to point to the correct version of Java installed,
>  and put the bin directory of JRuby in your PATH. After that, simlpe
>  'jruby' command would run JRuby. Use jruby -S gem, jruby -S rake,
>  jruby -S rails, etc to run the tools under JRuby.
>
>  I'll be happy to test/verify the changes. If you don't have enough
>  time/resources to handle the fixes, just let me know and I'll try to
>  come up with patches myself.
>
>

Ok, got the time, done some checkings.

- RbConfig::CONFIG['host_os']

For several years depending on RUBY_PLATFORM to determine the OS that
host your ruby interpreter was the defacto. Adding host_os to the
Gem.win_platform? will only tackle Gem and projects that:

Directly depend on RubyGems presence to be installed (forget about
package manager using plain setup.rb).

- jruby.bat.exe and the lack of .bat for the generated gems.

This is not complicated to fix, as you stated, but the batch files
generated by RubyGems right now are win32 specific.

I can review the patch If you provide the stub content that need to be
written, based on code it currently generates the stub scripts.

Since these scripts depend on win_platform? being true, we the first
item must be solved before continue.

Regards,
-- 
Luis Lavena
Multimedia systems
-
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 charles.nutter at sun.com  Mon Apr 28 10:40:09 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Mon, 28 Apr 2008 09:40:09 -0500
Subject: [Rubygems-developers] env shebang always for JRuby
Message-ID: <4815E1C9.7060403@sun.com>

JRuby ships with its "jruby" command as a shell script or batch file 
under Windows. This means that the default behavior for JRuby installing 
RubyGems is to always use an "env" shebang. However there are two 
problems with this right now:

- we have to manually patch our copy of RubyGems every time we upgrade, 
to make sure it env-shebangs by default
- RubyGems hardcodes the env shebang string to "ruby" rather than using 
the name of the current runtime's command (this may have been fixed?)

At any rate, I'm looking for suggestions or a RubyGems fix that will 
save us having to manually patch this all the time. JRuby is not going 
to have a native startup command any time soon, so the env shebang is 
always going to be necessary.

Thoughts?

- Charlie

From vsizikov at gmail.com  Mon Apr 28 11:54:25 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Mon, 28 Apr 2008 17:54:25 +0200
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <4815E1C9.7060403@sun.com>
References: <4815E1C9.7060403@sun.com>
Message-ID: <3454c9680804280854w122b3d17ne2cd5f434e360528@mail.gmail.com>

Charlie,

I think rubygems has just the option for us:
-E, --[no-]env-shebang           Rewrite the shebang line on installed
                                                    scripts to use /usr/bin/env

But it didn't work for me earlier today when I upgraded rubygems for
JRuby from 1.1 to 1.1.1, for some reason.

Well, the upgrade from 1.1.0 to 1.1.1 was a bit unusual altogether,
since the following command just did nothing, refusing to upgrade:
jruby -S gem update --system --env-shebang --no-rdoc --no-ri

So, I first downgraded to rubygems 1.0.1, and then upgraded to 1.1.1
successfully.

Thanks,
  --Vladimir

On Mon, Apr 28, 2008 at 4:40 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> JRuby ships with its "jruby" command as a shell script or batch file under
> Windows. This means that the default behavior for JRuby installing RubyGems
> is to always use an "env" shebang. However there are two problems with this
> right now:
>
>  - we have to manually patch our copy of RubyGems every time we upgrade, to
> make sure it env-shebangs by default
>  - RubyGems hardcodes the env shebang string to "ruby" rather than using the
> name of the current runtime's command (this may have been fixed?)
>
>  At any rate, I'm looking for suggestions or a RubyGems fix that will save
> us having to manually patch this all the time. JRuby is not going to have a
> native startup command any time soon, so the env shebang is always going to
> be necessary.
>
>  Thoughts?
>
>  - Charlie
>  _______________________________________________
>  Rubygems-developers mailing list
>  Rubygems-developers at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rubygems-developers
>

From vsizikov at gmail.com  Mon Apr 28 12:28:37 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Mon, 28 Apr 2008 18:28:37 +0200
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <4815E1C9.7060403@sun.com>
References: <4815E1C9.7060403@sun.com>
Message-ID: <3454c9680804280928xcdd3abcod12c40623598bffb@mail.gmail.com>

Oh, I misunderstood the email.

Indeed the, there is --env-shebang option, but it's not a default one,
and it does break binaries,
installed under JRuby.

Yes, it would be nice to have a way to make --env-shebang the default
one without patching the rubygems sources.

More below.

On Mon, Apr 28, 2008 at 4:40 PM, Charles Oliver Nutter
<charles.nutter at sun.com> wrote:
> JRuby ships with its "jruby" command as a shell script or batch file under
> Windows. This means that the default behavior for JRuby installing RubyGems
> is to always use an "env" shebang. However there are two problems with this
> right now:
>
>  - we have to manually patch our copy of RubyGems every time we upgrade, to
> make sure it env-shebangs by default
>  - RubyGems hardcodes the env shebang string to "ruby" rather than using the
> name of the current runtime's command (this may have been fixed?)

I think this was fixed. At least when I try to install, say, rake and
provide --env-shebang option,
I end up with rake script with proper shebang: #!/usr/bin/env jruby

Thanks,
  --Vladimir

From avatar at spellboundnet.com  Tue Apr 29 08:52:45 2008
From: avatar at spellboundnet.com (Donavan Pantke)
Date: Tue, 29 Apr 2008 08:52:45 -0400
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <4815E1C9.7060403@sun.com>
References: <4815E1C9.7060403@sun.com>
Message-ID: <200804290852.45647.avatar@spellboundnet.com>

On Monday 28 April 2008 10:40:09 am Charles Oliver Nutter wrote:
> JRuby ships with its "jruby" command as a shell script or batch file 
> under Windows. This means that the default behavior for JRuby installing 
> RubyGems is to always use an "env" shebang. However there are two 
> problems with this right now:
> 
> - we have to manually patch our copy of RubyGems every time we upgrade, 
> to make sure it env-shebangs by default
> - RubyGems hardcodes the env shebang string to "ruby" rather than using 
> the name of the current runtime's command (this may have been fixed?)
> 
> At any rate, I'm looking for suggestions or a RubyGems fix that will 
> save us having to manually patch this all the time. JRuby is not going 
> to have a native startup command any time soon, so the env shebang is 
> always going to be necessary.

I think that a of the discussions lately about gem vs. jgem, auto-default 
env-shebangs, etc.... is IMO symptomatic of a larger problem in handing gem 
executable binaries, and that problem is, "which interpreter do we use?". Now 
that we have real situations where you have multiple interpreters actively 
being used on a single system, our current method of selecting an interpreter 
is no longer adequate.

First, I want to stress that there should only be one gem repo on a system. 
RubyGems is platform-agnostic and handles selecting code based on interpreter 
platform well. Having multiple system-wide gem repositores is asking for 
trouble, since they all have to share a single PATH, and this problem is what 
led to "gem" vs. "jgem". The easiest way to get rid of strange PATH problems 
is to have one RubyGems managing it.

So how can RubyGems select between several interpreters? We'll need a couple 
of things to make this happen:

- A way to determine the default interpreter on the system.

This is easy to do on POSIX (symlink!), not so easy in Windows. Luis, do you 
have any thoughts on this? Remember, we don't really care what interpreter is 
called by "gem", so long as "gem" will run!

- An interpreter-independent GEM_HOME. We need to statically define where gems 
live so we gain platform/interpreter independence.

- A way for a gem to specify what interpreter has to be used.

- A way for the user to specify an alternate interpreter at install time. 
(Maybe at execution-time, too?)

- And while we're tackling binary problems, let's see if we can solve the 
problem of specifying the version of the binary we want to call (it currently 
drives me nuts that I can't just say "rails version=1.2.6 some_project").

In the future, we may run into problems with language incompatibilities (which 
I think is why the current structure imbeds versions). If things work out 
well, I hope this problem will solve itself by having the language spec 
independent of the implementation, and we can just add language version as an 
additional type of dependency.

I don't want to get too heavy into implementation details until we agree on 
the concepts, so.... what do you guys think?

Thanks!
Donavan

> 
> Thoughts?
> 
> - Charlie
> _______________________________________________
> Rubygems-developers mailing list
> Rubygems-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubygems-developers
> 



From jim.weirich at gmail.com  Tue Apr 29 09:11:40 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Tue, 29 Apr 2008 09:11:40 -0400
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <200804290852.45647.avatar@spellboundnet.com>
References: <4815E1C9.7060403@sun.com>
	<200804290852.45647.avatar@spellboundnet.com>
Message-ID: <4EABE8F4-7251-493F-B0CA-F4E6D881EA57@gmail.com>


On Apr 29, 2008, at 8:52 AM, Donavan Pantke wrote:
> - And while we're tackling binary problems, let's see if we can  
> solve the
> problem of specifying the version of the binary we want to call (it  
> currently
> drives me nuts that I can't just say "rails version=1.2.6  
> some_project").


Already available:

$ rake _0.8.1_ --version
rake, version 0.8.1
$ rake _0.7.3_ --version
rake, version 0.7.3

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From stephen.bannasch at deanbrook.org  Tue Apr 29 10:46:58 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Tue, 29 Apr 2008 10:46:58 -0400
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <200804290852.45647.avatar@spellboundnet.com>
References: <4815E1C9.7060403@sun.com>
	<200804290852.45647.avatar@spellboundnet.com>
Message-ID: <p06240865c43cda2e6292@[63.138.152.170]>

At 8:52 AM -0400 4/29/08, Donavan Pantke wrote:
>First, I want to stress that there should only be one gem repo on a system.
>RubyGems is platform-agnostic and handles selecting code based on interpreter
>platform well. Having multiple system-wide gem repositores is asking for
>trouble, since they all have to share a single PATH, and this problem is what
>led to "gem" vs. "jgem". The easiest way to get rid of strange PATH problems
>is to have one RubyGems managing it.

I like the idea but I recommend just the opposite for now -- always use separate gem repositories for different Ruby VMs.

  http://rubyforge.org/pipermail/rubygems-developers/2008-April/003737.html

Two basic problems: what native code gets built and which commands are installed in whatever passes for "bin/".

When a gem is installed that requires compilation and linking (or more generally any custom build products that are specific for a particular Ruby VM and OS -- for example an executable shell script) during the install the products of that install will only work when it is later used with the same Ruby VM and OS it was installed with. More about this problem here:

  http://rubyforge.org/pipermail/rubygems-developers/2008-April/003717.html

I mention the idea of lazy installation in that message: when a Gem with native code is installed using Ruby VM-A and later first used with Ruby VM-B perhaps the compilation and install part of the process can be run again by Ruby VM-B.

Or perhaps with a system GEM (which of course needs a system Ruby) alternate Ruby VM's could register themselves when installed.

There is also the problem of conflicting "bin/" commands requiring in a simple case different shebang lines.

A subtlety with the JRuby VM is that the Ruby is running on both a Java OS (in effect) and a host OS and has strong capabilities for interacting with both systems. This doesn't usually matter for most Java programs because they often only deal with the host OS mediated through Java libraries -- but among many other things Ruby is a systems programming language and Ruby scripts written to support these tasks often have code written to operate differently on different host OS platforms. In these cases code written to also run on JRuby may need to take into account that it is running both in JRuby on Java AND on which host OS Windows, MacOS, etc.

>- A way for a gem to specify what interpreter has to be used.

Or which interpreters may be used (all in the simple case) and which may not be used.

From charles.nutter at sun.com  Tue Apr 29 19:46:28 2008
From: charles.nutter at sun.com (Charles Oliver Nutter)
Date: Tue, 29 Apr 2008 18:46:28 -0500
Subject: [Rubygems-developers] env shebang always for JRuby
In-Reply-To: <200804290852.45647.avatar@spellboundnet.com>
References: <4815E1C9.7060403@sun.com>
	<200804290852.45647.avatar@spellboundnet.com>
Message-ID: <4817B354.5090605@sun.com>

First I'll say this isn't really related to the shebang thing. The env 
shebang hardcoding "/usr/bin/env ruby" would affect MRI too if you had 
an sh script not named 'ruby' you wanted to use as your launcher. That's 
essentially the case here; the 'jruby' command is a bash script that 
launches a JVM running JRuby. So that should be fixed to use the 
*actual* command name instead.

And the fact that we need env-shebangs by default is unrelated as 
well...it all comes back to the 'jruby' command being a bash script.

Second, I'll respond to a couple of your points.

Donavan Pantke wrote:
> First, I want to stress that there should only be one gem repo on a system. 
> RubyGems is platform-agnostic and handles selecting code based on interpreter 
> platform well. Having multiple system-wide gem repositores is asking for 
> trouble, since they all have to share a single PATH, and this problem is what 
> led to "gem" vs. "jgem". The easiest way to get rid of strange PATH problems 
> is to have one RubyGems managing it.

I think it should be an option that you have one repo, but I prefer to 
keep them separate myself. It certainly shouldn't be the default, since 
lots and lots of people install and use JRuby as their username, 
sometimes with a couple installs...and it ships with a couple IDEs, 
which package it in a subdir. Some people want to use a shared repo, 
some don't.

> So how can RubyGems select between several interpreters? We'll need a couple 
> of things to make this happen:
> 
> - A way to determine the default interpreter on the system.
> 
> This is easy to do on POSIX (symlink!), not so easy in Windows. Luis, do you 
> have any thoughts on this? Remember, we don't really care what interpreter is 
> called by "gem", so long as "gem" will run!

It would *seriously* suck if the only way to get rubygems to choose 
JRuby was by using a symlink...and the 'jruby' command isn't an 
executable, so gems installed without shebangs would not work wen you 
switched from ruby to jruby.

> - An interpreter-independent GEM_HOME. We need to statically define where gems 
> live so we gain platform/interpreter independence.

If you like, you can do that now and have JRuby access an existing 
GEM_HOME. I'm not sure people do it though.

> - A way for a gem to specify what interpreter has to be used.

This would definitely be nice to have in the gem metadata, since there's 
conceivably going to be five implementations to choose from that might 
all have their own extension mechanisms (ruby 1.8/1.9, jruby, rubinius, 
macruby [ObjC extensions?], ironruby).

> - A way for the user to specify an alternate interpreter at install time. 
> (Maybe at execution-time, too?)

Maybe...starts to get a little cumbersome at that point though.

- Charlie

From caleb.land at gmail.com  Tue Apr 29 23:13:57 2008
From: caleb.land at gmail.com (Caleb Land)
Date: Tue, 29 Apr 2008 23:13:57 -0400
Subject: [Rubygems-developers] Missing require from
	rubygems/remote_fetcher.rb "stringio"
Message-ID: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>

Running Jruby 1.1.1, I have the following problem (
http://jira.codehaus.org/browse/JRUBY-2476):

I untar JRuby 1.1.1, and then the following happens when I attempt to list
out of date gems:

$ jruby -S gem outdated
Bulk updating Gem source index for: http://gems.rubyforge.org/
ERROR: While executing gem ... (Gem::RemoteSourceException)
Error fetching remote gem cache: NameError: uninitialized constant
Gem::RemoteFetcher::StringIO reading
http://gems.rubyforge.org/yaml

I get this same error when I try to do the following:
$ jruby -S gem sources -a http://gems.github.com

I've also tried this on Linux with Java 1.6, and I get the same error.

If I open up jruby-1.1.1/lib/ruby/site_ruby/1.8/rubygems/remote_fetcher.rb and
add require 'stringio' to the top, it fixes the problem.


The remote_fetcher.rb file uses StringIO, but does not directly require
stringio. It works on MRI because someone else requires stringio for us, but
on JRuby this isn't happening. I think it might be yaml.rb, which doesn't
require stringio on JRuby but does on MRI.

If I recompile my jruby with a "require 'stringio'" in my yaml.rb, the
problem goes away.

What do you think?

-- 
Caleb Land
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080429/d7a20c0e/attachment.html>

From drbrain at segment7.net  Tue Apr 29 23:34:19 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 29 Apr 2008 20:34:19 -0700
Subject: [Rubygems-developers] Missing require from
	rubygems/remote_fetcher.rb "stringio"
In-Reply-To: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>
References: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>
Message-ID: <625FA5A0-6F70-4460-A75C-87BA72D73F6E@segment7.net>

On Apr 29, 2008, at 20:13 PM, Caleb Land wrote:

> [...]
> What do you think?

Please file bugs on the bug tracker.  Thanks.

From vsizikov at gmail.com  Wed Apr 30 03:51:04 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Wed, 30 Apr 2008 09:51:04 +0200
Subject: [Rubygems-developers] Missing require from
	rubygems/remote_fetcher.rb "stringio"
In-Reply-To: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>
References: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>
Message-ID: <3454c9680804300051q6eb520dk9c07ff67e6d07cb9@mail.gmail.com>

Hi Caleb,

This problem has been bugging us in JRuby for a while, I've seen few
reports from users about it, but no reliable use case that triggers
the problem were presented (until now, that is). :)

Thanks for reporting it and providing the suggested fix. I've fixed
the JRuby trunk for now, but I agree that it would be great if the fix
would made it into rubygems main repo.

Thanks,
  --Vladimir

On Wed, Apr 30, 2008 at 5:13 AM, Caleb Land <caleb.land at gmail.com> wrote:
> Running Jruby 1.1.1, I have the following problem
> (http://jira.codehaus.org/browse/JRUBY-2476):
>
>  I untar JRuby 1.1.1, and then the following happens when I attempt to list
> out of date gems:

From vsizikov at gmail.com  Wed Apr 30 04:25:57 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Wed, 30 Apr 2008 10:25:57 +0200
Subject: [Rubygems-developers] Missing require from
	rubygems/remote_fetcher.rb "stringio"
In-Reply-To: <3454c9680804300051q6eb520dk9c07ff67e6d07cb9@mail.gmail.com>
References: <bd544b2d0804292013v318ea262q8d52428ebf60b76b@mail.gmail.com>
	<3454c9680804300051q6eb520dk9c07ff67e6d07cb9@mail.gmail.com>
Message-ID: <3454c9680804300125t2674d02dl40a531d65365e57d@mail.gmail.com>

OK, some more info here.

Ola Bini figured out why MRI works and JRuby fails in the first place.
It turned out that yaml library in MRI requires StringIO, while JRuby
didn't. This has been corrected so that JRuby is
"side-effect-compatible" with MRI in that regard, and yaml now also
require's StringIO.

Still, adding explicit require 'stringio' to rubygems sources could be
useful, making the code more robust and less dependent on particular
implementation and side effects.

Thanks,
  --Vladimir

On Wed, Apr 30, 2008 at 9:51 AM, Vladimir Sizikov <vsizikov at gmail.com> wrote:
> Hi Caleb,
>
>  This problem has been bugging us in JRuby for a while, I've seen few
>  reports from users about it, but no reliable use case that triggers
>  the problem were presented (until now, that is). :)
>
>  Thanks for reporting it and providing the suggested fix. I've fixed
>  the JRuby trunk for now, but I agree that it would be great if the fix
>  would made it into rubygems main repo.
>
>  Thanks,
>   --Vladimir
>
>
>
>  On Wed, Apr 30, 2008 at 5:13 AM, Caleb Land <caleb.land at gmail.com> wrote:
>  > Running Jruby 1.1.1, I have the following problem
>  > (http://jira.codehaus.org/browse/JRUBY-2476):
>  >
>  >  I untar JRuby 1.1.1, and then the following happens when I attempt to list
>  > out of date gems:
>