clhs-use-local.el strongly assumes that a quicklisp version of the CLHS wrapper is currently installed

[Hexstream]

@saraf Thank you very much for your detailed report via email! I am flabbergasted!

(Note, it is generally far preferable to discuss issues in public rather than via email, for a great variety of great reasons, but right now I don't really feel like spending the time and energy to expound on that at length, although it's certainly an important topic.)

Somewhat tragically, I already knew what the problem was after reading the first 2 lines of your email:

I followed the following steps:
(ql:uninstall clhs) to remove the existing 0.6.3

[Impressive detailed report]

Uh, oops! I did not expect you to do that, although it was a completely logical thing to do. I did not even know that quicklisp supported such an easy uninstall functionality, I seem to remember that in the past it did not. Now obviously, it does.

So, the problem is that, per the topic, clhs-use-local.el strongly assumes that a quicklisp version of the CLHS wrapper is currently installed. To summarize, clhs-use-local.el uses some quicklisp-provided information as part of its computations to locate where the clhs wrapper is installed within the quicklisp directory (completely ignoring local-projects). That information is used to compute where the HyperSpec symlink should point. But due to very poor error handling, if no quicklisp-provided clhs wrapper version is currently installed, then that part of the symlink will be "left blank" instead of signaling an error, leaving the symlink essentially pointing to nowhere. That's what you were seeing.

---

Most people will only ever use quicklisp-provided clhs wrapper instances, so they never would come across this problem, I believe. For this reason, I'm classifying this as a low priority bug. I don't have a timeline for when I might fix this, if ever, it depends on a variety of factors such as how often it trips people up and how busy I am and how I feel, etc.

(I will still leave this issue open as a continuous acknowledgement and reminder of the issue, until it is finally fixed. It can also help prevent other people from falling into the same trap.)

---

In your situation, the easy workaround, for now, is to just reinstall the quicklisp-provided clhs wrapper (0.6.3) and then proceed to also install the 0.6.4-rc1 version. When all is said and done, you'll have installed the new clhs-use-local.el (version 0.7), and after running it your HyperSpec symlink will happily point to the HyperSpec in your old (0.6.3) clhs wrapper and everything should work perfectly. :)

Right now, the easiest way to force quicklisp to download and install the clhs wrapper,
despite another version of the wrapper already being installed in a location asdf can find such as within the quicklisp/local-projects directory, is to run the following in the Slime REPL:

(progn
  (ql:use-only-quicklisp-systems)
  (ql:quickload "clhs"))

Now that the quicklisp-provided clhs wrapper is (re)installed, restart your Common Lisp implementation by invoking ,restart-inferior-lisp in the Slime REPL. (Unfortunately, there is currently no other easy way to undo the effects of (ql:use-only-quicklisp-systems), nor of temporarily enacting its effects with a macro possibly called with-quicklisp-systems-only.)

After that, invoke (ql:quickload "clhs") or (asdf:load-system "clhs") to load the 0.6.4-rc1 release candidate and proceed with installation. Let me know how that goes!