-
-
Notifications
You must be signed in to change notification settings - Fork 631
Remove sagemath-sirocco package #40363
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
Eventually it would be nice to have these all separated out like sagemath-giac, but in the meantime, is there some way to prevent the automatic detection during the sagelib build? What we want to avoid is,
If something like |
Please no. We are moving in the right direction with meson optionally enabling features at build time. There is no need to complicate packager's lives by splitting sage into multiple small optional packages.
It will not crash - we have been shipping sage on Arch with all features enabled for years, with sirocco being optional. If you don't have the library, then you simply won't be able to load the corresponding module (with a quite explicit error message). But even if it did crash - that is a general issue with users compiling stuff from source which you can't do much about. You can just replace "sirocco" with "pari" in your objections - nothing prevents a user from uninstalling pari after compiling and completely breaking sage (this time really crashing). That's just the way things work when you build stuff from source. If you want proper dependency management, install sage using a package manager. |
My proposal as a partial answer to this problem is #39412 - with this PR you get a quite explicit error message when you try to import a module whose dependencies are not met. But this will not solve the problem that when a user removes (or updates) a dependency, then the import of the corresponding modules may fail. I think there is nothing we can do except document that in this case the user should just rerun the installation/compilation. Personally, I see value in extracting packages if they are purely python wrappers around some native library and there is a reasonable interest from other parties to use the same interface in other python projects. Not sure if that's the case for sirocco. |
From the user's perspective, this is just a crash. Something that used to work in their code now raises an error message due to an apparently unrelated change, and the error message doesn't really explain how to fix it within the package manager. We get bug reports about it constantly. There's a whole page about it.
Our package manager is source-based. There is something we can do about it though: we can have the package optionally depend on sirocco iff the user asks for it. But for that to have any effect, we need to be able to disable sirocco support in sage when the user has it disabled it in the package manager. Otherwise installing the sage package with the sirocco feature "disabled" will still build the sirocco component if sirocco happens to be installed. This also happens to help people who are building from source. Having them as separate packages also solves the problem (just don't install sagemath-sirocco if you don't want the sirocco support), so it would be preferable if we could switch to the meson approach without this regression. |
This modularized distribution was meant to optionally install some modules depending on
sirocco
. With the new meson build backend, we already optionally install these cython modules whensirocco
is available so there is no need for a seperate distribution.📝 Checklist
⌛ Dependencies