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.]