On Thu, 2023-04-27 at 12:37 -0700, Matthias Koeppe wrote: > A problem only arises when you try to build a bleeding-edge sage on an older > stable distro -- an undertaking unsupported by most projects. > > Is it? I would say that Sage is very special in this regard because of its > extreme number of complicated dependencies; and because of its > long-standing goals of empowering the members of the user community to > become contributors.
"Unsupported" was too strong, but a lot of large projects expect a higher level of sophistication from developers than users. For example, you're expected to have the latest GNUlib or autotools installed, or perhaps the latest LLVM, and a concoction of obscure test-suite dependencies. Gentoo stable is still on openssl-1.1, and I've had to put 3.x in /usr/local a few times to build projects that got tired of adding #ifdefs. This does... interact... with the goal of making it easy to contribute. But the complexity of the sage distribution and build system also makes it harder to use and develop sage. > But this creates a serious barrier: If Sage development can only be done on > bleeding-edge distributions, new Sage developers need to abandon their > current distribution. That's really bad. I agree, and "unsupported" carried the wrong connotation. You can certainly develop on those distros, but you're responsible for obtaining the dependencies. You can find them in a third-party rpm/deb repo, or build them in /usr/local, or install them with Nix/Conda/Guix. How difficult this is depends on how deeply the dependency is embedded in the tree. You know this, but for the sake of the list: you can't build only a local copy of PARI, you have to build local copies of anything else that will be linked to both PARI and sage. Otherwise it'll crash when you load both PARIs into the same process. In contrast, a python package at the edge of the graph can be installed locally with only a "pip install". We should take that into account when deciding how important backwards- compatibility is for a given package; there's no silver bullet. > Anyone bothered by this can of course send us patches that extend > compatibility to older PARI. > > Would we welcome such patches? When we upgrade a package such as PARI, > typically very experienced Sage developers have already assessed how easy > it would be to keep the old version supported. When it is decided to drop > support, it is often not because we don't know how to support both but > rather because we do not want to have more complicated code in Sage. We would have to take into account that breaking compatibility will force people on old distros to build local copies of not only pari, but also lcalc, giac, eclib, etc. Cleaning out the sage test suite will help some, but we will inevitably spend more time on compatibility than we do now. I think it's a better use of our time though. We'll be spending time making sure it works out of the box, rather than spending time on the fallback that we have to use because it doesn't work out of the box. -- 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/3e81f21d8b1723cf8ad6b0d632cae9393dab5c40.camel%40orlitzky.com.
