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

[Robert P. Goldman]

Faré wrote:
> Dear Robert,
>
> I'm not sure I like your latest restriction of system names to what
> logical pathnames accept: one of the big pluses of not using logical
> pathnames everywhere was to allow for a wider range of system names.
> Consider the widely used cl+ssl, for instance.
>
> At ITA, we also used to have module names like foo-V1.200, that are
> not compatible at all with your plan of forcing logical pathname
> compatibility — even less if converted to package-system where that
> would become part of the name.
>
> 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.

It's not fair to tell people that we let them have registries like

(:tree "home:lisp;")

and then have them only partly work.

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.

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'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). 

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.

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.

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

Cheers,
r