Addressing Dependency Challenges / Future of Sage-the-Distribution

[tobiasdiez]

One of the major pain points for users and developers of Sage is the need to install a wide range of dependencies before getting started with actually building sagelib. The idea of this issue is to discuss potential solutions and hopefully converge to one long-term vision, which can then be presented/discussed further on the mailing list.

---

Problem Overview

• Installing Sage often requires handling numerous dependencies, some of which can be tricky to install due to version conflicts, compatibility issues, or the lack of packaged versions in common package managers.
• This complexity acts as a barrier for users, particularly those who are not experienced with package management or building software from source.

---

Potential Solutions

1. Provide Build and Install Scripts for All Dependencies

This is the current status quo for sage-the-distribution. Based on a minimal set of dependencies, all Sage dependencies are installed via a manually maintained set of installation scripts and a dependency tree.

Advantages:

• Convenient for users.
• Ensures a consistent set of dependencies, providing a stable basis for testing.

Disadvantages:

• Installing these dependencies is a common source of build errors, requiring developer time to assist users with troubleshooting.
• Scripts require constant updates as dependencies evolve.
• There is no automated mechanism for updating external dependencies in sage-the-distribution.
• Extensive CI testing is required to maintain the scripts, adding to the maintenance burden.
• Lack of Windows support (currently).
• The setup is not reusable in other projects.

---

2. Provide Build and Install Scripts for a Minimal Set of Dependencies

This approach involves selecting a set of supported operating systems and maintaining scripts only for a minimal set of dependencies required to install sagelib after using the OS-provided package manager. There are different flavors, Python could be managed via external tools like pyenv or uv.

Advantages:

• Reduces the scope of dependencies Sage-the-Distribution maintains directly.
• Easier to manage and test a minimal set of scripts compared to the full dependency tree.

Disadvantages:

• Users may still face challenges, especially with dependencies not included in the minimal set.
• Some dependencies would rely on external tools, requiring additional user knowledge or documentation.
• Limited to supported operating systems, reducing flexibility.

---

3. Conda

Use Conda as the primary package and environment manager for Sage. Either directly using conda/mamba or via pixi.

Advantages:

• Conda provides prebuilt binaries, allowing users to install SageMath with minimal effort and minimal chance for installation problems.
• Conda creates isolated environments, making it possible to easily experiment with different versions of dependencies.
• Works seamlessly across Windows, macOS, and Linux.
• Familiarity within the scientific ecosystem: Many contributors to projects like NumPy and SciPy are already familiar with Conda workflows.

Disadvantages:

• Users unfamiliar with Conda need to install it first and learn its basics.
• Keeping Conda recipes updated and compatible across platforms requires ongoing effort.

---

4. Meson Wrap-DB

Explore using Meson Wrap-DB to manage dependencies. Meson Wrap-DB allows dependencies to be included as subprojects, simplifying their integration into the build system. In essence it is similar to the current sage-the-distro setup, but the build scripts of dependencies are written in Meson.

Advantages:

• Meson is fast, modular, and integrates well with subprojects through Wrap-DB.
• Wrap-DB simplifies dependency integration, reducing manual maintenance.
• Other projects could profit from the work done, e.g. python-flint could use the same scripts to install flint in their project
• Perhaps it's the only approach that easily allows to build dependencies for systems that they don't officially support (e.g. Windows).

Disadvantages:

• Transitioning to Meson would require significant effort and might disrupt the current build system.
• Contributors need to learn Meson and Wrap-DB concepts, which could initially slow development.

5. Only Rely on Package Managers to Install Dependencies

This approach would remove the need for custom build and install scripts and instead rely entirely on popular package managers like apt, yum, brew, pacman for dependency management. Users would be instructed to install dependencies using these package managers, and SageMath would ensure compatibility by specifying the required versions.
If an required version is not available, Sage would simply not install the part of sagelib that requires on this dependency.

Advantages:

• This approach leverages the existing ecosystem of package managers, eliminating the need for custom scripts.
• Package managers ensure that dependencies are installed in a consistent, well-tested way.

Disadvantages:

• Many dependencies may not be available, potentially reducing the functionality of the installed sage.
• Relying on package managers may lead to conflicts between system-level packages and the versions required by SageMath, especially for highly specific or custom libraries.
• This method provides less control over the installation process, and custom patches or configurations for dependencies may be harder to manage.

Mixed Strategies

These potential solutions should not necessarily be seen as mutually exclusive. A mixed approach could combine the strengths of different strategies to balance simplicity, flexibility, and maintainability. For example: Conda could be the recommended installation procedure (3.) and otherwise Sage would simply not install parts of sagelib if a dependency is not installed via the system's package maanger (5.).

Request for Community Input

I invite the SageMath community to share their experiences and thoughts about these solutions. Are there additional tools or approaches we should consider to reduce the dependency burden?
Looking forward to your feedback and ideas!

Pinging a few people that showed interest in discussing these topics in the past: @kwankyu @dimpase @orlitzky @tornaria @antonio-rojas @saraedum

[kwankyu]

This is a good topic to open in Discussions but inappropriate as an issue, which should focus narrowly.

[saraedum]

@tobiasdiez let me know if you want me to convert this to a discussion.

[saraedum]

I would like to add pixi to the list. I think it solves many of the usability problems that a plain conda setup has when providing developer dependencies.

[dimpase]

one immediate improvement of the current sage the distro model would be to make minimal requirements not as needlessly minimal as now. You could see that e.g. on Linux systems these don't include g++ and gfortran - something which makes no sense, as all the Linux systems we support have these ready to build Sage.

These are set in build/pkgs/_prereq/distros/
You can read more on this in #36726, where a fight erupted over the refusal to add a package providing pkill to a set of minimum requirements. And yes, we still contribute to global warming by building, in CI, gcc on systems which have perfectly OK gcc's. Can #36726 be revisited, or we need to wait (hopefully not too long?) for a Sage Technical Committee to take charge of reducing the technical debt?

[orlitzky]

Now that we can build sagelib independently using meson, I'm pretty happy.

We have at least five people packaging the dependencies of sage in various ecosystems. I'm quite content to build sagelib and ignore everything under build/ from now on. If someone wants to maintain that, to each his own, but I've been saying it's a waste of time for like 15 years now.

I'll be focusing on the few remaining issues (database packages) needed to get sage into Gentoo. When that's done, if you want to use sage, install the Gentoo package. If you want to develop sage... install the Gentoo package, and then clone sage.git and build sagelib using meson.

That doesn't work for non-Gentoo users, but I think that taking a similar stance with (say) conda would be a lot more scalable than what we are doing now.

[dimpase]

I should have replied here, as Discussions are threaded! See my reply below.

[PredictiveManish]

Based on above discussions, I think:

1. Adopting Conda as primary Solution is good for all kind of people: Making Conda primary for installation, as it provides an easier setup, cross-platform experience also it is widely used in scientific community, in various other orgs.
2. For those users who prefer or don't use conda or they don't have conda in their environments, SageMath can allow use of package managers, but with a clear set of supported versions and a less complete setup in case dependencies are unavailable.
3. We can implement tools or scripts which can help automatically resolving dependencies (similar to conda's approach), which can reduce the need for manual maintenance.
4. Lastly, if Meson's wrap-DB proves effective, it could help extend support to Windows users, resolving long-standing issues with compatibility on that platform.

Please let me know is this can be an effective solution or not as mixed approach can be a better option as beginners can be covered (via conda) and there can be flexibility for advanced users (via package managers or custom scripts). This approach also remains maintainable and adaptable to evolving needs.

[dimpase]

It seems natural at this point to decouple, as much as possible, sagelib and its requirements/dependencies (a.k.a. sage the distro).

This will simplify packaging sagelib for the linux distros and for conda, as well as acknowledge the reality of how sagelib is used. People who are not interested in maintaining sage the distro won't be distracted from work on sagelib, too.

This will also make it easier to design, if desired, a slimmer alternative to the current sage the distro, which is a product of many years of incremental updates, and as such is way too complicated and suboptimal.

[tobiasdiez]

This is a good topic to open in Discussions but inappropriate as an issue, which should focus narrowly.

I was not aware that we use Discussions actively. Feel free to move it there if you think it's a more appropriate category.

I would like to add pixi to the list. I think it solves many of the usability problems that a plain conda setup has when providing developer dependencies.

Thanks for the suggestion. I agree pixi looks great (so does uv if they would support conda). I've added it as a suboption of conda in the list above since they are quite similar in many regards. Okay?

So your preference is a pixi-only setup, or how would you envision the setup to look like?

I'm quite content to build sagelib and ignore everything under build/ from now on. If someone wants to maintain that, to each his own, but I've been saying it's a waste of time for like 15 years now.
It seems natural at this point to decouple, as much as possible, sagelib and its requirements/dependencies (a.k.a. sage the distro).

While I agree with the general sentiment here, I was hoping to find a solution that would fit most people's needs and wishes. I think we have also seen that the each-developer-their-own-corner approach only works as long as the corners don't intersect. But at some point you are bound to run into problems because one person needs some change that conflicts with someones else approach. To give some concrete examples:

• Sage-the-lib cannot just require numpy 2.0 because our current testing system relies largely on sage-the-distro, which brings its own version of numpy.
• There is the plan to move some of the runtime dependency checks on programs to the build stage using meson. Easy to do in sage-the-lib; but as long as sage-the-distro is not using meson this is not possible.
• In many places, the docs refer to sage -install, which doesn't make sense for conda / pure-meson. How to improve this?

Sure, in each instance you could say, I don't care about sage-the-distro and just move ahead with the necessary changes in sage-the-lib; but then you are bound to get very angry looks from the people that would like to keep sage-the-distro as the main installation mechanism.

So, in summary, my hope was to find a way that would unite most developers to work in the same direction.

For what's worth, I personally I essentially agree with the approach sketched above by @PredictiveManish, except that I don't think we need point 3 "installer scripts": Conda as the primary installation method and to setup the dev environment; complemented by sufficiently strong dependency checks in meson to make it possible to also manually install all dependencies (say via package managers) and meson-wraps for some important dependencies that are hard to install (on a given system).

[PredictiveManish]

This is a good topic to open in Discussions but inappropriate as an issue, which should focus narrowly.

I was not aware that we use Discussions actively. Feel free to move it there if you think it's a more appropriate category.

I would like to add pixi to the list. I think it solves many of the usability problems that a plain conda setup has when providing developer dependencies.

Thanks for the suggestion. I agree pixi looks great (so does uv if they would support conda). I've added it as a suboption of conda in the list above since they are quite similar in many regards. Okay?

So your preference is a pixi-only setup, or how would you envision the setup to look like?

I'm quite content to build sagelib and ignore everything under build/ from now on. If someone wants to maintain that, to each his own, but I've been saying it's a waste of time for like 15 years now.
It seems natural at this point to decouple, as much as possible, sagelib and its requirements/dependencies (a.k.a. sage the distro).

While I agree with the general sentiment here, I was hoping to find a solution that would fit most people's needs and wishes. I think we have also seen that the each-developer-their-own-corner approach only works as long as the corners don't intersect. But at some point you are bound to run into problems because one person needs some change that conflicts with someones else approach. To give some concrete examples:

• Sage-the-lib cannot just require numpy 2.0 because our current testing system relies largely on sage-the-distro, which brings its own version of numpy.
• There is the plan to move some of the runtime dependency checks on programs to the build stage using meson. Easy to do in sage-the-lib; but as long as sage-the-distro is not using meson this is not possible.
• In many places, the docs refer to sage -install, which doesn't make sense for conda / pure-meson. How to improve this?

Sure, in each instance you could say, I don't care about sage-the-distro and just move ahead with the necessary changes in sage-the-lib; but then you are bound to get very angry looks from the people that would like to keep sage-the-distro as the main installation mechanism.

So, in summary, my hope was to find a way that would unite most developers to work in the same direction.

For what's worth, I personally I essentially agree with the approach sketched above by @PredictiveManish, except that I don't think we need point 3 "installer scripts": Conda as the primary installation method and to setup the dev environment; complemented by sufficiently strong dependency checks in meson to make it possible to also manually install all dependencies (say via package managers) and meson-wraps for some important dependencies that are hard to install (on a given system).

Yes you're right point 3 is just an additional point. We can easily eliminate it apart from it all others can do the whole bunch of tasks covering entire spectrum either beginner or advanced developers.

[saraedum]

So your preference is a pixi-only setup, or how would you envision the setup to look like?

For developers, yes. You can still pip install if you happen to have all the dependencies ready (e.g., because you are building for a distro.)

I have not migrated a project the size of SageMath to pixi obviously, but otherwise the experience has been great. It's a great means to ship a very opinionated yet robust setup…I think it gives us everything that Sage the distro ever wanted (except we loose support for any platforms that are not supported by conda-forge.)

[tobiasdiez]

I had a look at pixi and it looks indeed like a very good option. Migration shouldn't be too hard as well, and we can keep the plain conda solution for a bit parallel. Do you want to give this a shot?

[dimpase]

Now that we can build sagelib independently using meson, I'm pretty happy.

We have at least five people packaging the dependencies of sage in various ecosystems. I'm quite content to build sagelib and ignore everything under build/ from now on.

@orlitzky One use of build/ is CI - as you need to set up the environment to run tests, it's unavoidable to have something of this sort - every Python module has this issue. So we'll need to replace build/ by something.
E.g. we can explicitly set the environment for each distro we test.

By the way, does Gentoo project run CI on not yet released by them soft?

[tobiasdiez]

To bring this back to the original topic, how do we make sagelib independent enough from sage distro so that we can eg require pari 2.17 in sagelib while distro still is on an older version? This would require removing all required ci tests based on sage distro, right? What happens to developers that are using sage distro in this case?

Another aspect is the broader question under which conditions is sagelib allowed to drop backwards compatibility with a certain dependency. Eg in the context of pari, 2.17 is not available on conda conda-forge/pari-feedstock#44 - is this a problem?

[tornaria]

I think we should strive to support older versions if feasible. That's what we always try (for example, support for python 3.13 is compatible with older python).

But sometimes this is a lot of extra work, the real challenge is to support the new software, and the old software will eventually go away.

My ideal is to prioritize moving to new versions of dependencies as quickly as reasonable. Distros with older dependencies can stick to older sagemath (in other words: if they want to update sagemath, they have to update dependencies). If conda doesn't ship pari 2.17, it doesn't get to ship sagemath 10.6, but it can stick to sagemath 10.5.

The problem from the point of view of a distro is the opposite one. If sagemath doesn't support pari 2.17, then a distro is either stuck with pari 2.15, or has to drop sagemath.

One issue with sage-the-distro is that sagelib is implicitly there always, so it's difficult to update pari ahead of adding support for new pari. For instance, testing the update of pari should be about testing pari, not testing sagelib. This mindset would allow updating pari first, then work on fixing sagelib to support the new pari. In fact, sage-the-distro is not very useful for this purpose, and that is why most of the work to support new releases of software in the past years (including e.g. python, which has been breaking sagemath every october) happens on other rolling distros (arch, conda, gentoo, void, etc).

[tobiasdiez]

From a theoretical perspective, I completely agree with you. But, practically speaking, how would this look like?

Say we ignore the existence of sage-the-distroc ompletely for the moment (or call it an abstract "mechanism") and look at the pari upgrade, for concreteness. There are two aspects:

• How can one design the CI to test that the Pari upgrade PR is okay? I assume you need some kind of mechanism that currently installs Pari 2.15 (to test the current code), and that mechanism needs to be upgraded to install Pari 2.17 (to test that the new code works with the new version) in the same PR that changes sagelib, right? I might miss something, but I don't see any way how a breaking change in sagelib (like supporting Pari 2.15 > 2.17) not also requires that one needs to update the "pari-install mechanism" at the same moment.
• For developers the situationis similar. How do they test that the PR works? Do they have to install Pari 2.17 manually by following the Pari install instructions?

I just want to understand how one can achieve a better decoupling of sagelib and the "dependency update mechanism" given these practical constraints.

In some way, sage-the-distro gives sagelib the promise: hey little guy, don't worry about your dependencies. You can require whatever version you like and I'll make sure it is installed for CI and developers.

[tornaria]

From a theoretical perspective, I completely agree with you. But, practically speaking, how would this look like?

Sure, I prefixed the comment with "my ideal". I am aware there are practical constraints.

Say we ignore the existence of sage-the-distroc ompletely for the moment (or call it an abstract "mechanism") and look at the pari upgrade, for concreteness. There are two aspects:

* How can one design the CI to test that the Pari upgrade PR is okay? I assume you need some kind of mechanism that currently installs Pari 2.15 (to test the current code), and that mechanism needs to be upgraded to install Pari 2.17 (to test that the new code works with the new version) in the same PR that changes sagelib, right? I might miss something, but I don't see any way how a breaking change in sagelib (like supporting Pari 2.15 > 2.17) not also requires that one needs to update the "pari-install mechanism" at the same moment.

There are two separate concerns:

• upgrading pari to 2.17 in sage-the-distro and testing the upgrade is ok
• support pari 2.17 in sagelib and testing that sagelib works fine with it

The first one concerns sage-the-distro, so ignore for now. The second one concerns sagelib, so let's focus on that.

In order to work on supporting pari 2.17, you need to have pari 2.17, for sure. But this is concern of the distro. The main prerequisite to work on pari 2.17 support for sagelib is that your distro supports it. Some ways that can be achieved in different situations:

1. (what I do on void linux) I create a draft PR updating pari to 2.17, until I'm satisfied with pari 2.17. I can't merge this PR because it would break sagemath for users. But I can install this locally (breaking my own sagemath) or in a chroot. Then I work on sagelib with pari 2.17.
2. (what could work on e.g. debian) since debian stable has pari 2.15 and debian backports has pari 2.17.0, one can actually chose to upgrade pari to 2.17 locally, then work on sagelib with pari 2.17.
3. (what could work on CI) pick a distro that has the correct dependencies. For pari maybe this is debian testing (which currently has pari 2.17.1, as opposed to backports having pari 2.17.0).

* For developers the situationis similar. How do they test that the PR works? Do they have to install Pari 2.17 manually by following the Pari install instructions?

Either that, or they use a distro that supports pari 2.17, or they make a PR to update pari to 2.17 in their distro of choice (e.g. for conda, but also for sage-the-distro).

Going back to sage-the-distro, if decoupled it could have "stable" releases (which have the "right" versions of dependencies to build stable sagelib) but the master branch can have newer software but might break sagelib.

I just want to understand how one can achieve a better decoupling of sagelib and the "dependency update mechanism" given these practical constraints.

I don't think sagelib should have a "dependency update mechanism". IMHO it should be like any normal software: it has some dependencies, and it builds and works given that these dependencies are available in compatible versions. How the dependencies are made available is a separate concern.

In some way, sage-the-distro gives sagelib the promise: hey little guy, don't worry about your dependencies. You can require whatever version you like and I'll make sure it is installed for CI and developers.

Sure, but I see it the other way around. When sagelib requires some dependency, it's the distro job to supply the dependency, sure. That's true for sage-the-distro, void linux, debian, etc. If sagelib now requires pari 2.17, the distro must upgrade pari before upgrading sagelib. It's not such a big deal if sagelib can't be upgraded before pari is upgraded.

[tobiasdiez]

Thank you very much for this input. I have to think more about it...

Going back to sage-the-distro, if decoupled it could have "stable" releases (which have the "right" versions of dependencies to build stable sagelib) but the master branch can have newer software but might break sagelib.

So when you speak about coupling of sagelib and sage-the-distro you mean that you cannot upgrade packages in sage-the-distro independently of whether sagelib works with the new version or not, right?

[dimpase]

I've asked fpylll people to have a new release, as all this is now fixed in their master. @malb @ludopulles - bij voorbaat dank.

[averner]

Hello,

I'm having trouble with using SageMath as a Python package. In particular, to see why Groebner basis computation in a specific problem of mine takes ages, I'd like to follow the underlying code line-by-line. I compiled SageMath 10.5 on WSL Ubuntu 22.04. Then, following the instructions on this page, I installed Tkinter, reinstalled the SageMath version of Python, started SageMath Python 3.12.5 with "sage -python", then told the interpreter to process "from sage.all import *". It failed with "No module named 'sage'". The directory I run sage from is "~/sage/" and it's the one that contains both executables such as "sage", "bootstrap", "configure", and directories such as "logs", "src", "tools", etc. Inside the "src" directory, there's another directory called "sage", which contains "all.py" and other Python files with the source code. I tried to change the working directory in Python to the "src" directory and import "sage.all" again, but it failed too, this time complaining about missing "cysignals" package in SagMath Python.

Any help with this issue would be much appreciated.

Regards,
Alexander.

[dimpase]

Hi, sorry, this thread is certainly not the place to ask Sage installation questions.
Can you join https://groups.google.com/g/sage-devel and ask there?
Or on a GitHub issue, in particular if you want to sort out a particular Groebner basis computation.

[dimpase]

@averner - I've opened #39740 to deal with your issue