Oh. I wasn't paying very close attention when I looked at that file. I am familiar with manylinux wheels, of course. I guess I was too busy being impressed by the size of the file.
The real driver of the complexity, then, is the number of different versions of python which Sage is obliged to support, and that in turn is driven by which Python versions are provided by the various distros that Sage supports. Of course the macOS app uses only one version of python, which it embeds, namely the one built with Sage's spkg. When I build Sage for the macOS app my current process is to first run Sage's standard build (disabling all "system" libraries and enabling as many optional packages as possible) and then, when that is done, I use Sage's pip to install current versions of pillow, jupyterlab and notebook from binary wheels. I use the following arguments to pip: install --no-user --force-reinstall --upgrade-strategy eager That means that several packages that Sage built from source get clobbered and replaced by packages installed from binary wheels. But Sage ends up with current (as of the time of my build) versions of jupyterlab and notebook, and those two packages end up having the dependencies against which they have actually been tested. (I don't believe that even a project as large as jupyter has the capacity to test against all combinations of dependencies which would meet their specifications, but I do believe that they test pretty thoroughly against the newest allowed version of each dependency.) I do a sanity check to see that the installed versions of jupyterlab and notebook work at a basic level, using the Sage kernel, but I don't really have any way of testing jupyter or its dependencies more carefully than the jupyter project itself does. So, for the macOS app, I have basically delegated the choice of wheel versions for the jupyterlab and notebook dependencies to the jupyter project. I think that few of the dependencies of those two packages are critical to other parts of Sage, with notable exceptions being IPython and its dependencies. - Marc PS I am also delegating the choice of version for many image processing libraries to the Pillow project, and trusting them to compile the libraries. On Sat, Aug 10, 2024 at 10:40 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > On Friday, August 9, 2024 at 7:37:34 AM UTC-7 Marc Culler wrote: > > I was naively looking at this from the point of view of someone > maintaining a port of Sage to a single platform, which also happens to > allow a single binary wheel to work for multiple versions of the OS. > Looking at that linked file [ > https://github.com/sagemath/sage/blob/fdc545367173f836890b9cddbce0d7c032b10d2b/build/pkgs/rpds_py/checksums.ini] > reveals that the linux situation is infinitely more complex. The version > "pinning" apparently must be done separately for each release of each > distro. > > > These are not really tied to "Linux distro releases". Instead the Python > PA has defined common-denominator platforms called "manylinux" that are > basically keyed to the GLIBC version. (That's what "2.17" in > "manylinux_2_17" refers to.) In addition, there are common-denominator > platforms for a different libc implementation, "musllinux". > > Probably there is no way to tame that maintenance headache. Possibly Sage > could hope to "delegate" the job of deciding which version of each binary > wheel is optimal for each release of each distro to the package > maintainer(s) for that distro and to copy the data for those checksum.ini > files from some known location within each distro. However, I don't see > how that will work for the majority of distros given that they are not > close to supporting the current version of Sage. > > > That's the upstream projects' burden, not ours; in fact, the upstream > projects delegate this burden to a large extent to the infrastructure that > is provided by https://cibuildwheel.pypa.io/en/stable/ > > I don't know if this scheme will end up being simpler than installing Rust > in the Sage build directory (which involves very little more than > downloading and running rustup.sh). I hope it will. > > > I also don't know for sure, but I'm simply not keen on taking on the work > of maintaining anything Rust-related just to know with greater certainty. > > It's good to have a clear boundary of the project. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sage-devel" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sage-devel/vFsNl87zLxo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/03d03a54-609c-444d-b834-7fb0663a8c7fn%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/03d03a54-609c-444d-b834-7fb0663a8c7fn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CALcZXRHJz02NncFBjzQmp21q2R8kEquP9_K9KkBbDfGHHNs%3Dsg%40mail.gmail.com.
