From jim at weirichhouse.org  Sat Apr  1 22:56:05 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Sat, 01 Apr 2006 22:56:05 -0500
Subject: [Rubygems-developers] CVS Head Gem has problems installing
 latest rails
In-Reply-To: <442DAA20.5010007@weirichhouse.org>
References: <442DAA20.5010007@weirichhouse.org>
Message-ID: <442F4B55.4040809@weirichhouse.org>

Jim Weirich wrote:
> I get the following while installing a the latest version of rails.
> 
> $ sudo gem install rails -y
[...]
> ERROR:  While executing gem ... (RuntimeError)
>      Unhandled special: Special: type=17, text="SimpleXML"

It seems that you can't run the RI document option twice in the same 
program invocation.  I've patched my local gem command to trap the error 
and continue with the rest of the RDOC/RI generation.  Only the first RI 
document is generated, all the others fail with similar errors.

I think it is good to *not* abort the entire gem command on a 
documentation installation error (assuming appropriate error messages 
are given), so I will fix that in gems.  But that just sidesteps the 
basic problem of why the RI documentation fails.  I will post a message 
in Ruby-core about this.

-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From jim at weirichhouse.org  Sat Apr  1 23:39:04 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Sat, 01 Apr 2006 23:39:04 -0500
Subject: [Rubygems-developers] CVS Head Gem has problems installing
 latest rails
In-Reply-To: <442F4B55.4040809@weirichhouse.org>
References: <442DAA20.5010007@weirichhouse.org>
	<442F4B55.4040809@weirichhouse.org>
Message-ID: <442F5568.8040504@weirichhouse.org>

Jim Weirich wrote:
> I think it is good to *not* abort the entire gem command on a 
> documentation installation error (assuming appropriate error messages 
> are given), so I will fix that in gems.  [...]

Committed.

-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From jim at weirichhouse.org  Tue Apr  4 14:35:57 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Tue, 04 Apr 2006 14:35:57 -0400
Subject: [Rubygems-developers] Getting at non-lib dirs in gem
	(like	datadir)
In-Reply-To: <4b6f054f0603301618n4a99f770saf3e095bd3335e1@mail.gmail.com>
References: <4b6f054f0603291826h7072ed8se70e3b561d00505d@mail.gmail.com>
	<4b6f054f0603301618n4a99f770saf3e095bd3335e1@mail.gmail.com>
Message-ID: <4432BC8D.6050004@weirichhouse.org>

TRANS wrote:
> On 3/29/06, TRANS <transfire at gmail.com> wrote:
>> Could these be added to the Gems module?
>>
>>     def active?(gemname)
>>     def gemspec(gemname)
>>     def gempath(gemname)
>>     def gemdir(gemname, dir)

I haven't had a chance to look at these in detail.  I will agree in 
principle that having a more reflective gem interface is a good thing. 
I'm planning on spending some time looking at that datadir issue after 
incremental downloading is in place. (and after that, continuing on the 
local/remote gem integration).

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From jim at weirichhouse.org  Tue Apr  4 17:01:11 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Tue, 04 Apr 2006 17:01:11 -0400
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <442A9DCD.1050402@weirichhouse.org>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>
	<442A9DCD.1050402@weirichhouse.org>
Message-ID: <4432DE97.5090809@weirichhouse.org>

Jim Weirich wrote:
> Tom, here is the software to generate the rubygems server index files. 
> The script is index_gem_repository.rb and is called as follows:  [...]

Here is an update.

Tom has installed the indexing software on RubyForge.  Based on initial 
timings, I put the cutoff at 50 outdated gems.  In other words, if there 
are more that 50 gems to be updated, it is better to do a bulk update 
(with one humongous file) rather than a bunch of little updates of small 
files.  That number is subject to further testing, but it seems a good 
first cut.

There is a beta version of the gem software available that supports 
incremental updating.  You can get it from CVS head, or with:

    gem update --system --source http://onestepback.org/betagems

Give this a whirl and report any problems back here on the list.

Thanks.

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From chad at chadfowler.com  Tue Apr  4 19:06:06 2006
From: chad at chadfowler.com (Chad Fowler)
Date: Tue, 4 Apr 2006 17:06:06 -0600
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <4432DE97.5090809@weirichhouse.org>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>
	<442A9DCD.1050402@weirichhouse.org>
	<4432DE97.5090809@weirichhouse.org>
Message-ID: <70DAE1E8-C24D-447D-9B0C-CB84AF4B1F1F@chadfowler.com>


On Apr 4, 2006, at 3:01 PM, Jim Weirich wrote:

>     gem update --system --source http://onestepback.org/betagems


This is totally rocking!  It feels _much_ faster to me.

I think we should open up beta testing to a wide audience of people  
who know they're in for potential problems.

To that end, I'm going to tell people in Rails Core and the private  
#caboose channel of about 50 people to try it at their own risk.  It  
would be great to get this into circulation before another huge Rails
download-fest :)

Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20060404/98f0792f/attachment-0001.htm 

From tom at infoether.com  Tue Apr  4 19:16:15 2006
From: tom at infoether.com (Tom Copeland)
Date: Tue, 04 Apr 2006 19:16:15 -0400
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <70DAE1E8-C24D-447D-9B0C-CB84AF4B1F1F@chadfowler.com>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>
	<442A9DCD.1050402@weirichhouse.org> <4432DE97.5090809@weirichhouse.org>
	<70DAE1E8-C24D-447D-9B0C-CB84AF4B1F1F@chadfowler.com>
Message-ID: <1144192575.17140.17.camel@hal>

On Tue, 2006-04-04 at 17:06 -0600, Chad Fowler wrote:

> To that end, I'm going to tell people in Rails Core and the private
> #caboose channel of about 50 people to try it at their own risk.  It
> would be great to get this into circulation before another huge Rails
> download-fest :)

+1 on that!

tom



From jim at weirichhouse.org  Wed Apr  5 11:20:59 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 05 Apr 2006 11:20:59 -0400
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <4432DE97.5090809@weirichhouse.org>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>	<442A9DCD.1050402@weirichhouse.org>
	<4432DE97.5090809@weirichhouse.org>
Message-ID: <4433E05B.3030703@weirichhouse.org>

I found a bug in the new extension builder portion of RubyGems.  It is 
unrelated to the incremental download update, but it will probably cause 
problems if you are trying to install gems with native extensions.  Grab 
version 0.8.11.11 from the beta site to fix that.

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From chad at chadfowler.com  Wed Apr  5 12:27:35 2006
From: chad at chadfowler.com (Chad Fowler)
Date: Wed, 5 Apr 2006 10:27:35 -0600
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <4433E05B.3030703@weirichhouse.org>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>	<442A9DCD.1050402@weirichhouse.org>
	<4432DE97.5090809@weirichhouse.org>
	<4433E05B.3030703@weirichhouse.org>
Message-ID: <075E4DA6-15EC-4FEC-A587-AC152BC9E1C9@chadfowler.com>


On Apr 5, 2006, at 9:20 AM, Jim Weirich wrote:

> I found a bug in the new extension builder portion of RubyGems.  It is
> unrelated to the incremental download update, but it will probably  
> cause
> problems if you are trying to install gems with native extensions.   
> Grab
> version 0.8.11.11 from the beta site to fix that.

Oh cool.  I was going to be investigating today why my Mongrel  
installation was failing yesterday.  As usual, you beat me to it :)

Chad

From jim at weirichhouse.org  Wed Apr  5 12:53:52 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 05 Apr 2006 12:53:52 -0400
Subject: [Rubygems-developers] The replacement for 'require_gem'
Message-ID: <4433F620.9080106@weirichhouse.org>

We've been talking about a replacement for 'require_gem' that does not 
do the auto-requiring.  Several names have been suggested (e.g. 
activate_gem).

Here's what I'm leaning towards:

   require "rubygems"
   gem 'rails', '= 1.0.0'
   gem 'rake', '= 0.7.0.1'
   gem 'activesupport', '= 1.2.5'
   gem 'activerecord', '= 1.13.2'
   gem 'actionpack', '= 1.11.2'
   gem 'actionmailer', '= 1.1.5'
   gem 'actionwebservice', '= 1.0.0'

I like it because I don't have to explain what 'activate' means :)

Comments?

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From aaron_patterson at speakeasy.net  Wed Apr  5 13:04:09 2006
From: aaron_patterson at speakeasy.net (Aaron Patterson)
Date: Wed, 5 Apr 2006 10:04:09 -0700
Subject: [Rubygems-developers] gem building native extensions
Message-ID: <20060405170409.GA28320@eviladmins.lan>

Hi, I'm building a native extention in a gem, and gem seems to be
removing $(target_prefix) from the end of RUBYARCHDIR, and RUBYLIBDIR in
the Makefile.  Because of that, my library doesn't get installed in to
the correct directory.  Is this expected functionality?

I modified gem, to not remove that variable, and my gem installed
properly.  I've included the patch below.

--Aaron

Index: lib/rubygems/installer.rb
===================================================================
RCS file: /var/cvs/rubygems/rubygems/lib/rubygems/installer.rb,v
retrieving revision 1.110
diff -u -r1.110 installer.rb
--- lib/rubygems/installer.rb 5 Apr 2006 14:40:30 -0000 1.110
+++ lib/rubygems/installer.rb 5 Apr 2006 16:57:12 -0000
@@ -570,8 +570,8 @@
       results = []
       raise unless File.exist?('Makefile')
       mf = File.read('Makefile')
-      mf = mf.gsub(/^RUBYARCHDIR\s*=\s*\$.*/, "RUBYARCHDIR = #{dest_path}")
-      mf = mf.gsub(/^RUBYLIBDIR\s*=\s*\$.*/, "RUBYLIBDIR = #{dest_path}")
+      mf = mf.gsub(/^RUBYARCHDIR\s*=\s*\$[^$]*/, "RUBYARCHDIR = #{dest_path}")
+      mf = mf.gsub(/^RUBYLIBDIR\s*=\s*\$[^$]*/, "RUBYLIBDIR = #{dest_path}")
       File.open('Makefile', 'wb') {|f| f.print mf}

       make_program = ENV['make']

From jim at weirichhouse.org  Wed Apr  5 14:04:06 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 05 Apr 2006 14:04:06 -0400
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <20060405170409.GA28320@eviladmins.lan>
References: <20060405170409.GA28320@eviladmins.lan>
Message-ID: <44340696.2010802@weirichhouse.org>

Aaron Patterson wrote:
> Hi, I'm building a native extention in a gem, and gem seems to be
> removing $(target_prefix) from the end of RUBYARCHDIR, and RUBYLIBDIR in
> the Makefile.  Because of that, my library doesn't get installed in to
> the correct directory.  Is this expected functionality?
> 
> I modified gem, to not remove that variable, and my gem installed
> properly.  I've included the patch below.

Patch applied.  New beta now available as 0.8.11.13.  Get it from the 
usual place.

   gem update --system --source http://onestepback.org/betagems

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From chad at chadfowler.com  Wed Apr  5 14:14:56 2006
From: chad at chadfowler.com (Chad Fowler)
Date: Wed, 5 Apr 2006 12:14:56 -0600
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <44340696.2010802@weirichhouse.org>
References: <20060405170409.GA28320@eviladmins.lan>
	<44340696.2010802@weirichhouse.org>
Message-ID: <D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>


On Apr 5, 2006, at 12:04 PM, Jim Weirich wrote:

> Aaron Patterson wrote:
>> Hi, I'm building a native extention in a gem, and gem seems to be
>> removing $(target_prefix) from the end of RUBYARCHDIR, and  
>> RUBYLIBDIR in
>> the Makefile.  Because of that, my library doesn't get installed  
>> in to
>> the correct directory.  Is this expected functionality?
>>
>> I modified gem, to not remove that variable, and my gem installed
>> properly.  I've included the patch below.
>
> Patch applied.  New beta now available as 0.8.11.13.  Get it from the
> usual place.
>
>    gem update --system --source http://onestepback.org/betagems
>


Am I right in thinking that this fixes the age-old extensions bug  
that we've had on the TODO list forever?

I so, Aaron, we owe you a big one.  Even if not :)

Chad

From jim at weirichhouse.org  Wed Apr  5 14:21:37 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Wed, 05 Apr 2006 14:21:37 -0400
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>
References: <20060405170409.GA28320@eviladmins.lan>	<44340696.2010802@weirichhouse.org>
	<D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>
Message-ID: <44340AB1.6070109@weirichhouse.org>

Chad Fowler wrote:
> Am I right in thinking that this fixes the age-old extensions bug  
> that we've had on the TODO list forever?

The bug prevented the extension .so from being installed in a 
subdirectory of lib.  I think that's the bug on the TODO list, so yes, I 
think we (I mean Aaron) fixed it.

Aaron, given this version a try to make sure it works as intended.  I 
don't have a native extension that triggers it handy.

And I echo Chad's thanks!

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From chad at chadfowler.com  Wed Apr  5 14:25:06 2006
From: chad at chadfowler.com (Chad Fowler)
Date: Wed, 5 Apr 2006 12:25:06 -0600
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <44340AB1.6070109@weirichhouse.org>
References: <20060405170409.GA28320@eviladmins.lan>	<44340696.2010802@weirichhouse.org>
	<D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>
	<44340AB1.6070109@weirichhouse.org>
Message-ID: <A6C97641-67D7-4D6E-861C-6B56E147B780@chadfowler.com>


On Apr 5, 2006, at 12:21 PM, Jim Weirich wrote:

> Chad Fowler wrote:
>> Am I right in thinking that this fixes the age-old extensions bug
>> that we've had on the TODO list forever?
>
> The bug prevented the extension .so from being installed in a
> subdirectory of lib.  I think that's the bug on the TODO list, so  
> yes, I
> think we (I mean Aaron) fixed it.
>
> Aaron, given this version a try to make sure it works as intended.  I
> don't have a native extension that triggers it handy.
>
> And I echo Chad's thanks!
>

Aaron, are you coming to RailsConf or RubyConf?  If so, I owe you a  
drink or meal or something.  I had a really convoluted solution in  
mind for this and you found the simple way.  Thanks!

Chad


From aaron_patterson at speakeasy.net  Wed Apr  5 14:31:38 2006
From: aaron_patterson at speakeasy.net (Aaron Patterson)
Date: Wed, 5 Apr 2006 11:31:38 -0700
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <44340AB1.6070109@weirichhouse.org>
References: <20060405170409.GA28320@eviladmins.lan>
	<44340696.2010802@weirichhouse.org>
	<D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>
	<44340AB1.6070109@weirichhouse.org>
Message-ID: <20060405183138.GA28952@eviladmins.lan>

On Wed, Apr 05, 2006 at 02:21:37PM -0400, Jim Weirich wrote:
> Aaron, given this version a try to make sure it works as intended.  I 
> don't have a native extension that triggers it handy.
> 
> And I echo Chad's thanks!
> 

I just installed version 0.8.11.13, and it worked great!  Thanks for
taking my patch, and I'm glad I could help out.

--Aaron


From aaron_patterson at speakeasy.net  Wed Apr  5 17:17:48 2006
From: aaron_patterson at speakeasy.net (Aaron Patterson)
Date: Wed, 5 Apr 2006 14:17:48 -0700
Subject: [Rubygems-developers] gem building native extensions
In-Reply-To: <A6C97641-67D7-4D6E-861C-6B56E147B780@chadfowler.com>
References: <20060405170409.GA28320@eviladmins.lan>
	<44340696.2010802@weirichhouse.org>
	<D120CC50-9CDD-4E09-AC2D-98747F5C35FC@chadfowler.com>
	<44340AB1.6070109@weirichhouse.org>
	<A6C97641-67D7-4D6E-861C-6B56E147B780@chadfowler.com>
Message-ID: <20060405211748.GA29589@eviladmins.lan>

On Wed, Apr 05, 2006 at 12:25:06PM -0600, Chad Fowler wrote:
> Aaron, are you coming to RailsConf or RubyConf?  If so, I owe you a  
> drink or meal or something.  I had a really convoluted solution in  
> mind for this and you found the simple way.  Thanks!
> 
> Chad
> 

I'm actually going to the Canada on Rails conference next week.  I'm not
sure about RailsConf or RubyConf.  I'd like to go if I can get work to
pay for it, but for now Vancouver is much closer to Seattle.  :-)

Also, I have a rubyforge account and I'd be happy to help you want or
need people.

--Aaron


From gregory.t.brown at gmail.com  Thu Apr  6 15:53:34 2006
From: gregory.t.brown at gmail.com (Gregory Brown)
Date: Thu, 6 Apr 2006 15:53:34 -0400
Subject: [Rubygems-developers] The replacement for 'require_gem'
In-Reply-To: <4433F620.9080106@weirichhouse.org>
References: <4433F620.9080106@weirichhouse.org>
Message-ID: <b37300880604061253h3d41ebads5b5a141cc6b0febe@mail.gmail.com>

On 4/5/06, Jim Weirich <jim at weirichhouse.org> wrote:
> We've been talking about a replacement for 'require_gem' that does not
> do the auto-requiring.  Several names have been suggested (e.g.
> activate_gem).
>
> Here's what I'm leaning towards:
>
>    require "rubygems"
>    gem 'rails', '= 1.0.0'
>    gem 'rake', '= 0.7.0.1'
>    gem 'activesupport', '= 1.2.5'
>    gem 'activerecord', '= 1.13.2'
>    gem 'actionpack', '= 1.11.2'
>    gem 'actionmailer', '= 1.1.5'
>    gem 'actionwebservice', '= 1.0.0'
>
> I like it because I don't have to explain what 'activate' means :)
>
> Comments?

use_gem ?

use_gem 'rake'

Otherwise, just gem sounds okay.


From jim at weirichhouse.org  Fri Apr  7 16:03:24 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Fri, 07 Apr 2006 16:03:24 -0400
Subject: [Rubygems-developers] Update on Testing for Gems 0.9.0 Beta
In-Reply-To: <4433E05B.3030703@weirichhouse.org>
References: <018a01c63975$c77db8e0$1301a8c0@tomhplaptop>	<442A9DCD.1050402@weirichhouse.org>	<4432DE97.5090809@weirichhouse.org>
	<4433E05B.3030703@weirichhouse.org>
Message-ID: <4436C58C.4040904@weirichhouse.org>

Jim Weirich wrote:
> I found a bug in the new extension builder portion of RubyGems.  It is 
> unrelated to the incremental download update, but it will probably cause 
> problems if you are trying to install gems with native extensions.  Grab 
> version 0.8.11.11 from the beta site to fix that.

I haven't been calling out every version, but I've been making several 
bug fixes and minor enhancements over the past few days.  If you picked 
up a beta version earlier, you might want to grab the latest version. 
Recent fixes include adding a --[no]-ri option to install/update/rdoc 
commands (e.g. if you don't want RI docs, add a --no-ri option to the 
command line).  Also several fixes to native extension building.  The 
'gem' method replacement for 'require_gem' is now enabled.  Also, I 
reintroduced optional arguements to the SourceIndex.from_installed_gems 
command so that the Mongrel GemPlugin would continue to work. (the 
arguments were removed in a code cleanup refactoring a while back).

As always, let me know if anyone has any problems.

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From jim at weirichhouse.org  Mon Apr 10 15:03:11 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Mon, 10 Apr 2006 15:03:11 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
Message-ID: <443AABEF.6020104@weirichhouse.org>

I've not heard any complaints about the incremental downloading feature, 
so its time to start thinking about what needs to be done for a 0.9.0 
release.

Of the outstanding features, the one I really think that needs to be in 
0.9.0 is something to address the datadir issue.  I think everyone has 
agreed that something needs done, I'm not sure we have agreement on what 
that something is.

So, to get the ball rolling, I'll make a proposal.

DATADIR PROPOSAL:
If a gem has a directory named 'data', then at installation time the 
contents of that directory will be copied into Config::CONFIG['datadir'] 
(which is configured to be /usr/local/share on my system).

Here's some points to ponder:

(1) This is exactly what setup.rb does today.  This allows one directory 
  structure to be used for either gem or setup.rb usage.  This reaffirms 
are commitment to be setup.rb compatible.

(2) The data directory is easy to find, just use:

     require 'rbconfig'
     DataDir = File.join(Config::CONFIG['datadir'], 'mygemname')

(3) This works without any changes to the gemspec format, which means 
eliminates the problems of integrating new gemspec formats with old 
versions of the gem command.  A big win here.

(4) What happened to versioning the data directory?  Well, good 
question.  The problem is that there isn't a single data dir policy that 
will work for everybody.  Some projects might need data versions in lock 
step with the gem version.  Other projects might choose to version the 
data dir data structures in a separate versioning scheme.

By keeping with the simple solution above, we allow users to implement 
whatever schemes work best for them.  The key is to make sure gems 
doesn't get in the way.

(5) Note that the data directory gets copied directly into the share 
area.  This means that the users should put their data in a subdirectory 
of data tagged with their gem name:  Example:

      data/mygemname/stuff.data

(5a) Just a side note that if users want data versioning, they can do it 
  themselves with:

     data/mygemname/V2/stuff.data

(6) What about an uninstall policy?  I am suggesting by default, gems 
will not remove data from the data directory.  But, I'm willing to 
entertain an option on the uninstall command that would also uninstall 
the data.  Comments?

(7) On a related note, if the data already exists in the shared 
directory, should an install copy new files on top of that?  I'm 
thinking yes, but I'm not sure.

Ok, that's enough for now.  Feedback welcome.

-- 
-- Jim Weirich       jweirich at one.net      http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From halostatue at gmail.com  Mon Apr 10 15:50:33 2006
From: halostatue at gmail.com (Austin Ziegler)
Date: Mon, 10 Apr 2006 15:50:33 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <443AABEF.6020104@weirichhouse.org>
References: <443AABEF.6020104@weirichhouse.org>
Message-ID: <9e7db9110604101250q12730facgdb337c5aa3a76084@mail.gmail.com>

On 4/10/06, Jim Weirich <jim at weirichhouse.org> wrote:
[snip proposal]
Jim, I think I can live with this *if* RubyGems starts using its tarcapabilities a little smarter than it currently does and allows me tospecify some of this in the gemspec.
If you look at the tarring that I do in the PDF::Writer Rakefile(actually, all of my rakefiles now), I *dynamically* determine theappropriate directory and set things appropriately in my .tar.gz files.What I want here is to have my images/ and data/ directories where theybelong in my SCM tree but dynamically name them to data/gem-1.3/images/and data/gem-1.3/data/ in the .gem file. Maybe:
  spec.datadirs = %w(images data)  spec.version_datadir = true
Alternatively, allow me to provide a proc -- similar to what you see inmy PDF::Writer Rakefile -- that will do all sorts of renaming from theperspective of the gem directory on down. I would actually prefer both;this way I could version some data without versioning other data.Alternatively:
  spec.datadirs = %w(images)  spec.versioned_datadirs = %w(data)
To make this work without this sort of transparent transformation, I'dhave to copy my files to a staging directory, move the directoriesaround, and then gem package. I would no longer be able to cleanly buildall of my packages from a single source and my Rakefile would double insize pretty quickly.
I think that having spec.datadirs and spec.versioned_datadirs makes itpretty easy to deal with from all perspectives.
-austin--Austin Ziegler * halostatue at gmail.com               * Alternate: austin at halostatue.ca

From aslak.hellesoy at gmail.com  Mon Apr 10 18:35:16 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 10 Apr 2006 17:35:16 -0500
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <443AABEF.6020104@weirichhouse.org>
References: <443AABEF.6020104@weirichhouse.org>
Message-ID: <8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>

> DATADIR PROPOSAL:
(snip)

This would be awesome. I have a couple of gems that would like to
write to file - and this would make things a lot easier for me and the
users of my gems.

Thanks,
Aslak


From halostatue at gmail.com  Mon Apr 10 20:00:37 2006
From: halostatue at gmail.com (Austin Ziegler)
Date: Mon, 10 Apr 2006 20:00:37 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>
References: <443AABEF.6020104@weirichhouse.org>
	<8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>
Message-ID: <9e7db9110604101700k5f5d3130i78b3db862588f293@mail.gmail.com>

On 4/10/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:> > DATADIR PROPOSAL:> (snip)> This would be awesome. I have a couple of gems that would like to> write to file - and this would make things a lot easier for me and the> users of my gems.
This is not what the datadir should be used for. On some platforms,especially Debian-based distributions, the datadir will probably beread-only to most users.
In Ruwiki, I would use this for the versioned read-only documentationwiki. In PDF::Writer I would use this for versioned documentation andnon-versioned font data.
But the data *must* be considered read-only if it's in datadir.
-austin--Austin Ziegler * halostatue at gmail.com               * Alternate: austin at halostatue.ca

From transfire at gmail.com  Mon Apr 10 20:16:46 2006
From: transfire at gmail.com (TRANS)
Date: Mon, 10 Apr 2006 20:16:46 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <9e7db9110604101700k5f5d3130i78b3db862588f293@mail.gmail.com>
References: <443AABEF.6020104@weirichhouse.org>
	<8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>
	<9e7db9110604101700k5f5d3130i78b3db862588f293@mail.gmail.com>
Message-ID: <4b6f054f0604101716v70b3fb1en1d500d0162e24787@mail.gmail.com>

While I think the proposal is probably the right one, just to draw
soem contrast the other option is to keep the datadir in the gem and
provide access to it, eg.

  Gem.datadir( 'mygemsname' )

Note, along with datadir, there is also confdir (etc/) and what about
var/, what's the map to?

Also how does this work with regards to Windows?

T.


From halostatue at gmail.com  Mon Apr 10 20:43:50 2006
From: halostatue at gmail.com (Austin Ziegler)
Date: Mon, 10 Apr 2006 20:43:50 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <4b6f054f0604101716v70b3fb1en1d500d0162e24787@mail.gmail.com>
References: <443AABEF.6020104@weirichhouse.org>
	<8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>
	<9e7db9110604101700k5f5d3130i78b3db862588f293@mail.gmail.com>
	<4b6f054f0604101716v70b3fb1en1d500d0162e24787@mail.gmail.com>
Message-ID: <9e7db9110604101743n337cd50cvd1e086f97046504b@mail.gmail.com>

On 4/10/06, TRANS <transfire at gmail.com> wrote:> While I think the proposal is probably the right one, just to draw> soem contrast the other option is to keep the datadir in the gem and> provide access to it, eg.>>   Gem.datadir( 'mygemsname' )>> Note, along with datadir, there is also confdir (etc/) and what about> var/, what's the map to?>> Also how does this work with regards to Windows?
It will work just fine. There is no meaningful map for etc/ and var/, though.
-austin--Austin Ziegler * halostatue at gmail.com               * Alternate: austin at halostatue.ca

From jim at weirichhouse.org  Tue Apr 11 02:24:59 2006
From: jim at weirichhouse.org (Jim Weirich)
Date: Tue, 11 Apr 2006 02:24:59 -0400
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <4b6f054f0604101716v70b3fb1en1d500d0162e24787@mail.gmail.com>
References: <443AABEF.6020104@weirichhouse.org>	<8d961d900604101535q2ea40768w827069bc0c76b6ab@mail.gmail.com>	<9e7db9110604101700k5f5d3130i78b3db862588f293@mail.gmail.com>
	<4b6f054f0604101716v70b3fb1en1d500d0162e24787@mail.gmail.com>
Message-ID: <443B4BBB.9050804@weirichhouse.org>

TRANS wrote:
> While I think the proposal is probably the right one, just to draw
> soem contrast the other option is to keep the datadir in the gem and
> provide access to it, eg.
> 
>   Gem.datadir( 'mygemsname' )

The disadvantage of this approach is that it then requires the software 
to be installed as a gem to run.  If the Config::CONFIG['datadir'] value 
is used, you don't have any dependencies on gems.

Also, anything in the gem directory must also be considered read-only by 
the application (just like datadir).

-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

From hgs at dmu.ac.uk  Tue Apr 11 05:29:31 2006
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Tue, 11 Apr 2006 10:29:31 +0100 (WEST)
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <443AABEF.6020104@weirichhouse.org>
References: <443AABEF.6020104@weirichhouse.org>
Message-ID: <Pine.GSO.4.64.0604110958410.1061@brains.eng.cse.dmu.ac.uk>

On Mon, 10 Apr 2006, Jim Weirich wrote:

> I've not heard any complaints about the incremental downloading feature, 
> so its time to start thinking about what needs to be done for a 0.9.0 
> release.

Too much going on for me to experiment with that just now...
        [...Datdir...]
> So, to get the ball rolling, I'll make a proposal.
> 
> DATADIR PROPOSAL:
> If a gem has a directory named 'data', then at installation time the 
> contents of that directory will be copied into Config::CONFIG['datadir'] 
> (which is configured to be /usr/local/share on my system).

OK, but presumably something below that....  Would one keep gems separate
from non-gems in there?  I.e., have a .../gems/... directory?  One may 
have several versions of a gem installed, which is not possible for
some packages.

> 
> Here's some points to ponder:
> 
        [...]
> 
> (4) What happened to versioning the data directory?  Well, good 
> question.  The problem is that there isn't a single data dir policy that 
> will work for everybody.  Some projects might need data versions in lock 
> step with the gem version.  Other projects might choose to version the 
> data dir data structures in a separate versioning scheme.

What sort of other versioning policies might there be?
Unless there's a good reason for other policies, I'd tend to want to
stick with one policy.  Less branching in code to support, less
places to look for things.  Also, tying it to the version of the gem
allows more than 1 gem version to be installed, facilitates
uninstall.  In short, I fail to see the need for a separate
versioning scheme.

> (5a) Just a side note that if users want data versioning, they can do it 
>   themselves with:
> 
>      data/mygemname/V2/stuff.data

Which seems like 4 to me, but I'd go for
data/gems/wossname-3.5.1/stuff.dat
> 
> (6) What about an uninstall policy?  I am suggesting by default, gems 
> will not remove data from the data directory.  But, I'm willing to 
> entertain an option on the uninstall command that would also uninstall 
> the data.  Comments?

We (by which I mean the machines I manage) need this.  It is usually
a struggle to get people to invest in new hardware ("But we bought you
a fast server only 5 years ago!") so our disks are smaller than we'd
like.  We have a need to uninstall things completely to save the space
we have.  Trying to figure out what we need to keep and what we can
afford to chuck out would be exacerbated by allowing arbitrary versioning
policies for data directories.  

> 
> (7) On a related note, if the data already exists in the shared 
> directory, should an install copy new files on top of that?  I'm 
> thinking yes, but I'm not sure.

Well, if /usr/share is on one filesystem, one could use hard links
within the different version directories.  SHA-256 should be sufficient
to check the files are identical. [??]  For symlinks, keep the original
files in the newest directory, and put the links in the old ones
(cf how data is stored in CVS -- differences take you back not forward).
Then if the old dir is trashed manually we are still OK.

> 
> Ok, that's enough for now.  Feedback welcome.
> 
        Hope that's useful...
        Hugh

From drbrain at segment7.net  Tue Apr 11 14:47:39 2006
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 11 Apr 2006 11:47:39 -0700
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <443AABEF.6020104@weirichhouse.org>
References: <443AABEF.6020104@weirichhouse.org>
Message-ID: <A0A3D46D-B141-4DCE-848C-CBB31A90FF7F@segment7.net>

On Apr 10, 2006, at 12:03 PM, Jim Weirich wrote:

> (6) What about an uninstall policy?  I am suggesting by default, gems
> will not remove data from the data directory.  But, I'm willing to
> entertain an option on the uninstall command that would also uninstall
> the data.  Comments?

FreeBSD hangs onto MD5 checksums for all port/package installed files  
and only removes files where the MD5 checksum matches.

Unfortunately this isn't a complete solution, if you install two  
copies of the same package and the files didn't change extra stuff  
can get deleted...

Gems could, check if the installed file is in more than one manifest.

-- 
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com



From grant at antiflux.org  Fri Apr 14 18:02:29 2006
From: grant at antiflux.org (Grant Hollingworth)
Date: Fri, 14 Apr 2006 16:02:29 -0600
Subject: [Rubygems-developers] The next step toward 0.9.0
In-Reply-To: <443AABEF.6020104@weirichhouse.org>
References: <443AABEF.6020104@weirichhouse.org>
Message-ID: <20060414220229.GA8830@okcomputer.antiflux.org>

* Jim Weirich <jim at weirichhouse.org> [2006-04-10 13:05]:
> If a gem has a directory named 'data', then at installation time the 
> contents of that directory will be copied into Config::CONFIG['datadir'] 
> (which is configured to be /usr/local/share on my system).

Is there any interest in the configuration patch I posted about a month
ago?   I have systems where the Config::CONFIG values are not what I
want used for RubyGems.

http://rubyforge.org/pipermail/rubygems-developers/2006-March/001911.html

From spam-debian at udev.org  Thu Apr 20 22:28:44 2006
From: spam-debian at udev.org (Antony Lesuisse)
Date: Fri, 21 Apr 2006 04:28:44 +0200
Subject: [Rubygems-developers] Is it a bug ? line 143 of
	lib/rubygems/gem_commands.rb
Message-ID: <4448435C.8070009@udev.org>

Shouldn't it be GEM_HOME ?

TIA

--- rubygems-0.8.11.orig/lib/rubygems/gem_commands.rb 

+++ rubygems-0.8.11/lib/rubygems/gem_commands.rb 

@@ -143,7 +143,9 @@ 

      end 

 

      def execute 

-      ENV['GEM_PATH'] = options[:install_dir] 

+      # bug ? 

+      # ENV['GEM_PATH'] = options[:install_dir] 

+      ENV['GEM_HOME'] = options[:install_dir] 

        # TODO: If a dependency isn't met, first check to see if it's in 

        # the install list 

        if(options[:args].empty?) 



From transfire at gmail.com  Fri Apr 21 21:54:25 2006
From: transfire at gmail.com (TRANS)
Date: Fri, 21 Apr 2006 21:54:25 -0400
Subject: [Rubygems-developers] Problem building gem without loading gem
	reuqire system.
Message-ID: <4b6f054f0604211854i50766420ud0e66e21bec7ed66@mail.gmail.com>

Hi,

I've created a script for automating the building a gem, among other
things, but I have to use

  require 'rubygems'

in the script to make it work. Unfortuately that causes Gems to take
control of the require mechanism  and thus the script can't be run in
such a way as to bypass the Gems system --i.e. a manual install
overriding a gems install.

How can this be fixed?

Thanks,
T.


From transfire at gmail.com  Fri Apr 21 22:06:42 2006
From: transfire at gmail.com (TRANS)
Date: Fri, 21 Apr 2006 22:06:42 -0400
Subject: [Rubygems-developers] Problem building gem without loading gem
	reuqire system.
In-Reply-To: <4b6f054f0604211854i50766420ud0e66e21bec7ed66@mail.gmail.com>
References: <4b6f054f0604211854i50766420ud0e66e21bec7ed66@mail.gmail.com>
Message-ID: <4b6f054f0604211906q3ecec9cfsfe7224001a82dba4@mail.gmail.com>

On 4/21/06, TRANS <transfire at gmail.com> wrote:
> Hi,
>
> I've created a script for automating the building a gem, among other
> things, but I have to use
>
>   require 'rubygems'
>
> in the script to make it work. Unfortuately that causes Gems to take
> control of the require mechanism  and thus the script can't be run in
> such a way as to bypass the Gems system --i.e. a manual install
> overriding a gems install.
>
> How can this be fixed?

Never mind. That's not quite the issue. A require was failing in the
mainual installaton which was feeding back to Gems and causing it to
subsequently load from the gems repository instead --a strange quark
of the Gems system, but not a show stopper.

T.