On Sunday, September 26, 2021 at 1:10:21 PM UTC-7 Nils Bruin wrote:
> On Sunday, 26 September 2021 at 10:44:14 UTC-7 Matthias Koeppe wrote:
>
>>
>> *3. Break up Cython modules that depend on several C/C++ libraries
>> simultaneously*
>>
>> An example is sage.matrix.misc, which depends on both flint and mpfr.
>> This is https://trac.sagemath.org/ticket/32433 (which needs help).
>>
>
> The particular file you point to looks like it deserves to be
> restructured, but the way your objective is structured seems definitely
> flawed. I just wrote a cython module that essentially depends on both the
> mpfr and the pari libraries (on C-level!). I don't see how that would be
> broken up and why it would even be bad to link a cython module against
> several libraries at once.
>
It's not an objective -- it's a step that is informed by the technical
*restrictions* of modern Python packaging. The *objective* is separate
installability of modularized parts of the Sage library as distribution
packages ("pip-installable packages").
Let me explain the technical restriction: In modern Python packaging (PEP
517/518), there is no such thing as an optional build dependency: The build
of a distribution package is completely determined by the declared
build-system dependencies (in pyproject.toml "build-system requires").
There is no mechanism to denote "flavors" of binary wheels of distribution
packages based on what "optional C/C++ libraries" were available at build
time. This is why one of the first steps of the modularization project was
to eliminate the mechanism of "optional extension modules"
(https://trac.sagemath.org/ticket/29701, merged in Sage 9.2).
Because of this, the design of the modularized parts necessarily has to be
based on the compile-time dependencies on compiled libraries.
Of course there are classes and functions that depend on several libraries.
The goal of 3. is to refactor so that such necessary dependencies do not
block the separate installability and usability of modules that do not have
these dependencies on multiple libraries. The distribution packages can of
course define dependencies ("install-requires").
In the ticket list of https://trac.sagemath.org/ticket/29705 I have
sketched a few possible distributions (modularized parts). The details will
need attention by developers; finding a good design is not a mechanical
task, but it will have to take the technical constraints into consideration.
--
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/6c0ea493-ee3d-432b-bc12-8e2446b4dd29n%40googlegroups.com.
