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