[asdf-devel] 3.1.0.75 pushed: more checking of system names

[Faré]

Dear Robert,

>> Logical pathnames are a horror that no one should use, and the
>> portability constraints of which should not be inflicted on everyone.
>>
>> Could you revert this new constraint?
>
> Not until we remove logical pathnames support from the central registry.
>
for ASDF2 and ASDF3, my policy regarding logical pathnames was
to support them on a "best effort" basis: if you respect the
portability constraints, then it will work, but some systems
do not respect these constraints and then the setup will work
if and only if the implementation supports it.

This is an upgrade from ASDF1, that didn't handle relative
pathnames correctly (e.g. "foo/bar") in the context of logical pathnames,
had no tree search at all much less on logical pathnames, etc.
Moreover, after multiple bug reports by janderson and p-cos,
the test suite now includes tests for basic logical pathname functionality,
so the support should be stable now.

I don't think we can do better, and I don't think we should try.
I don't think we should do worse by trying to enforce portability:
setting up logical pathnames early enough for them to be useful
is not portable anyway, therefore people who deal in logical pathnames
are already eschewing portability.

> It's not fair to tell people that we let them have registries like
>
> (:tree "home:lisp;")
>
> and then have them only partly work.
>
That's why instead we recommend
(:tree (:home "lisp"))
which is guaranteed to work thanks to our configuration location DSL.
The home logical pathname isn't defined on most lisps, anyway.

> If we want to refuse to support logical pathnames *at all*,
> then we can do that.  But saying we support them, and
> then leaving people open to unpredictable, odd errors,
> because we don't *totally* support them is wrong.
>
I believe we support them as totally as can be.
The limitations are inherent in logical-pathnames, not in our support.
That's why I do not recommend logical-pathnames and wish them to die;
but I don't see why to remove support after it was so painfully added.
It works, really, it does, and it is being regression tested.

> As an alternative, I would offer the possibility to simply raise an error if someone configures with logical pathnames (we'd have to also check when trying to search ASDF:*CENTRAL-REGISTRY*).
>
I don't think it helps anyone.
People who use logical pathnames are not only big boys, but old farts.
They know better, or should.

> I'm not thrilled about this alternative, because, for example, I use a "home" logical pathname host to handle the difference between /Users/rpg/ and /home/rpg/.  Also, doesn't SBCL use logical pathnames internally?  I believe other implementations do, too.  So note that, for example, it might not be possible for an implementation to bundle cl+ssl (in the event that one would like to).
>
If you use a logical pathname, you're on your own, especially on SBCL.
I recommend the use of (:home "lisp") in the source-registry,
or (subpathname (user-homedir-pathname) "lisp/") in the central-registry.
No need to magically setf logical-pathname-translations in your .sbclrc.

SBCL uses logical pathnames internally, but is careful that its pathnames
respect the portability constraints that SBCL enforces.
Many other implementations also use logical pathnames internally,
but most do not enforce strict portability constraints like SBCL.

> So before I revert this, I'd like to have a better solution in hand.
>
> Possible alternative: transform my continuable error into a WARNING or a STYLE-WARNING?  I think that wouldn't meet your desiderata, though, since you *want* logical pathname-inconsistent system names.
>
Yes, I *really* want to be able to use foo-V1.200 and such in my pathnames.
It's a requirement for QRes, and one reason why QRes didn't use
logical-pathnames (as janderson proposed it, which failed on SBCL).

> Possible second alternative: trap these cases when we try to merge pathnames with logical pathnames and warn the user intelligibly that he or she will lose?
>
> My main concern is that ASDF behave understandably for all users, and errors about illegal pathnames appearing deep in the call tree, away from the reason for their occurrence, won't meet that requirement.
>
I'd say that we just document in asdf.texinfo that we believe that
(il)logical pathnames are a generally bad idea,
that we disrecommend using them,
that using without following strict constraints is eminently non-portable,
but that if you are janderson or p-cos
or some unidentified third remaining CL hacker on earth to use them,
you're welcome to marinate in your own little hell.

> This seems like another case where trying to be nice, instead of being strict, leads us to a place where *someone* must lose. If ASDF 1 had either refused logical pathnames, or refused inconsistent module names, we wouldn't be in this pickle...
>
ASDF1 didn't care at all for portability.
It was minimal, had a thin layer over the implementation, and
almost any non-trivial use of pathnames was guaranteed to be break
on some implementation or some other.

Supporting logical pathnames was the right thing to do then, both
because they were common practice before ASDF's *load-truename* revolution,
and because not supporting them would have strayed from the minimalism.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Skill without imagination is craftsmanship.
Imagination without skill is contemporary art. — Tom Stoppard