Austin Ziegler wrote:

> That doesn't bother me at all. If you install with gems, you get
> additional features. If you don't, you don't.

Fine. And say I use system X to get similar features. Then what? Will
Gems play nice? If Gems goes into core will that still fly? It becomes
a problem, because Gems has hijacked #require. So it's Gems Way or no
way, but it needs to be the Ruby Way or no way --which I think is
broader then what Gems is proposing.

> As I said above, it is the fact that the data is *with* the lib that
> drives the repackagers nuts. I don't have as big an issue with it -- I
> use that right now.

Just wrap it in an .rb file, they won't know the difference ;) Hey,
Lisp guys do it all the time!

But on this topic BTW, I find it interesting that Ruby libs are
installwed to a special site_ruby dir but data files that go with them
are put right into /usr/share, or what have you, with every thing else.
Seems to me this bolsters my point about shared data having a life of
it's own. But I also wonder, does site_ruby exist simply so Ruby knows
were to look for libs?

> Hmm. I *would* like to be be able to specify a stub that gets installed
> rather than the default, but I think that the existing stub is
> sufficient for most peoples' purposes.

For most it is. But I agree with you. I think it's better just have a
little tool that can do this for you. Say you put a bin/ subdir in your
lib/ dir and a script wraps it automaically and puts it in /bin for
you, or something like that.

> I agree with them that there needs to be an API to get at the data
> cleanly. Simply doing data relative to File.dirname(__FILE__) is ...
> fragile. I disagree with them on other points.

Well, that's easy enough. And I agree. __FILE__ just looks hackish to
begin with.

> Um. Sorry, but do you actually have a solution that works, then? One
> that *doesn't* tie versioning to package management? The idea of *not*
> having the two pieces together is a bit silly, at that, as package
> management is centrally about versioning, and API version management is
> lacking in every language that *I* know (and that's quite a few). This
> really does offer Ruby an opportunity to tie things together that work
> well.

In fact, I may have a possible solution. And you are right, it is an
oppurtunity for Ruby, but one that should be considered extremely
carfully.

> Oh, bollocks. The "ugly" argument flies quite well, especially when
> we're talking about a language that we both consider quite beautiful,
> although apparently for different reasons.

A wise Rubyists, once said "just don't look there". This applies here
as well. Your doing it aready if you really think about it.
Nonetheless, feel free to develop without the version in place and
simply append it upon distribution --you never have to see it.

> You can accuse me of thinking inside of the box, but the reality is that
> both of these problems are interrelated -- and RubyGems is suited
> perfectly for the combined problem.

RubyGems addresses the problem. But perfectly?

While we want the the package manager to know about versions in order
to handle dependencies, the package manager doesn't need to dictate how
the API handles version constraint. (Imagine if apt-get tried that!)
Yet few ever really try to add API versioing to the software b/c they
assume it has to be the package manages domain, not theirs. Catch-22.

> "Incorrect." Sorry, it's not incorrect -- if I have to do:
>
>   require 'foo-1.0'
>
> I have tied myself irrevocably to version 1.0. If I can do
>
>   require 'foo'
>
> Then I'll get whatever the latest version is installed. If I can do:
>
>   require 'foo', '~> 1.1'
>
> Then I'll get the various versions as indicated. This is *best* handled
> by something that doesn't actually have to scan *directories* to see if
> there's an appropriate version, but can scan a quick database of
> installed packages ... just like RubyGems does.

Come on! Gems can do it but nothing else can? That's exactly what I
meant by inside the box. Require can be adjusted to handle the version
appendege and you know it. Isn't that essentially what Gems does?
Except the libs are tucked away in another specail gems directory. So
you got your *ugly* versioned directory names after all, you just don't
look there!

> Package managers *always* have to do version management. The only
> difference between RubyGems and other package managers is that Chad,
> Jim, and the others who designed it also decided to handle API
> versioning *at the same time*, since the API version and the package
> version are often closely related.

I can understand that. They came at from on end and went on down. Now
consider it from the other end and work your way up. That's a more
interesting appraoch b/c it gets you to deal with API versioning first
and thus automatically makes it independent of the
packaging/installation mechinism.

> Again, if you can point me to a solution that is *easy* and *not ugly*,
> I'll evaluate it and, if appropriate, champion it. RubyGems solves two
> major problems for Ruby, and I think it solves it elegantly.

To be honest I think RubyGems is pretty cool too. But I can't be
comfrotable unless  John Doe can install his wares with a tar.gz or
..zip or apt-get or whatever and still take advantage of API versioning.
That should be the goal and the opporunity. Installing software is
realtively easy, doing the above is where the challenge lies.

T.