Currently, when you try to package sage on a new distro, you need to have all dependencies installed before you can even explore building sage. The modularization effort could be helpful in this regard, because it enables a more incremental approach where you first package a smaller subset of the dependencies, and then build (and distribute) only a subset of sage. I think this is what excited people on the debian mailing list. However, this is actually mostly a limitation of the current build system - once you can say: please compile only these parts of sage for which the correct dependencies are installed, you no longer get an advantage of modularization in this regard.
As for the main body of the modularization project, I agree there is a conflict between the needs of users and developers: - As a user, I'm okay with having a core sage project and then install certain extensions/add-ons/plugins to extend the functionality (if needed). This is a pretty common approach to split large projects, and users shouldn't be too confused (at least once it's easy enough to discover in the docs which addon one needs to install to enable a certain feature). - As a developer, I want a completely independent piece of sage code that I can directly use in my own project without pulling in a massive amount of transitive dependencies. In particular, these smaller modules need to be compiled with minimal dependencies and also their runtime interface needs be self-contained. And as Marc said, these modules need to be available on many platforms. Perhaps it's less of a "conflict" but just that developer-focused modules need more work than user-focused ones. For example, the sagemath-bliss is a nice add-on that fulfills the needs of a user. But it cannot really be used in some other projects because you need to pass a sage graph to it. So to make it more useful someone needs to put more effort in it, and rework the public interface to be useful without references to the rest of the sage project. Here is a concrete proposal to move forward with the modularization effort: 1) Create more extension distributions that users can install to complement the core functionality. The requirement is that these extensions should compile with the required external dependencies installed and with sagemath-standard installed. Ideally, they should be on pypi so that one can simply install them with `pip install sagemath-xyz`, and distributions are not required to ship all of them. The goal here is to make sagemath-standard leaner and easier to install (and compile) by moving some less-often-used external dependencies to external modules. 2) Spearhead some developer-focused modules. Perhaps, start with what Marc needs for snappy, and bundle exactly this part of sage in a new distribution. The goal here would be to see what problems you encounter and how to overcome them (eg what I foresee are a lot of circular import issues and that our current build system needs be overhauled to support building on windows). 3) Convert more and more of the user-focused distributions to developer-focused ones. A perhaps rather important question is, who actually wants to work on any aspect of this? On Wednesday, October 9, 2024 at 1:17:34 PM UTC+8 marc....@gmail.com wrote: > On Tue, Oct 8, 2024 at 8:52 PM 'Gonzalo Tornaría' via sage-devel > <sage-...@googlegroups.com> wrote: > > > For me cypari2 works really nice and it's not particularly difficult to > package (except it broke with pari 2.17, but of course having this as a > standalone package makes it much easier to fix it). What is the problem > with windows? > > The problem with Windows is just that cypari2 does not support it. > CyPari works fine on Windows. There is some trickiness required to > get cysignals to work on Windows. This is because sage's > implementation of sig_on calls setjmp and expects a signal handler to > call longjmp, but that scheme fails on Windows where each signal > handler runs in a separate thread with its own stack. However, CyPari > has a workaround for this. > > - Marc > > PS There is another problem with cypari2, completely unrelated to this > thread, which prevents SnapPy from using it, even on platforms which > are supported by cypari2. That problem is that huge memory leaks were > introduced in cypari2 by a redesign of the Python Gen class to try to > keep the Pari GEN managed by a Python Gen object on the Pari stack as > long as possible. Those leaks make cypari2 unusable for us. CyPari > has reverted to the original model, where each Pari GEN is moved to > the Pari heap when its wrapper Gen is constructed, and is freed from > the Pari heap in the wrapper's __dealloc__ method. That fixes the > leaks. > -- 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/78d08c46-4d5d-4231-bf0b-fa836170ca9en%40googlegroups.com.
