BEWARE! ENSURE-PATHNAME uses PARSE-UNIX-NAMESTRING, not PARSE-NAMESTRING. In this case, you want PARSE-NAMESTRING (possibly through PATHNAME).
(describe (uiop/pathname:ensure-pathname "home:lisp;asdf;"))
#P"home:lisp;asdf;" is a pathname, with the following components: NAME = "home:lisp;asdf;" VERSION = :NEWEST
Thanks. But isn't this a bug:
(uiop/pathname:ensure-pathname "home:lisp;asdf;" :namestring :lisp) #P"home:lisp;asdf;" [10]> (describe *)
#P"home:lisp;asdf;" is a pathname, with the following components: NAME = "home:lisp;asdf;"
That looks like a bug indeed, but after I (setf (logical-pathname-translations "home") '(("**;*.*" #p"/home/tunes/**/*.*")))
it's working for me: (describe (uiop/pathname:ensure-pathname "home:lisp;asdf;" :namestring :lisp))
#P"HOME:LISP;ASDF;" is a portable pathname, with the following components: HOST = "HOME" DIRECTORY = (:ABSOLUTE "LISP" "ASDF")
It seems to me that either probe-asd or sysdef-central-registry-search before it calls probe-asd should indeed call ensure-pathname somehow and fails to, and that that's the problem.
Here I have explicitly told UIOP & clisp that the namestring is a LISP namestring, so it should see this as a valid logical-pathname, not garble the logical pathname into a PATHNAME's name field.
That sounds like a bug indeed; however, it doesn't happen on my recent checkout of CLISP (on Linux x64, but I suppose this part of the clisp code is portable.)
This seems to have to do with an oddity (I suspect it's conforming, strictly speaking, but it's awkward at best, and impossible at worst) in clisp's interpretation of PARSE-NAMESTRING for logical pathnames.
If parse-namestring was called, it's probably not conforming to not parse the : as a host separator. If parse-namestring was not called, it's a bug in ASDF and/or UIOP, and trace will hopefully tell you as much.
I have absolutely no idea how to preserve usefulness of logical pathnames on clisp, since it looks like I would have to do a lot of horrible mess to try ripping colon-postfixed substrings off everything that might be a logical pathname, before feeding it to PARSE-NAMESTRING.
I suppose if ENSURE-PATHNAME is a bottleneck, I could try that there, wrapping some error-handling around a check...
Sometimes, you have to concede defeat and move on. Certainly if some old (or new) version of CLISP doesn't parse logical-pathnames properly, that's a bug that should be reported and then we'd move on.
IIRC, there was also a bug whereby #p"foo:" was parsed improperly for logical pathnames on Allegro (should be absolute, was relative); in this case, I had a workaround (see uiop:pathname-root and other horrors), so I just issued the bug report and moved on.
In general, logical pathnames were HELL to support, for little or no benefit. (With maybe a handful users in the whole world.) I recommend eschewing them completely. After breaking their support a few times, there are now regression tests, though, that you might want to extend to include some basic parsing.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Obama's economic policies will be so remembered that he'll be the president picked for the face on the hundred trillion dollar bill.