Open dyne2meter opened 3 months ago
Thank you for reporting this issue.
Those tracebacks are both describing the same error. The error is that the symbol ____chkstk_darwin does not exist in your C runtime library /usr/lib/libSystem.B.dylib, but that symbol is referenced by the file libsodium.26.dylib which is part of the zmq package. The symbol is missing because the zmq package was built for a minimum macos version of 10.15, as the error message helpfully points out.
The parent directory of that dynamic library is named .dylibs which indicates that zmq was installed by pip from a binary wheel built using delocate, as is typical for binary wheels on pypi. And that is true. The zmq library, along with all of the other dependencies of the Jupyter notebook and jupyterlab packages , was re-installed inside the app using current (at the time) binary wheels. Those installations replaced the ones that were built from source in the Sage build process. For the Sage build process we set a minimum OS version of 10.12. Of course the actual minimum OS version is the maximum of the minima used for all packages. You have discovered that the developers of the zmq package are no longer supporting anything older that 10.15. (I still remember the nightmare which followed the release of macOS 10.14 (Mojave), so I can empathize with their desire to drop it. But I also remember that 10.13 (High Sierra) was a high point for pre-dark-mode macs )
Anyway, I think that means that the SageMath-10-4 app requires at least macOS 10.15, at least if you want to use Jupyter and have it work "out of the box". I was not aware of that until now.
However, there is a possible workaround, albeit a slightly unpleasant one. If you have an older installation of the notebook and jupyterlab python packages (and their dependencies) that work on your system, then you could try to force Sage to use that version instead of the one installed in the app by specifying the installation path of the working packages in the PYTHONPATH environment variable. The settings menu in the SageMath app allows specifying values for environment variables to be used when running Sage with the app. So there is a chance that you could set the PYTHONPATH in such a way as to make Sage use an old version of notebook and/or jupyterlab. To do the equivalent thing from the command line, without using the app, run this command:
env PYTHONPATH="/path/to/jupyter/package" sage -n jupyter
There are no guarantees, of course. But if you can make that work, please let us know.
Thank you so much for the feedback. The jupyter notebook / jupyter lab from outside sage runs fine until I try to use a sage kernel. I'm always this curious when something doesn't work, and at this point, I accept that using old hardware has its limitations. I accept updates to my python3 installation via MacPorts and the negative consequences are often of this sort. I have a machine I could upgrade to 10.15, but it wasn't designed to accommodate Catalina and would probably end up using memory swapping a lot, slowing things to an uacceptable level.
It so happens that the 10.3 sage app package works on my Mojave machine for running sage inside a notebook or jupyterlab, but I see the end of the trail ahead. On the 10.13 machine, I won't try to use anything more than the last sage that zmq won't reject. By the way, installing Julia and its kernel encounters the same problems building an interface with jupyter. It all relates to the same components around zmq, I will guess. I pretty much need a package that works out of the box, so I'll stick with what works that way.
The 3-manifolds project is heroic, so thanks for all the effort in building and maintaining it! I'll post more if I settle on something that works systematically. Cheers!
The 10.2 release works with the notebook interface on Mac OS High Sierra 10.13, and that certainly should suffice for me. I use these old platforms because they run software that won't run in more recent systems.
Did you try setting the PYTHONPATH with the 10.4 app?
It might work to install an old Jupyter package in a venv and set the PYTHONPATH to the site-packages directory in the venv.
I did try, but kind of feebly, because my Python-fu is not strong. I set the pythonpath to the version of the script that launches jupyter in my MacPorts installation, which was obviously not the way to go about it. Or maybe that's precisely why it didn't work -- but as I said, I use the MacPorts jupyter with their python3 kernel without issues, and I suppose that their version of zmq has to work with it. I know a little about virtual environments, which MacPorts uses extensively via their "select" subcommand, but they automate it for me. If you can explain a little about what kind of venv I should be looking for, I can try again. I mean, I have the venv of the Sage 10.2 site-packages that seems to be working for me. I'm a bit confused, but not quite dazed yet. ;-)
I should add further information about the peculiarities of my setup. I use a csh variant for my shell and so my shell command would start with set; choosing the 10.2 venv does not work. I'm happy to keep trying to see if there can be a workaround for this old machine.
I think there may be a much simpler way. Try running this command in your terminal:
sage -m pip install --force pyzmq==26.2.0
That should install an appropriate version of pyzmq in your directory: ~/Library/SageMath-10-4/lib/python3.12/site-packages and SageMath-10-4 should look there first, so it should find the one you installed instead of the one inside the app.
It turns out that the pyzmq project does offer a binary wheel which works on older versions of macOS, as well as one which requires macOS 10.15. I have no idea why. If I had known that I would have used the one for 10.9 and up when I built the app. I will do that for the next release.
Please let me know if that works. Of course you may only find the next package which requires macOS 10.15, but at least that is a finite process.
On second thought, since you have multiple versions of Sage on your computer, it might be safer to start SageMath-10-4 from the app, and then do the installation from within Sage by running the command
%pip install --force pyzmq==26.2.0
That way you can't accidentally install the package for SageMath-10-2 instead of SageMath-10-4.
Genius! A thousand thanks for your research. It worked on the first try, starting sage and using the pip install command. It doesn't matter to the notebook interface whether I start the notebook using the script in my MacPorts distribution and select the sage kernel for 10.4, or whether I use sage -n jupyter. So that's a pretty finite process, for the time being. A grateful planet rejoices!
This is the error log from the given command
The command line version works fine started from my sage launcher script in /usr/local/bin.
I have also tried starting my MacPorts installation of the jupyter notebook and selecting the Sage 10.4 kernel which is visible in the interface. The error log is different, and perhaps not informative, but I will include it:
... and so on. I see the messages about a python library that was built for Mac OS X 10.15, so maybe that's the issue. If this is an idiosyncratic issue with my installations of sage and python/jupyter, I guess I'd be happy to revert to an earlier version that works, but if there's a more general issue that needs to be resolved, I'm happy to follow any advice I'm given.