On Fri, 2009-10-02 at 14:57 +0200, Göran Weinholt wrote:
> Abdulaziz Ghuloum <xxxxxx@gmail.com> writes:
>
> > On Oct 1, 2009, at 6:59 PM, Göran Weinholt wrote:
> >
> >> So is the idea that I would be keeping versioned filenames in my
> >> bazaar
> >> repository, or would they be renamed to include a version by a package
> >> manager?
> >
> > We should not assume the existence of a package manager.  Also, you
> > won't be using a package manager when working with your own libraries,
> > right?  Usually, you work on your libraries locally and then, in a
> > separate step, package it together for distribution.  You won't want
> > to add the package manager to your workflow.
>
> That's a good point. So what problem is solved by keeping the version
> inside the filename? I read something about a distinct mapping of
> filenames to library names, but then I'm not sure what problem that in
> turn solves. If you want the version number then it's in the file, which
> is usually not far away.

That mapping ability can be useful for people and programs reviewing and
managing library files because you only need to look at the file names
to know what libraries, including their versions, are present and where,
and don't need to look in the files or have an additional "manifest"
file.  I think that is worthwhile, but by itself probably not enough
justification for having versions in file names.

I make the argument that having to open a file and find the version is
comparably annoying to having to rename files.  The ability to rename a
file is usually not far away either.  I think not being annoyed by
renaming is worthwhile, but by itself probably not enough justification
for not having versions in file names.

When considering only these things, this is what decides the winner for
me: only the developer(s) have to deal with renaming files because of
version changes, but everyone, which hopefully includes many more people
than the developer(s), have to use the file names to know what libraries
are present and where, and they need to also know the versions.  So, a
smaller number of people having to deal with an annoyance wins over a
larger number of people having to deal with a same-magnitude annoyance.

> Having the version in the filename also duplicates information, which in
> my experience always gives you the problem of keeping the duplicated
> information synchronized.

I agree that's annoying.

> 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.

PLT Scheme requires the versions to be in file names.  To use my
existing versioned libraries on it, I've already been dealing with
versions in file names.  If PLT is not willing to support this SRFI (I
don't know what they think), then to use our versioned libraries on PLT,
we'll still be dealing with versions in file names, and additionally
dealing with symlinks/copies to/of the files conforming to this SRFI
without versions in their name.

The point about supporting having multiple versions in the same
directory is what I see as the primary reason for having versions in
file names.  The other points, about mapping file names to library names
and file names exactly corresponding to library names, are not as
motivating.

> 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.

Yeah.

> Is the idea that filenames should contain versions so that multiple
> versions of a library can co-exist in the same directory?

Yes.

> If a library
> developer wants to do that, he can simply append a major version to the
> end of a library identifier, something like this:
>
>  (foo jpeg (0))   foo/jpeg.sls   initial version (0 is the minor)
>  (foo jpeg (1))   foo/jpeg.sls   second version, supports more formats
>  (foo jpeg1 (0))  foo/jpeg1.sls  third version with a much better API
>
> If he wants to he can even make it so (foo jpeg) is a compatibility
> wrapper around (foo jpeg1). Such a wrapper would be very useful for
> anyone changing a program to use the new library, because it would show
> exactly what changes are necessary. And if the developer was careful,
> there will not be any point in keeping (foo jpeg (0)) around when you've
> got (foo jpeg (1)).
>
> This is much less tedious than requiring that every part of a version
> reference always must be included in the filename, and it leaves the
> individual developer free to choose what he and his users need.

Problems with this scheme are: semantic disintegration between major
numbers and minor numbers, version constraints cannot be used on major
numbers, and an additional redundant versioning convention to deal with.

What if someone wants multiple versions which have the same major number
but different minor number to co-exist in the same directory?  That's
not possible with your proposed scheme.

I think putting any part of the version in the last symbol (or any
symbol) is going against the purpose of compound library names.

> I can't
> imagine anyone being very happy when they discover that to use R6RS's
> version feature they need to forever keep renaming their files.

I'm sure it's true that people won't be excited about that.  But how
happy are they going to be when they realize they have to manage
reconfiguring search paths in order to run different programs which
require different versions of a library?  Or how happy when they realize
they can have multiple versions with different major numbers co-exist,
but not with different minor numbers?  Or how happy when they realize
they can have version constraints on minor numbers but not on major
numbers?  Or how happy when they realize they have to open files and
search through the contents to know libraries' versions when all they
really needed was the file names to know what libraries there are?

--
: Derick
----------------------------------------------------------------