From: Chris Morris <chrismo@...>
Date: 2002-09-10T08:27:27+09:00
Subject: Re: Multiple .rb versions support

> You could also look at how linux distributions version their .so
> files. It's been used and working much longer than .NET has been
> around. (Although the linux way somewhat depends on the fs sanely
> supporting symlinks.)

... and I'm a Windows-er primarily, so perhaps this wouldn't work. Dunno,
I'll take a look. (.NET is a similar approach to what I've put together.
There's more to it, but they also have an explorer plug-in that presents a
flat file view of the hierarchy).

> Instead of implicit naming schemes in the file path, maybe you should
> just add an optional parameter or two to require (or introduce
> vrequire).

It was probably buried in my original post, but I was interested in seeing
what a solution would look like that would not require a new require or an
altered one. I know one of the strengths of Ruby is being able to redefine
or tack on our own behavior here, and ultimately I'm pretty sure this would
be a better solution ... but I just wanted to see what could be done with
the current require and see how feasible a solution it would be.

With a custom require, then each file would need to require the custom
require library first. So, from that point of view, which is simpler?

require 'verrequire'
vrequire 'lib', AT_LEAST, 1.5

or

require 'lib/1.5'

It seems in this one case, the latter is more straightforward, but it's also
less clear. Does it mean exactly 1.5 or at least? On the other hand do I
want to type "require 'verrequire'" at the top of every file I use? And if
ship this off to someone else, I've got one more thing to install. Is that a
big deal? Eh, could be, may not matter at all if I'm already installing
other supporting files.

> I'm still not sure its worth the work.  How would you resolve libraries
> depending on libraries of conflicting versions?  Wouldn't the module
> and class constants from different versions collide?

You mean if
 A -> B
 A -> C
 B -> D v.1
 C -> D v.2

That would be a problem ... but that would be a problem regardless of what
version loading mechanism was in place. The problem's not any easier without
a version loading mechanism -- a version loading structure could at least
help track down the problem here.

Chris