From: Austin Ziegler <halostatue@...>
Date: 2005-11-20T06:44:15+09:00
Subject: Re: An alternative to Gems

On 11/19/05, Trans <transfire@gmail.com> wrote:
> As I've mentioned before, I am concerned about Ruby becoming tied to
> RubyGems.

Yes, you have. I, however, am not. I think you're worried about nothing.

> I am concerned because I think Gems overly complicates Ruby's
> require mechanism, making it less efficient than it needs to be and
> sometimes causing unexpected load behaviors.

I think that it is less complex than the mess that you have tried to
introduce with Facets.

> Even more worrisome to me
> though is that Gems ties require versioning (and some of it's other
> benefits) to *package distribution*.

A tiny speck of thought about this would actually make it quite clear
that this is the only sane way to approach the problem (e.g., making
it so that packaging and versioning *work together*). I have yet to
see anyone else propose anything that is remotely reasonable in any
way.

> B/c of this I fear Gems will
> become the ONLY acceptable way to distribute Ruby software --indeed, it
> already seems to be doing so. Maybe some people want that, but I fear
> it locks Ruby in too much, and stiffles any future innovation in the
> distribution area.

Doubtful.

> For these reasons I'm inquiring into the support that may exist for
> doing things a little differently.  I believe it would be better if
> Ruby itself simply elaborated on its #require method (and #load method
> of course) to handle versioned directory tiers. Then simply by adding a
> version tier to a project's lib/ path versioning would be supported --
> independent of any distribution mechinism. To be clear, what I mean is
> instead of this:

What you're asking for is a half-assed barely-considered approach that
doesn't even address the a single problem that people legitimately
have with RubyGems. It's nonsense.

> One would put:
>
>   myproject/
>     lib/
>       myproject/
>         1.0.0/
>           myfile.rb
>
> So even setup.rb can be used just as it always has and versioning would
> be supported.

Ah. Please, litter my system with all kinds of garbage that isn't
cleanly tied together! What you have proposed has exactly *zero*
advantage over RubyGems and probably has several disadvantages, not
least of which putting the versioning *completely* out of Ruby's
hands, which is the problem that is trying to be solved in the first
place.

> I want to make clear that I am not wishing away Gems in this, I like
> Gems and think is makes a great package manager for Ruby. I simply
> think the versioning should not be dependent on Gems. And Gems could be
> adapted to work with the above system too.

I hope not, because what you've described is nonsense.

> So I'd like to know if others would be in support of this approach as I
> have already written a system to do exactly this. The system deals with
> all the details that arise doding this and adds some additional
> benefits, but the above is heart of the matter. The system is nearly
> ready for release. I am down to completing thread safety and
> solidifying the exact require interface that will support it.
>
> So what do you think? Anything you'd like me to clarify? Is there
> support out there for pursuing this approach?

Yeah -- if you really want to propose an alternative, code it. No,
really. Sit down and code it out. Start finding out what the problems
with your approach would be. I'm *really* tired of people being lazy
backseat drivers to the problems that the RubyGems team has *solved*.
If you don't like what RubyGems does, provide something else as a
reasonable alternative.

Otherwise, STFU. Please.

-austin
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca