[asdf-devel] MCL issue

[Faré]

>> But ASDF can't require each and every user to learn about
>> logical pathnames and how to set them up in their specific implementation,
>> each and every system writer to adhere to naming limitations of
>> "logical pathnames", etc. That would raise the bar to adoption, not lower it.
>
> This is only true under the assumption that what ASDF 2 adds on top of ASDF 1 is easy to learn, but that's not the case either.
>
Does not compute.

Setting up logical pathname is a step that ought to be done before ASDF
is loaded and/or used. Some implementations don't even provide a way
to load an initialization file (e.g. lwper).
If you're willing to contribute a guide to how to do these things
on each of the 15 platforms we support, I'll include it in the ASDF manual.

I could have tried to resurrect one of the old mechanisms of loading
configuration files as lisp code, but they were decidedly neither modular
nor portable nor future-proof. There's a reason they didn't take on.

>> In the bad old days of ASDF 1, I've done my lot of
>>       (:module "foo-bar" :pathname
>>       #.(merge-pathnames (make-pathname :directory '(:relative "foo" "bar")
>> :defaults *some-directory* #| required for the :host and :device slots
>> |#) *some-directory*) ...)
>>
>> NO, THANKS! Now it's just (:module "foo/bar" ...)
>
> Why was that necessary? It was possible to say (:module "foo" (:module "bar" ...) ...) [or something similar], no?
>
It's possible to have nested modules, indeed, and
rpgoldman importantly fixed the bug in module dependencies for ASDF 2.

But let's just suppose for a minute that
you're part of a project with thousands of files
where tens of developers simultaneously edit files.
At some point, you need to add a dependencyn
between files that were originally in different directories,
and you don't want to move the file,
either because it would cause painful gratuitous merge conflicts,
or just because the directories denote some logical grouping
independent from the dependency order.
Suddenly, you find yourself either creating plenty of gratuitous modules
with different names but identical pathname, or using hierarchical names,
which in the bad old days meant playing games with merge-pathnames.

> - In Section 3.1, the documentation says the following: "The simplest way to add a path to your search path, say /home/luser/.asd-link-farm/ is to create the directory ~/.config/common-lisp/source-registry.conf.d/ and there create a file with any name of your choice but the type conf, for instance 42-asd-link-farm.conf containing the line: (:directory "/home/luser/.asd-link-farm/")"
>
> This is very confusing, because the "old style" using asdf:*central-registry* is decidedly much simpler. So the sentence above needs some explanation in what sense the "new style" is simpler.
>
"old style" is much simpler if you either solve the issue of documenting
configuration for 15 different implementations, or don't support the writing
of lisp scripts distributed independently from the libraries they are using.

I invite you to read the paper Robert Goldman and I wrote,
particularly section 4.5 "Decentralized configuration".
	http://common-lisp.net/project/asdf/ilc2010draft.pdf

> - Section 5.3.6 should be renamed. The main body of the text is about how to use logical pathnames with ASDF 2, and is not a "warning." The recommendation not to use logical pathnames should also be removed, because it is not substantiated (and is therefore not a "warning," because it doesn't say what the potentially bad effects of using logical pathnames are).
>
I renamed it to "Using logical pathnames", and added a note regarding
why we do not recommend logical pathnames to newcomers.

> There are advantages and disadvantages with using both either logical pathnames or the ASDF 2 approach. Any future Common Lisp implementation that claims adherence to ANSI CL will support logical pathnames, and so it will be relatively straightforward to use logical pathnames in conjunction with ASDF 2, while ASDF 2 will probably need patching in order to support such a future Common Lisp system, which can be regarded as an advantage of logical pathnames over the ASDF 2 approach.
>
I don't believe there will be many "future Common Lisp implementations".
Several existing implementations have problems with logical pathnames
(or sometimes physical pathnames) that are decidedly not going away.
Logical pathnames have limitations that are enforced in SBCL, and make
them inapplicable to a variety of situations.

> I think that statements of personal preference should not have a place in the documentation of a tool that is supposed to be used by the whole Common Lisp community, but such a documentation should rather reflect the wide range of opinions in that community.
>
Between James Anderson and you, I know of only two people who ever care
about logical pathnames — and either of you is welcome to write a guide
to using them, though I will only include it in the ASDF doc if it is
comprehensive enough in (1) how to configure them on each of 15
supported implementations (distinguishing LW and LWper), and
(2) how to deal with physical pathnames that don't fit.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The rule is perfect: in all matters of opinion our adversaries are insane.
	— Mark Twain