In #46 I changed the loading mechanism from using asdf:central-registry to using ql:local-project-directories. For a user based kernel installation this is fine, but it appears to have broken system-wide kernel installations because /usr/local/maxima-jupyter/system-index.txt is only writable by root. (Quicklisp uses this as the ASD system index).
To fix this we can revert this change, but I think that this is just fixing the symptom and not really the core issue. Basically, I don't think we should be using Quicklisp in system-wide installations.
First consider a system-wide installation that is not image based. If we put the the Maxima-Jupyter files in /usr/share/maxima-jupyter and have the kernel spec file load from there then each user that tries to access the kernel will have to have quicklisp setup before they run the kernel. The support libraries (babel, ironclad, etc) will be installed on a user specific basis into ~/quicklisp. This is because Quicklisp doesn't have a concept of a system-wide library.
Second consider a system-wide installation that is based on an image. That image will be generated in the Quicklisp environment for a specific user. This means that references to ~/quicklisp will be preserved in the image. Furthermore, if the root user creates the the kernel image then there will be references to /home/root/quicklisp in the kernel.
In either of these cases, Quicklisp will only be functional if the image is loaded by the user who created it. The Maxima-Jupyter kernel will still work, but if the user tries to use ql:quickload it probably won't work.
I am hoping that the solution to all of these issues is to use Quicklisp's ql:bundle-systems to create a Quicklisp independent bundle of dependencies for system-wide installations. For non-image based kernels we just dump the bundle into /usr/share/maxima-jupyter. For image based kernels we generate the bundle, then re-run Maxima, load the bundle and dump the image. In either case the resulting kernel won't have any references to a user based Quicklisp and will work even if the user has not installed Quicklisp.
For user based kernels nothing would change. We keep using Quicklisp.
Copied verbatim from this comment in a now-closed thread dated 2019-04-19 by @yitzchak:
In #46 I changed the loading mechanism from using asdf:central-registry to using ql:local-project-directories. For a user based kernel installation this is fine, but it appears to have broken system-wide kernel installations because /usr/local/maxima-jupyter/system-index.txt is only writable by root. (Quicklisp uses this as the ASD system index).
To fix this we can revert this change, but I think that this is just fixing the symptom and not really the core issue. Basically, I don't think we should be using Quicklisp in system-wide installations.
First consider a system-wide installation that is not image based. If we put the the Maxima-Jupyter files in /usr/share/maxima-jupyter and have the kernel spec file load from there then each user that tries to access the kernel will have to have quicklisp setup before they run the kernel. The support libraries (babel, ironclad, etc) will be installed on a user specific basis into ~/quicklisp. This is because Quicklisp doesn't have a concept of a system-wide library.
Second consider a system-wide installation that is based on an image. That image will be generated in the Quicklisp environment for a specific user. This means that references to ~/quicklisp will be preserved in the image. Furthermore, if the root user creates the the kernel image then there will be references to /home/root/quicklisp in the kernel. In either of these cases, Quicklisp will only be functional if the image is loaded by the user who created it. The Maxima-Jupyter kernel will still work, but if the user tries to use ql:quickload it probably won't work.
I am hoping that the solution to all of these issues is to use Quicklisp's ql:bundle-systems to create a Quicklisp independent bundle of dependencies for system-wide installations. For non-image based kernels we just dump the bundle into /usr/share/maxima-jupyter. For image based kernels we generate the bundle, then re-run Maxima, load the bundle and dump the image. In either case the resulting kernel won't have any references to a user based Quicklisp and will work even if the user has not installed Quicklisp.
For user based kernels nothing would change. We keep using Quicklisp.