[Rubygems-developers] Re: [ANN] dev-utils v1.0

Eivind Eklund eivind at FreeBSD.org
Mon Oct 11 09:48:40 EDT 2004

On Mon, Oct 11, 2004 at 08:35:14AM -0400, Chad Fowler wrote:
> On 11-Oct-04, at 8:02 AM, Eivind Eklund wrote:
> >On Mon, Oct 11, 2004 at 07:39:28AM -0400, Chad Fowler wrote:
> >>Thanks for the long and detailed note.  As I said previously in this
> >>thread, we plan to fix our rather naive install.rb, so some of your
> >>pains should go away with the next rubygems release.
> >
> >Might it be feasible to use the RPA install.rb as base here?  
> >(Mauricio,
> >you've probably got a better idea of the differences here than
> >anyone...)  This might signify adding some more policy to RubyGems,
> >requiring an internal directory structure a la setup.rb, but I
> >think that would be good in general - something like that will be
> >necessary to be able to handle policy for native package conversions,
> >anyway.
> >
> >And having a shared codebase here should be of benefit to everyone -
> >less duplicated work, less "random" divergence.
> These are interesting ideas, but I think I was unclear when I was 
> talking about "install.rb".  I meant the installer for the RubyGems 
> library itself.  It sounds like you're talking about the actual gem 
> installer that gets invoked when "gem install" is called?


> It would be interesting to see if the codebase for a large part of the 
> infrastructure could be shared.  I was disappointed when I learned that 
> RPA wasn't going to use RubyGems as its package manager.  Of course, 
> there are philosophical differences that would either need to be worked 
> out or avoided.  I wonder how much of the core of these systems could 
> be the same, without the philosophical issues getting in the way.

I think they to a very large degree could be.  The reason for I
recommended separate a package management technology for RPA was that I
see it as a fairly ambitious project in itself.  Relying on a package
manager that is not controlled by the project results in non-mallable
technology for a very core part of the requirements, and this was a
momentum-risk I saw as unacceptable (ie, very likely to kill the project
at some stumbling block due to differences between RPA priorities and
the RubyGems or other packaging technology priorities.)

However, this is fully compatible with sharing a lot of base source code
or sharing a version control repository.   Ideally, I'd see RPA and
RubyGems being developed in the same repository, with a comprehensive
set of functional tests for each (as well as unit tests for code), and
then have them refactored to use as much common code as possible.

Even more ideally, I'd like this repository to be somewhere where people
can put their projects so this could be done cross more or less all
public Ruby projects.  We (the Ruby Production Junta) been throwing some
ideas around for how to make this work (I've also been throwing some
ideas with Tom Copeland a while ago.)

> For example, we're going to continue to support multiple versions of
> libraries.  I don't see that changing at any point.

I predict pain around the 2000-packages point and up.


More information about the Rubygems-developers mailing list