[asdf-devel] ASDF manual lisp installation directions

[Faré]

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