Going over the manual to tidy it up, I was quite surprised to read this:
The default location for a user to install Common Lisp software is under `~/.local/share/common-lisp/source/'.
This seems /very/ odd. Why would I want to install software in a location 'ls' is going to hide from me?
For conventional programs, I stick the source in ~/src and I put my executables in ~/bin. It wouldn't even occur to me to stick them somewhere where I couldn't find them without something like 'ls -a'.
Furthermore, since I work on my lisp code most of the day, it wouldn't occur to me to hide them four levels deep behind a hidden directory.
Do most lisp users stick things in ~/.local ? And if so, why????
Thanks, r
On 2010/03/12, at 00:53 , Robert Goldman wrote:
Going over the manual to tidy it up, I was quite surprised to read this:
The default location for a user to install Common Lisp software is under `~/.local/share/common-lisp/source/'.
This seems /very/ odd. Why would I want to install software in a location 'ls' is going to hide from me?
For conventional programs, I stick the source in ~/src and I put my executables in ~/bin. It wouldn't even occur to me to stick them somewhere where I couldn't find them without something like 'ls -a'.
Furthermore, since I work on my lisp code most of the day, it wouldn't occur to me to hide them four levels deep behind a hidden directory.
Do most lisp users stick things in ~/.local ? And if so, why????
You're right, it's totally silly.
Moreover, file names starting with dots are not even "right" for lisp, given the syntax for logical pathnames. They can only be explicited as physical pathnames...
Actually, I have ls as an alias which includes the -a option in my ~/.bashrc, so it would make no difference to name an entry with a dot. Therefore I tend to not (anymore) use dotfiles (I rename my ~/.common.lisp file to ~/common.lisp now).
On my systems, Lisp software is installed either in distribution specified directories, such as /usr/share/common-lisp (gentoo), or in / data/share/lisp/ or in ~/src/lisp/ etc.
: rpg Going over the manual to tidy it up, I was quite surprised to read this:
The default location for a user to install Common Lisp software is under `~/.local/share/common-lisp/source/'.
This seems /very/ odd. Why would I want to install software in a location 'ls' is going to hide from me?
For conventional programs, I stick the source in ~/src and I put my executables in ~/bin. It wouldn't even occur to me to stick them somewhere where I couldn't find them without something like 'ls -a'.
Furthermore, since I work on my lisp code most of the day, it wouldn't occur to me to hide them four levels deep behind a hidden directory.
Do most lisp users stick things in ~/.local ? And if so, why????
Well, apart from ~/.local/share/ being a "standard" XDG-recommended place to store such things, consider that
1- *If* we are any successful, most users would probably not read, much less edit, any of the stuff they download (or rather, that gets downloaded for them). It is proper that that stuff should be stashed away in a hidden directory.
2- Sure, developers like you and I want to see our source in an easily accessed directory, but
a- there is no standard for such directory (I use ~/cl/)
b- we developers can easily add stuff to our source-registry configuration.
3- you didn't complain when I put the configuration in ~/.config/common-lisp/ which is also the XDG-recommended place.
: pjb Moreover, file names starting with dots are not even "right" for lisp, given the syntax for logical pathnames. They can only be explicited as physical pathnames...
Uh? You can easily configure a logical host that will map some logical pathname of your choice to the suitable physical pathname. No problem here.
Actually, I have ls as an alias which includes the -a option in my ~/.bashrc, so it would make no difference to name an entry with a dot. Therefore I tend to not (anymore) use dotfiles (I rename my ~/.common.lisp file to ~/common.lisp now).
To each his own, but
On my systems, Lisp software is installed either in distribution specified directories, such as /usr/share/common-lisp (gentoo), or in / data/share/lisp/ or in ~/src/lisp/ etc.
Everyone has a different setup. Hence this configuration facility.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You can tell whether a man is clever by his answers. You can tell whether a man is wise by his questions. — Naguib Mahfouz
On 2010/03/12, at 06:24 , Faré wrote:
Well, apart from ~/.local/share/ being a "standard" XDG-recommended place to store such things, consider that
I agree with all your objections to my message; mine was mostly "stylistic" and personal taste indeed.
3- you didn't complain when I put the configuration in ~/.config/common-lisp/ which is also the XDG-recommended place.
I make a difference for configuration files (and "RC" files).
But if there's a standard for installation of software libraries for users, no objection.
Just interested: do you have a convenient linky to the relevant part of the spec?
Cheers,
-- Nikodemus
I'd like to try to diagnose a communication error that has gone on here.
I think we're seeing some problems with asdf-output-locations primarily because of unclear communications. It seems to me that Faré may feel a ill-used because the asdf-output-locations have been out there for a long while, and now a bunch of issues are being raised.
I fear that the problem is that although this facility has been out there for a long time, it hasn't been widely tested, or nor has the documentation even been browsed.
I will say now that I don't see how to effectively use the file-based configuration scheme IN MY WORKING ENVIRONMENT, so I doubt I will ever use it. I am more than willing to help get it in the manual, but it's probably not worth assuming, based on my silence about it, that I am expressing anything other than apathy. It's clear that I should have been explicit about this earlier.
On 3/11/10 Mar 11 -11:24 PM, Faré wrote:
: rpg Going over the manual to tidy it up, I was quite surprised to read this:
The default location for a user to install Common Lisp software is under `~/.local/share/common-lisp/source/'.
This seems /very/ odd. Why would I want to install software in a location 'ls' is going to hide from me?
For conventional programs, I stick the source in ~/src and I put my executables in ~/bin. It wouldn't even occur to me to stick them somewhere where I couldn't find them without something like 'ls -a'.
Furthermore, since I work on my lisp code most of the day, it wouldn't occur to me to hide them four levels deep behind a hidden directory.
Do most lisp users stick things in ~/.local ? And if so, why????
Well, apart from ~/.local/share/ being a "standard" XDG-recommended place to store such things, consider that
1- *If* we are any successful, most users would probably not read, much less edit, any of the stuff they download (or rather, that gets downloaded for them). It is proper that that stuff should be stashed away in a hidden directory.
2- Sure, developers like you and I want to see our source in an easily accessed directory, but
a- there is no standard for such directory (I use ~/cl/)
b- we developers can easily add stuff to our source-registry configuration.
3- you didn't complain when I put the configuration in ~/.config/common-lisp/ which is also the XDG-recommended place.
I'm afraid the answer to (3) doesn't really apply because I haven't examined this stuff until yesterday. Even if I had been able to test this facility, I would never have used the configuration files, for the reasons I specified below.
FWIW, I /don't/ like the XDG recommendations, per my previous post -- I think they splatter files all over the place in ways that make them hard to find, and that make it very difficult to determine the actual running state of one's system. These guidelines seem to me almost to be saying "let's have as many global variables as possible," for configuration files are essentially global variables.
To the extent that I consented (even passively) to the XDG recommendations, that's because I assumed that they wouldn't matter to me -- that I could simply find a relatively simple way, all in lisp, to get asdf-output-translations to behave the way asdf-binary-locations did. I think that's probably feasible, per my last message.
As for number 1, I think the primary audience for lisp code is still developers, not users. My experience with the state of the art also indicates to me that it is only the brave and foolhardy that count on CL libraries being downloaded and installed for them. By and large I have been sorry every time I've loaded a CL library from ASDF-INSTALL instead of using a working copy from some form of revision control system (indeed, if I go beyond experimentation with a library, I will ensure that it is blown into our local svn repository of lisp utilities). Sad but true (see parenthetical below).
At any rate, I think that utilitarianism would suggest focusing on the developer experience rather than the user experience for A-O-L.
[Let me share with you our delivery experience, in the hopes it will be of interest. If not, feel free to skip.
When we deliver software, we are not about to take the chance of users getting incompatible library versions, etc. We always make sure that we deliver a blob of some form that starts up, populates its set of libraries, and doesn't allow in anything else.
A remark about this: The CL libraries we see are often brittle, and it is the exception rather than the rule if they indicate versioning requirements. For our users, we simply can't take the risk of them using a version of a library that we haven't tested.
Indeed, if we can get away with it, we don't deliver software /at all/. We have found for CL it's actually easier to deliver a whole system, say by building with Knoppix, to even further nail down the state of the environment (a nasty experience with a CL program that invoked ImageMagick several years ago prompts us to try to do things like this). Or we specify a particular version of Linux to run on.]
:rpg I fear that the problem is that although [A-O-T] has been out there for a long time, it hasn't been widely tested, or nor has the documentation even been browsed.
AOT has only been there for a month, really, and has only started being semi-widely used recently, with PvE including it in CLC last week.
I will say now that I don't see how to effectively use the file-based configuration scheme IN MY WORKING ENVIRONMENT, so I doubt I will ever use it. I am more than willing to help get it in the manual, but it's probably not worth assuming, based on my silence about it, that I am expressing anything other than apathy. It's clear that I should have been explicit about this earlier.
People like you and I, building large(ish) software for production, need reproducibility and complete scripted control. Thus, we will override whatever defaults are found in those files. However, we essentially use the same mechanisms as found in said files, and the fact that the files exist mean that individual users as well as system administrators can get their defaults right, instead of having to painstakingly edit every program's startup script.
3- you didn't complain when I put the configuration in ~/.config/common-lisp/ which is also the XDG-recommended place.
I'm afraid the answer to (3) doesn't really apply because I haven't examined this stuff until yesterday. Even if I had been able to test this facility, I would never have used the configuration files, for the reasons I specified below.
FWIW, I /don't/ like the XDG recommendations, per my previous post -- I think they splatter files all over the place in ways that make them hard to find, and that make it very difficult to determine the actual running state of one's system. These guidelines seem to me almost to be saying "let's have as many global variables as possible," for configuration files are essentially global variables.
XDG splatters things around no more and no less than the FHS. Indeed it's all about global variables, for various values of "global". The point being that you want to be able to set some variables across all instances of all Lisp processes (for given user, on given machine, etc.)
To the extent that I consented (even passively) to the XDG recommendations, that's because I assumed that they wouldn't matter to me -- that I could simply find a relatively simple way, all in lisp, to get asdf-output-translations to behave the way asdf-binary-locations did. I think that's probably feasible, per my last message.
Yes. This is feasible and supported. Use
(asdf:initialize-output-translations `(:asdf-output-translations ...))
As for number 1, I think the primary audience for lisp code is still developers, not users. My experience with the state of the art also indicates to me that it is only the brave and foolhardy that count on CL libraries being downloaded and installed for them. By and large I have been sorry every time I've loaded a CL library from ASDF-INSTALL instead of using a working copy from some form of revision control system (indeed, if I go beyond experimentation with a library, I will ensure that it is blown into our local svn repository of lisp utilities). Sad but true (see parenthetical below).
I haven't been bitten too much by things downloaded via clbuild so far, but I haven't been trying too hard either. In any case, ASDF itself doesn't handle versioning, and doesn't really try. If you want version control, you'll need version control, with svn externals, git submodule, etc.
At any rate, I think that utilitarianism would suggest focusing on the developer experience rather than the user experience for A-O-L.
I think both are important, and I think the defaults should target the user first.
Indeed, if we can get away with it, we don't deliver software /at all/. We have found for CL it's actually easier to deliver a whole system, say by building with Knoppix, to even further nail down the state of the environment (a nasty experience with a CL program that invoked ImageMagick several years ago prompts us to try to do things like this). Or we specify a particular version of Linux to run on.]
Here at ITA, we deliver software to be run inside a chroot, so that once the software is installed, the kernel is the only possible moving part from machine to machine.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] We [the French] will accept any master who will let us enjoy the good life, with good food, sweet romance and long vacations; and we'll use that good life to corrupt whoever will rule us into embracing our way of life. Yet we'll abandon him for a stronger master the moment that his weakness is apparent.
On 12 March 2010 07:24, Faré fahree@gmail.com wrote:
Well, apart from ~/.local/share/ being a "standard" XDG-recommended place to store such things, consider that
Erm, my reading suggests otherwise.
From:
http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
"$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used."
IMO, if the idea is to follow XDG (I don't care strongly either way), then let's follow it properly and use the appropriate environment variables instead of canonicalizing on the defaults.
Cheers,
-- Nikodemus
IMO, if the idea is to follow XDG (I don't care strongly either way), then let's follow it properly and use the appropriate environment variables instead of canonicalizing on the defaults.
OK. Will do.
The next question is what to do on Windows?
On LispWorks, I could use
(merge-pathnames* (sys:get-folder-path :local-appdata) "common-lisp/config/") instead of ~/.config/common-lisp/ and probably also (merge-pathnames* (sys:get-folder-path :local-appdata) "common-lisp/) instead of ~/.local/share/common-lisp and similarly (merge-pathnames* (sys:get-folder-path :common-appdata) "common-lisp/config/") instead of /etc/config/common-lisp/ and (merge-pathnames* (sys:get-folder-path :common-appdata) "common-lisp/") instead of /usr/share/common-lisp/
How do I do the same on all Windows Lisp implementations? GAH!
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Anyone who is capable of getting themselves made President should on no account be allowed to do the job. — Douglas Adams, "The Hitchhiker's Guide to the Galaxy"
-
Faré -
Nikodemus Siivola -
Pascal J. Bourguignon -
Robert Goldman