Re: Keeping the version in filenames

[Abdulaziz Ghuloum <aghuloum@xxxxxxxxx>]

On Oct 2, 2009, at 3:57 PM, Göran Weinholt wrote:

> So what problem is solved by keeping the version inside the
> filename?

Derick's idea is that you may have two programs P1 and P2 where
P1 depends on A.v1 and P2 depends on A.v2 and to be able to run
both programs, you need to have both A.v1 and A.v2 at the same
time.  If the SRFI does not map files+versions to file names,
then you can only have one of A.sls and not both of A.1.sls and
A.2.sls.

Now shift the problem a little, and let's say that P1 depends
on A1 depends on B1, and P2 depends on A2 depends on B2.  Yes,
by having distinct file names, you can run P1 and P2, but you
still cannot use the libraries A1 and A2 or B1 and B2 at the
same time.

If you put the version in the library name, as you suggest, and
call these libraries A1, A2, B1, and B2, then yes, you can have
them at the same directory and you can load them all at the same
time.  This may or may not be a good idea depending on what the
library does.


> There is something of a feature-creep in this SRFI as it currently
> stands. As I see it, the idea is to standardize the widely implemented
> library file locator algorithm and work out all the edge cases.  
> Keeping
> the version number in the filename is not widely implemented, and
> creates new problems by itself. Remove that feature and I think we  
> will
> have a less controversial SRFI that is also compatible with existing
> Schemes and libraries.

I agree with this.  If the versions in this SRFI is providing a real
solution to the problem, I would have no problem implementing it and
ditching everything that already exists in Ikarus.


> I'm all in favor of library versions and version references. I use  
> them
> myself, as a courtesy to those who want to use my libraries, and  
> because
> I want to be able to change the meaning of exported bindings without
> causing people too much trouble.

In Ikarus, versions are supported for the purpose of checking for
availability of a certain version, and failing fast if the specified
version does not meet the actual library version.  I certainly am
not going to add a SAT solver for picking which library must be used
among a set of available libraries, and I certainly don't like to
just pick the first specified one (which is random more or less)
which is what this SRFI currently says I should do.

I would like to keep version dependencies, constraints, conflicts,
etc., outside of the implementation as much as possible.

Aziz,,,