Should we base our search path on the XDG Base Directory Specification? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html To the point of actually using getenv to get these search paths?
I say we should.
The default configuration files should be $XDG_CONFIG_DIRS/common-lisp/source-registry.conf $XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/
And the default search path should include $XDG_DATA_DIRS/common-lisp/systems/ $XDG_DATA_DIRS/common-lisp/source//
The default cache path should be under $XDG_CACHE_HOME/common-lisp/
Unless anyone objects, I'll implement that behavior and commit something like ASDF 1.695.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Vision is the art of seeing what is invisible to others. — Jonathan Swift
Should we base our search path on the XDG Base Directory Specification? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html To the point of actually using getenv to get these search paths?
I say we should.
The default configuration files should be $XDG_CONFIG_DIRS/common-lisp/source-registry.conf $XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/
And the default search path should include $XDG_DATA_DIRS/common-lisp/systems/ $XDG_DATA_DIRS/common-lisp/source//
The default cache path should be under $XDG_CACHE_HOME/common-lisp/
The config dirs stuff looks good. Systems and sources do not belong under DATA dirs. If the cache path specifies where fasls get dumped, I'm ambivalent whether it belongs in CACHE_HOME.
Are there specs regarding how XDG works on apple or mswin platforms?
Also note that systems like KDE support XDG in addition to their own heirarchy. There are benefits to keeping your apples away from your oranges. http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy http://techbase.kde.org/KDE_System_Administration/KDE_Filesystem_Hierarchy
XDG is a win if you're trying to share trash cans and desktop files between window managers. I don't see how CL fits in; but XDG does appear to have a reasonable description of how things work.
- Daniel
On 2/22/10 Feb 22 -11:23 AM, Faré wrote:
Should we base our search path on the XDG Base Directory Specification? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html To the point of actually using getenv to get these search paths?
I say we should.
Only to the extent that we maintain the possibility for people who want to configure their environment in pure lisp to do so.
I clicked on that link, read about 10 words and decided that I had already spent more than enough time on it.
As far as I'm concerned, as long as I can still type
(push "home:lisp;myLibrary;" asdf:*central-registry*)
and it Just Works, go wild.
But if this is going to make me bend over backwards to work around XDG, then no, please don't.
My take on this is that I want to get my lisp environment working entirely within the confines of ~/clinit.cl and ~/.sbcl (aside from recording the location of the lisp executables). I don't want to do anything at all with the shell, or any extra bonus configuration files.
If other people want the *opportunity* to use environment variables or config files, but not the *obligation*, then I think it's a great idea.
Cheers, r
Yes, ASDF will still work, in a backward-compatible way, if you only use the *central-registry*. This is actively supported.
I'd like to eventually promote (asdf:initialize-source-registry ...) as an alternative to setf'ing *central-registry* when configuring from Lisp, and eventually declare the latter obsolete, but we're not quite there yet.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Backwards compatible — If it's not backwards it's not compatible — Greg Newton gregnewton@netscape.net
On 22 February 2010 13:48, Robert Goldman rpgoldman@sift.info wrote:
On 2/22/10 Feb 22 -11:23 AM, Faré wrote:
Should we base our search path on the XDG Base Directory Specification? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html To the point of actually using getenv to get these search paths?
I say we should.
Only to the extent that we maintain the possibility for people who want to configure their environment in pure lisp to do so.
I clicked on that link, read about 10 words and decided that I had already spent more than enough time on it.
As far as I'm concerned, as long as I can still type
(push "home:lisp;myLibrary;" asdf:*central-registry*)
and it Just Works, go wild.
But if this is going to make me bend over backwards to work around XDG, then no, please don't.
My take on this is that I want to get my lisp environment working entirely within the confines of ~/clinit.cl and ~/.sbcl (aside from recording the location of the lisp executables). I don't want to do anything at all with the shell, or any extra bonus configuration files.
If other people want the *opportunity* to use environment variables or config files, but not the *obligation*, then I think it's a great idea.
Cheers, r
From: Faré fahree@gmail.com
Should we base our search path on the XDG Base Directory Specification? http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html To the point of actually using getenv to get these search paths?
I say we should.
The default configuration files should be $XDG_CONFIG_DIRS/common-lisp/source-registry.conf $XDG_CONFIG_DIRS/common-lisp/source-registry.conf.d/
And the default search path should include $XDG_DATA_DIRS/common-lisp/systems/ $XDG_DATA_DIRS/common-lisp/source//
The default cache path should be under $XDG_CACHE_HOME/common-lisp/
Unless anyone objects, I'll implement that behavior and commit something like ASDF 1.695.
What do we do about non-XDG-enabled platforms?
Some static set of per-platform defined subdirectories relative to whatever (user-homedir-pathname) returns?
regards, Samium Gromoff -- "Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)
-
dherring＠tentpost.com -
Faré -
Robert Goldman -
Samium Gromoff