Austin Ziegler wrote:
> > Gems doesn't support a DATA dir at the moment. Of course they are
> > working on it and fitting it into the Gems "philosophy" --which is
> > that everything is stored in gems and the outside looks there for its
> > needs.
>
> This isn't quite correct.

How so? Gems even caches data to the gems lib directory.

> > For example, a BIN file actually is a kind of stub that requires a
> > file from its gem.
>
> This is a stub, but it's a versioning stub. That is, the stub is aware
> of versions installed and as such you only have to have a single stub
> installed to be able to run multiple versions of a program offered by
> Gems.

Ah, the _1.0_ version parameter (I couldn't find any documentation on
this btw). I suppose that's no worse or better then symlinks. Still its
a rather trival thing fo rthe end programmer to do If they want. What
troubles me is that a manual install with setup.rb is gogin to be
different the a gems install --probably not a big deal in this case
(though I imagine thjere are edgecases, $0 comes to mind), but it does
illustrate how Gems alters things.

> > One of the problems with this, besides that it really irks other
> > distribution managers b/c it poopoos on their philosophies, is that it
> > adds Gems' versioning to all of it. So now you have not only versioned
> > libs, but bins and data too.
>
> This is actually valid. If you read my statement to Jim Weirich on
> ruby-core, you would have noted that at least for Ruwiki and
> PDF::Writer, I *require* versioned data, not just version-independent
> data. However, the bin versioning isn't the case as I outlined above.

The put the data with the lib. Why should it not be there if it is
versioning along with the lib. Why are .rb files special? What makes my
data and program different. lispers would tell you otherwise. The data
could just as well be encodded in Ruby. So what's the justification of
putting it elsewhere?

> > So I've been thinking about this and I've come to the conclusion that
> > all versioning belongs to the LIB only!
>
> This is incorrect, as noted above. Versioning can be applied to either
> data or libs.

Sure, but my point is then why separate them?

> Um. I suspect that data versioning -- and remember we're talking about
> "central" data, here, not user data -- is more important than you think.
> If I change data formats and want people to be able to have both v2 and
> v3 of my lib, they need to have *both* datafiles present, even if
> they're named the same.

Right. I'm not saying any different.

> > Consider the bin dir. Gems' use of wrapping the exe is clever but is
> > rather useless with regards to versioning. How are you going to tell
> > the exe to use a different version? ... So it's up to the designer of
> > the exe to add that if he really wants it, manually writing a stub is
> > easy enough, or somehthing that has a "--ver" option. Gems can't really
> > help.
>
> Actually ... gems *does* handle it properly. Read the stubs that are in
> your bin dir.

You are right, I miss spoke here. The "_1.0_" paramter allows it, I
hadn't seen anything written up about this. It's a bit of an ugly hack,
but it does the job. Nonetheless, my point here is really that can be
trival for an end programmer to implement and then they have greater
control over it themselves.

> > As for the data dir, what does it really matter is if the data is in
> > with the lib or outside?
>
> This is where the Debian (and FreeBSD and ...) folks would disagree with
> you, and I would by and large be inclined to agree. I'm told that Ruby
> Gnome support is a particular mess for this.


Ha! Ha! That's funny. You're argeesing with them now? Well, I don't see
why. I was agreeing with you!

> > In conclusion I think Gems is over-engineered. Tightly tying a
> > versioning distribution manager to Ruby's library require mechanics is
> > too much. And b/c of this will ultimately be bad for Ruby.
>
> This is not a logical conclusion from your arguments, and it's certainly
> not logical from the misinformation involved with your arguments. I
> believe that it is precisely that versioning that makes RubyGems
> *desirable* because there's nothing else even remotely suitable, and API
> versioning is something that the *language* needs to deal with, not the
> operating system.

Sure it does, though admittedly I didn't fill in all the little steps
along the way. An what misinforamation, I had ONE fact wrong. They rest
are essentially opinion --which can't be misinformation. I'm not
arguing against versioning, just the particular approach. And I agree,
with you last stament here. But I might go further and say that the
language shouldn't limit versioning to a package distribution system.
If I want to do versioning but not use Gems how is Ruby going to help
me? Make Gems integral to Ruby and Gems becomes the only way.
VERSIONING SHOULD NOT BE TIED A PACKAGE DITRIBUTION MANGER.

> > I believe a better solution may simply be to extend require to provide
> > optional parameters, among them special version constraints and then
> > Ruby can look for libs following a simple convention of appending
> > version to the lib dir name.
>
> I've already argued that "require 'foo-1.0'" is inappropriate (as well
> as Ugly). This means that I am *always* fixed to a particular version
> number in an application, rather than possibly getting a compatible
> sub-version, as with RubyGems possible future capability:

You know what, the "ugly" arguments doen't fly here. I don't think its
ugly. I think it looks fine. And you're later starement is simply not
true. You're thinking inside the box. The require statment can be
adjusted to do the version lookup. By your reasoning Gems itself
wouldn't work.

> Sorry, but appending version to the lib dir name is completely
> inappropriate and an utter mess. It looks stupid, too.
>
> > So all versioned material goes in the lib, the rest remains version
> > free. It's a simple convetion, although not ideal in some minor
> > respects, it's simple and effective.
>
> It's not ideal in major respects. It's also neither simple nor effective
> for the reasons noted above.

What reasons? You haven't given any facts or rational explination of
your opinions except a single incorrect one. "stupid" and "ugly" are
not helpful.

T.