ASDF configuration and cache

[Faré]

Dear Mark,

~/.config/common-lisp/source-registry.conf.d/ is being used because
you're compiling on Unix. If you were using Windows, it would be using
something else based on LOCALAPPDATA, not USERPROFILE.

For reliable builds, especially ones that create cross-platform
objects, we recommend you don't use either, but explicitly pass a
proper (or null) overriding configuration to the initialization
functions initialize-source-registry and
initialize-output-translations.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
I've never understood why it is 'greed' to want to keep the money you've earned
but not greed to want to take somebody else's money. — Thomas Sowell


On Tue, Apr 28, 2015 at 11:34 PM, Mark Evenson <evenson at panix.com> wrote:
>
>
> On 2015/4/29 07:13, Faré wrote:
>> Dear Lispers,
>>
>> The most significant bit for this email is:
>> DO YOU HAVE A source-registry.conf ON WINDOWS?
>> or do you know someone who has?
>> If so, please contact me, either on this list or in private,
>> because I'm considering a backward-incompatible change in its location.
>
> […]
>
> For systems that build production code under Windows with ABCL running
> asdf-3.1.4, we use the the user configuration directory
> <file:~/.config/common-lisp/source-registry.conf.d/> (it always seemed
> conceptually easier to have many small files that may be easily moved
> than placing all the forms in a single
> <file:~/.co

ASDF configuration and cache

Inbox
x

Faré <fahree at gmail.com>

10:13 PM (2 hours ago)
to ASDF-devel
Dear Lispers,

The most significant bit for this email is:
DO YOU HAVE A source-registry.conf ON WINDOWS?
or do you know someone who has?
If so, please contact me, either on this list or in private,
because I'm considering a backward-incompatible change in its location.

(If you use or don't use source-registry.conf on Linux, that can be an
interesting data point, too, for comparison of impact.)

If not, then there will be no negative impact to the proposed change.

I'm having a hard time finding an affected Windows user who cares,
which may be a sign that there is none and I can proceed, or that I'm
simply disconnected from the user base.

Right now, ASDF tries to do things kind-of-the-windows-way, where
"common-lisp/" replaces the vendor/app/ path component. Thus, it puts
its configuration in %LOCALAPPDATA%/common-lisp/config/ its cache in
%LOCALAPPDATA%/common-lisp/cache/ and for source code in
%LOCALAPPDATA%/common-lisp/source/

I'm considering dropping the Windows special-casing, and offering the
XDG model on all platforms, including Windows. That would mean the
configuration would instead go in
%LOCALAPPDATA%/Configuration/common-lisp/ and the cache in
%LOCALAPPDATA%/Cache/common-lisp/ while source code remains in
%LOCALAPPDATA%/common-lisp/source/ with these the conceptual mapping
XDG_CONFIG_HOME=%LOCALAPPDATA%/Configuration instead of ~/.config/ and
XDG_DATA_HOME=%LOCALAPPDATA%/ instead of ~/.local/share/ and
XDG_CACHE_HOME=%LOCALAPPDATA%/Cache/ instead of ~/.cache/

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:
* all files can be redirected on all platforms using the
XDG_CONFIG_HOME environment variable and its siblings.
* the same directory concepts on all platforms.
* slightly simpler code for the ASDF maintainers, and much simpler
documentation: no need to explain vast subtle discrepancies from one
platform to the next.
* the ability to handle backup of configuration and skipping of backup
of cache in a simpler way than with the usual Windows semi-convention.
* a more uniform API for the Lisp programmer

The main disadvantage is that this setup is somewhat different from
current conventions on Windows. On the other hand, conventions on Unix
were similar to those on Windows some ten years back, and have
improved thanks to XDG -- maybe they can evolve for the better on
Windows, too, in the next ten years.

To me, the big issue is with transition for people who currently use a
source-registry.conf on Windows. Since ASDF will start to look for it
at a different location, their setup will need to be amended when they
upgrade ASDF.

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?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Corollaries to the Law of Bitur-Camember: The political process destroys the
value of all known resources that are up for grabs. The socialist process of
systematically denying legitimacy to property rights applies the political
process universally and destroys the value of all available resources.

Mark Evenson via common-lisp.net

11:34 PM (1 hour ago)
to asdf-devel
On 2015/4/29 07:13, Faré wrote:
> Dear Lispers,
>
> The most significant bit for this email is:
> DO YOU HAVE A source-registry.conf ON WINDOWS?
> or do you know someone who has?
> If so, please contact me, either on this list or in private,
> because I'm considering a backward-incompatible change in its location.

[…]

For systems that build production code under Windows with ABCL running
asdf-3.1.4, we use the the user configuration directory
<file:~/.config/common-lisp/source-registry.conf.d/> (it always seemed
conceptually easier to have many small files that may be easily moved
than placing all the forms in a single
<file:~/.config/common-lisp/source-registry.conf>.)  At production
runtime, we explicitly "neuter" the ASDF configuration strategy via the
appropriate ASDF API, as we are running from within a Java web
application archive (to be described in a long overdue ABCL-DEV blog post).

As I understand your proposal, even though we don't use the
"source-registry.conf" file, we would still be effected by your proposed
change, as the value of XDG_CONFIG_HOME would be based on
%LOCALAPPDATA%, not %USERPROFILE% as is currently the case.

We would probably not use the XDG_CONFIG_HOME environment variable,
instead adapting to ASDF defaults, as it would be additional complexity
to describe to operations and one more thing that could go wrong.

As long as you make your proposed transition across a minor revision
(aka as ASDF 3.2.x), I do not have a problem with your proposal.  For
the record, although none of your listed benefits of this change would
give us any immediate advantage that I can determine, I support the
drive towards greater cross-platform uniformity.
Mark Evenson (panix.com), ASDF-devel (asdf-devel at common-lisp.net)
Dear Mark,


Saved
9.96 GB (66%) of 15 GB used
Manage
Last account activity: 1 hour ago
Details
nfig/common-lisp/source-registry.conf>.)  At production
> runtime, we explicitly "neuter" the ASDF configuration strategy via the
> appropriate ASDF API, as we are running from within a Java web
> application archive (to be described in a long overdue ABCL-DEV blog post).
>
> As I understand your proposal, even though we don't use the
> "source-registry.conf" file, we would still be effected by your proposed
> change, as the value of XDG_CONFIG_HOME would be based on
> %LOCALAPPDATA%, not %USERPROFILE% as is currently the case.
>
> We would probably not use the XDG_CONFIG_HOME environment variable,
> instead adapting to ASDF defaults, as it would be additional complexity
> to describe to operations and one more thing that could go wrong.
>
> As long as you make your proposed transition across a minor revision
> (aka as ASDF 3.2.x), I do not have a problem with your proposal.  For
> the record, although none of your listed benefits of this change would
> give us any immediate advantage that I can determine, I support the
> drive towards greater cross-platform uniformity.
>
>
>
> --
> "A screaming comes across the sky.  It has happened before, but there
> is nothing to compare to it now."
>