[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Keeping the version in filenames
- To: Göran Weinholt <goran@xxxxxxxxxxx>
- Subject: Re: Keeping the version in filenames
- From: Derick Eddington <derick.eddington@xxxxxxxxx>
- Date: Fri, 02 Oct 2009 06:06:21 -0700
- Cc: srfi-103@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-103@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=0ojeAUhngjTxVjfCE7dJYbSibzpcBcMus+EYjwJj4wE=; b=ggaBvQF49+S9j7MHvxHxJ34QAENuuTKo4OYgcNM83ViBHDHYW2fHbutoSW449jqUnx rjrhJB3/ACXvFuA+rJj3d008PH8lfHhd0RBgD9VZXPkwRyQ4waHAh4v5Xz5rHLfE1aVx vOZD1Py3PcDXequOUbDCa/tqyhpXRQzhwT60I=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=ftAg8P4/ikNzDzV0nxgs9dfr5uWUr7V1W1pQO/bydU92lsLeLdqsUC8P8ovpgIieqP QQX3tiS1R029/fDjukUkfCISj22xUvTjiYo4AJPakDcyRsDxjFS5W+H3DIFHkiaG341B gNqX7jKoOOYO2nVGOjSrwAmjnEYnwGOktvCZo=
- In-reply-to: <87ocorgl65.fsf@xxxxxxxxxxxxxxxxxxx>
- References: <87ocorgl65.fsf@xxxxxxxxxxxxxxxxxxx>
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
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
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
> 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...)