[asdf-devel] ASDF manual lisp installation directions

[Robert Goldman]

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