I hate that I have to push a commonly shared directory onto *central-registry* for each implementation and thus have to know the rc files of every implementation.
(I was recently bidden by some classic rm -rf ~, and had to redo all these kinds of infrastructure woes.)
Would anyone mind ASDF coming with an additional default value of ~/.asdf/systems/?
-T.
Would anyone mind ASDF coming with an additional default value of ~/.asdf/systems/?
That does seem like a reasonable default for *nix. Is there an analogous spot for Windows / cygwin? Can we use, e.g.,
(merge-pathnames (make-pathname :directory '(:relative ".asdf" "systems")) (user- homedir-pathname))
On Wed, 23 Sep 2009, Gary King wrote:
Would anyone mind ASDF coming with an additional default value of ~/.asdf/systems/?
That does seem like a reasonable default for *nix. Is there an analogous spot for Windows / cygwin? Can we use, e.g.,
(merge-pathnames (make-pathname :directory '(:relative ".asdf" "systems")) (user- homedir-pathname))
Yes, user-homedir-pathname gives a reasonable value for all the implementations I've tested on linux, mac, and windows.
Regarding Tobias's question, if CL/ASDF take off, I think people will want more than one default location. On a unix machine, they might be /usr/asdf, /usr/local/asdf, and ~/.asdf. On Windows, they might be C:\asdf, C:\Windows\asdf, and $HOME\asdf (I forget the exact $HOME variable name right now).
As Faré pointed out, these should be specified through a site-specific configuration rather than being hard-coded into ASDF. Such configuration might involve querying an environment variable or reading a config file from a known location (that's how most shells set these environment variables).
If reading config files, the two major conventions I know are - read the global config, then the user config, possibly overwriting settings - read the first available config file, trying the user config then the global config
Later, Daniel
2009/9/24 Daniel Herring dherring@tentpost.com:
Regarding Tobias's question, if CL/ASDF take off, I think people will want more than one default location. On a unix machine, they might be /usr/asdf, /usr/local/asdf, and ~/.asdf. On Windows, they might be C:\asdf, C:\Windows\asdf, and $HOME\asdf (I forget the exact $HOME variable name right now).
What about making it not specific to asdf but general to common-lisp, including any future replacement for asdf, be it xcvb, mudballs or whathaveyou?
And so the things to push in the *central-registry* would be /usr/share/common-lisp/systems/ (currently used by debian) /usr/local/share/common-lisp/systems/ (for non-distribution-managed system-installed systems?) ~/.common-lisp/systems/ or maybe ~/.local/share/common-lisp/systems/ (for user-installed systems?)
Now, now, now. What about instead exporting COMMON_LISP_PATH to default to $HOME/.common-lisp:$HOME/.local/share/common-lisp:/usr/local/share/common-lisp:/usr/share/common-lisp or whatever, and have ASDF either recurse through these directories or go to the systems directory underneath? This would allow sharing the configuration variable with XCVB and future CL software management systems, unlike an ASDF-specific ASDF_PATH.
As Faré pointed out, these should be specified through a site-specific configuration rather than being hard-coded into ASDF. Such configuration might involve querying an environment variable or reading a config file from a known location (that's how most shells set these environment variables).
If reading config files, the two major conventions I know are
- read the global config, then the user config, possibly overwriting
settings
- read the first available config file, trying the user config then the
global config
Similarly, if we are to have configuration files, what about the following? /etc/common-lisp/asdf-configuration.lisp ~/.local/etc/common-lisp/asdf-configuration.lisp ~/.common-lisp/asdf-configuration.lisp
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] ...so that IBM Java envangelist tells me "nothing spread as fast as Java", to which I answer: "crack!"...
or whatever, and have ASDF either recurse through these directories or go to the systems directory underneath? This would allow sharing the
i would like to point out that the way asdf suggests the symlinking of systems as the default way is not too newbie friendly...
a different setup would be much more slick for newcomers, where it has a list of dirs that it scans for *.asd's 1 level deep.
this symlinking is a though-trap, from which it's hard to escape, but i still remember the point when i did my own scanner and happily forgot symlinking and systems dirs forever.
/me ducks
I use ~/.local/share/common-lisp/systems/ /usr/local/share/common-lisp/systems/ /usr/share/common-lisp/systems/
YMMV.
What about an ASDF_PATH shell variable to be taken from getenv the first time an asdf:operate is called? (which raises questions as to how to reset it when you dump an image)
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] No witty quote today.
2009/9/23 Tobias C. Rittweiler tcr@freebits.de:
I hate that I have to push a commonly shared directory onto *central-registry* for each implementation and thus have to know the rc files of every implementation.
(I was recently bidden by some classic rm -rf ~, and had to redo all these kinds of infrastructure woes.)
Would anyone mind ASDF coming with an additional default value of ~/.asdf/systems/?
-T.
On 2009-09-23, at 22:03 , Faré wrote:
I use ~/.local/share/common-lisp/systems/ /usr/local/share/common-lisp/systems/ /usr/share/common-lisp/systems/
YMMV.
What about an ASDF_PATH shell variable to be taken from getenv the first time an asdf:operate is called? (which raises questions as to how to reset it when you dump an image)
one way to accomplish that is to use logical hosts which the system remaps when it loads.
james anderson writes:
On 2009-09-23, at 22:03 , Faré wrote:
I use ~/.local/share/common-lisp/systems/ /usr/local/share/common-lisp/systems/ /usr/share/common-lisp/systems/
YMMV.
What about an ASDF_PATH shell variable to be taken from getenv the first time an asdf:operate is called? (which raises questions as to how to reset it when you dump an image)
one way to accomplish that is to use logical hosts which the system remaps when it loads.
Hah! Suggesting logical pathnames as a solution to Fare is quite amusing. :-)
-T.
On 2009-09-24, at 00:06 , Tobias C. Rittweiler wrote:
james anderson writes:
On 2009-09-23, at 22:03 , Faré wrote:
I use ~/.local/share/common-lisp/systems/ /usr/local/share/common-lisp/systems/ /usr/share/common-lisp/systems/
YMMV.
What about an ASDF_PATH shell variable to be taken from getenv the first time an asdf:operate is called? (which raises questions as to how to reset it when you dump an image)
one way to accomplish that is to use logical hosts which the system remaps when it loads.
Hah! Suggesting logical pathnames as a solution to Fare is quite amusing. :-)
i would be surprised, if he didn't see it coming.
2009/9/23 james anderson james.anderson@setf.de:
On 2009-09-24, at 00:06 , Tobias C. Rittweiler wrote:
james anderson writes:
On 2009-09-23, at 22:03 , Faré wrote:
What about an ASDF_PATH shell variable to be taken from getenv the first time an asdf:operate is called? (which raises questions as to how to reset it when you dump an image)
one way to accomplish that is to use logical hosts which the system remaps when it loads.
Hah! Suggesting logical pathnames as a solution to Fare is quite amusing. :-)
i would be surprised, if he didn't see it coming.
Well, I'll be glad if logical pathnames are somehow fixed or made portable, then relied upon by ASDF (the opposite order would disturb me though). I invite janderson to draft an amendment to the CLHS that would make logical pathnames useful, and to get a sign off of it by all major CL implementers (SBCL implementers probably being the last on the boat). With a little bit of luck, they will all be eager to agree to that. I'd even like to see this endeavor succeed, though it is not a battle I am ready to fight personally.
But in any case, my proposal at hand is not about how things look like inside the Lisp process, but about a possible interprocess protocol for specifying one or many PATHs that ASDF would lookup, recursively or not, according to an environment variable.
There are such things as PATH LD_LIBRARY_PATH PERL_PATH PYTHONPATH PLTCOLLECTS TEXINPUTS etc.
What about a ASDF_PATH, or better, a COMMON_LISP_PATH ? Hopefully the latter, with a semantics that can be shared between ASDF and XCVB, and that allows recursion through directories instead of or in addition to having everything in one directory with symlinks.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt.
Faré writes:
What about a ASDF_PATH, or better, a COMMON_LISP_PATH ? Hopefully the latter, with a semantics that can be shared between ASDF and XCVB, and that allows recursion through directories instead of or in addition to having everything in one directory with symlinks.
Such behaviour should be introduced by a custom system-definition search function, possibly bundled with ASDF as a contrib. I feel somewhat queasy about ASDF-BINARY-LOCATION having been merged into ASDF itself. I think, it might have been a good opportunity to think of a contrib system for ASDF.
-T.
-
Attila Lendvai -
Daniel Herring -
Faré -
Gary King -
james anderson -
Tobias C. Rittweiler