Re: ASDF configuration and cache
Dear Paulo,
thanks a lot for your feedback.
I suppose the most significant bit is:
DOES ANY WINDOWS USER HERE HAVE A source-registry.conf ?
If not, then there will be no negative impact to the proposed change.
If yes, then I'd like to interact with you.
> Why? Seriously, XDG/freedesktop.org is a BSD/Linux/Unix thing, where
> and how does that fit in the Windows world? And if it does, it should
> be freedesktop.org defining where and how the user directories work in
> Windows (if they care at all).
>
That's a great suggestion. I'll ask on the freedesktop list, if they care.
>> The advantage of the change would be that ASDF would offer to Lisp
>> programs a uniform XDG view on all platforms, which has some costs in
>> terms of being slightly unfamiliar to Windows users and a transition
>> issue for some of them, but going forward allows for:
>> * the same directory concepts on all platforms.
>
> Who cares? The only thing you can really take untouched between
> platforms is the source anyway.
>
> You'll most likely have platform-specific configuration files even if
> you kind-of follow XDG in Windows.
>
The people who care are those who are going to have a non-standard
configuration. And those people who could have had a standard
configuration if we do things right who won't.
But really, I don't expect a big impact from moving the cache, but I
do expect an annoyance for moving the configuration files. If anyone
is using them, they may have a bad surprise when they stop working.
Note that I'm not moving the source code itself.
>> * the ability to handle backup of configuration and skipping of backup
>> of cache in a simpler way than with the usual Windows semi-convention.
>
> Well, here are my 2 cents.
>
> In Windows, you should store the configuration file in a roaming
> directory, e.g. %APPDATA%. I don't know what led to the current state
> of ASDF, but it's strange that you have to copy configuration over if
> you log on to a different machine.
>
> The cache is perfectly fine in %LOCALAPPDATA%. This is a compilation
> optimization, it would actually hurt if it were included in the
> roaming profile, potentially delaying all logs off and the first log
> on in a given machine.
>
> The source is mostly an internet resource, much like a browser's
> cache, so I guess it's OK in %LOCALAPPDATA%. The same space and
> performance reasoning that I applied to the cache, I apply to the
> source.
>
Here's the thing: the only thing that the configuration configures, so
far, is those things that you agree with me fit in %LOCALAPPDATA%.
Then moving it to a roaming %APPDATA% will only possibly result but on
discrepancies, when one machine goes looking for source code that is
only present on the other. That is why I decided to have the
configuration files in %LOCALAPPDATA% rather than %APPDATA%.
> So, from my point of view, following the XDG or leaving things as they
> are is equally bad for the Windows convention (it's actually
> documented, so no semi- prefix).
>
I'll also mention that when I started using the ~/.cache/ convention,
the XDG spec was nowhere popular on Unix. Ten years later, it's
omnipresent and has been adopted by the big and small players alike. I
don't despair that if Windows still exists in ten years, its
convention will have evolved the right way.
> If you're changing things, I'd prefer to have the configuration file
> in a roaming directory using Windows conventions, and leave all else
> as-is.
>
Even if what it configures is the stuff that remains local?
>> * a more uniform API for the Lisp programmer
>
> When is this ever visible to the programmer? If there is an API, why
> is it that the paths make it less uniform? Shouldn't the API abstract
> these details from the programmer no matter the differences or
> complexity?
>
That's a good point. By making the API slightly more complex, and
adding a level of indirection (naming the app and the file under the
app's config separately), we can abstract over those details. But the
lack of uniformity is hard to manage by tools not privy to the
internals of each and every application, even less so since the number
of levels of subdirectories is not uniform. For many apps it's 2
(vendor/appname), for some it's only 1 ("common-lisp", and many older
apps), for some it might be three or more (what with sub-applications
and profiles). So you can never trust where the Cache/ is, or that it
will be named Cache/, or that what's in the Cache/ can indeed be
skipped from backups. The XDG spec makes these things more reliable in
the long run if people follow them. Windows is in the disarray that
Unix was 12 years ago pre-XDG; Unix graduated out of it (somewhat); so
could Windows. Since we are going to be somewhat incompatible with
Windows conventions anyway, we might as well make that the opportunity
for being incompatible in a GOOD way.
>> * slightly simpler code for the ASDF maintainers.
>
> Ok, "slighty simpler" doesn't cut it for me. I consider this a change
> just because so.
>
It means that application programmers can request for a place to store
a configuration file on the machine, and be handed a sensible
pathname, whichever system the user is using.
>> What do you think? Does anyone care at all? Does anyone actually have
>> a common-lisp/config/source-registry.conf file and be confused if the
>> location changes?
>
> Again, I don't care, as I tend to ignore where ASDF stores things, or
> I manually fetch (mostly with version control tools) the required
> projects into a sub-directory of a Lisp project, or a common directory
> for a set of projects, to guarantee stability (but unfortunately, I do
> it each time less, and I haven't done it for quite a while...).
>
How/where do you configure ASDF?
> This is my way of quickly packaging a project from one
> platform/machine to another. It usually works.
>
> Actually, this is what I'd like the most: that ASDF would use local
> directories for source and cache by default, like e.g. .NET's nuget.
> And possibly merge a local config file with the user config file,
> where the local settings override the user settings. And possibly
> have a machine-wide config file.
>
That's what I'm aiming for, too. I'm consulting LOCALAPPDATA before
APPDATA, and I am considering adding PROGRAMDATA to the mix. LispWorks
6's get-folder-path doesn't provide access to :programdata, which
stopped me in the past, but since I use getenv on other
implementations anyway, I might use it on LispWorks, too.
> PS: Ok, I don't know how much of this ASDF has or not, and it's kind
> of unreasonable to keep discussing new features in this thread, so you
> may just ignore the previous paragraph.
>
That's all very reasonable things to discuss. Thanks a whole lot!
PS: can an administrator please unsubscribe tayloj@cs.rpi.edu ? Every
mail sent to the list results in the sender getting notification about
this address being not valid anymore.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Procrastination is great. It gives me a lot more time
to do things that I'm never going to do.
_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html