Keeping the version in filenames Göran Weinholt (01 Oct 2009 16:29 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 05:53 UTC)
Re: Keeping the version in filenames Göran Weinholt (02 Oct 2009 12:59 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 16:22 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 17:24 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:13 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:51 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 20:25 UTC)
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 13:06 UTC)
Re: Keeping the version in filenames Abdulaziz Ghuloum (02 Oct 2009 16:26 UTC)
Bye-bye versioning Derick Eddington (02 Oct 2009 19:56 UTC)

Re: Keeping the version in filenames Derick Eddington 02 Oct 2009 13:06 UTC

On Thu, 2009-10-01 at 17:59 +0200, Göran Weinholt wrote:
> I'm wondering what my workflow will look like if I want to write
> libraries that work with SRFI-103.

Thanks for your feedback.

> Since I have versions in all my
> library forms, it seems like I'd have to rename my files whenever I
> change a version number.

Yes, that's true.

> I would need to write a save-hook or it would
> get boring pretty fast. I suspect that I'd also need to abandon the
> YYYYMMDD part of my version numbers, or I'd end up with quite a lot of
> files.

You'd need to rename the files via the repository manager so it tracks
the renaming and gets rid of the old file name.

I look at the issue like this:

This SRFI needs to support having multiple versions of a library stored
as separate files in the same directory.  The only way to accomplish
that is by having versions in file names.  It is important to support
having multiple versions available so that different programs which
require different versions can both be used.  If the file naming scheme
does not support versions, the only way to accomplish running the
different programs is to manage configuring the search paths used for
each program so that the correct version is used.

We should be able to know what libraries are present, which includes
knowing their versions because different versions are distinct things,
from only a listing of file names.  The only way to accomplish that is
by having versions in file names.

A library's file's name should represent the library's name, and a
version is naturally a part of the name.  The purpose of the version is
to identify a distinct library, and the purpose of the file name is to
correspond to the identity of the library.  If we want a library's name
to have a version, and we want its file name to correspond to the
library name, then shouldn't the file name have the version?

I want to make sure everyone has thoroughly thought about these points
before sacrificing the qualities of the current draft for the sake of
not being annoyed by file renaming.

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

The idea is that no package manager should be required and you'd have
versioned file names in basic tar-balls and repositories.  The idea is
that library file names exactly represent the name of the contained
library.

> Also, SCHEME_LIBRARY_SEARCH_PATHS is rather long. How about SLSPATH?

SLSPATH is rather short, non-descriptive, and makes it seem like its
value can only be a single path.  I'm okay with SCHEME_LIBRARY_PATHS or
SCHEME_PATHS.  (I've always hated the Unix tradition of making public
global variables' names be bizarrely truncated and non-descriptive, and
always loved the Lisp tradition of proper, descriptive names for such
variables.  IMO, there's not a good reason why environment variables'
names should follow Unix tradition...)

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