Skip to content

Meta-ticket: Modularize sagelib into separate distributions (pip-installable packages) sagemath-... for Sage 10.x #29705

@mkoeppe

Description

@mkoeppe

We modularize sagelib into separate distributions (pip-installable packages), so that these can be built and run with a much smaller set of dependencies. The packages are made available individually on PyPI in source and wheel form. The modularization is done without changing the overall structure of the source tree by means of PEP 420 implicit namespace packages.

Mega-PR #35095 (not for merging; changes are being cherry-picked from here for integration in Sage) adds the new distributions. Instead of defining a distribution package for every possible community or subfield of mathematics that Sage supports, the modularization project introduces three types of distribution packages:

Distributions named after a basic mathematical structure: The packages may also cover a wide range of generalizations/applications of the structure after which they are named. Users who work in a specialized research area will, of course, recognize what structures they need. The down-to-earth naming also creates discoverability by a broader audience. Not many more distribution packages than these 7 are needed:

Distributions named after a third-party non-Python dependency: This makes technical sense because the dependencies will be localized to this distribution package, but it also helps give attribution and visibility to these libraries and projects that Sage depends on.

Standard packages Optional Packages
sagemath-flint sagemath-bliss
sagemath-gap sagemath-brial
sagemath-glpk sagemath-coxeter3
sagemath-giac sagemath-mcqd
sagemath-homfly sagemath-meataxe
sagemath-lcalc sagemath-sirocco
sagemath-libbraiding sagemath-tdlib
sagemath-libecm
sagemath-linbox
sagemath-ntl
sagemath-pari
sagemath-singular

Distributions named after a technical functionality:

  • sagemath-objects: Sage extends Python's object system by dynamic mix-in classes that are driven by categories and axioms. It is loosely modeled on concepts of category theory and inspired by Scratchpad/Axiom/FriCAS, Magma, and MuPAD. This distribution package makes Sage objects, the element/parent framework, basic categories and functors, the coercion system and the related metaclasses available.
  • sagemath-categories: This distribution package contains the full set of categories defined by Sage, as well as basic mathematical objects such as integers and rational numbers, a basic implementation of polynomials, and affine spaces. None of this brings in additional dependencies.
  • sagemath-environment
  • sagemath-plot: Plotting facilities, depending on matplotlib.
  • sagemath-repl: The top-level interactive environment with the preparser that defines the surface language of Sage. This distribution also includes the doctesting facilities, as the doctests are written in the surface language.
  • sagemath-standard: Everything as provided by a standard installation of the Sage distribution. This is reduced to an empty meta-package.
  • sagemath-standard-no-symbolics

Older posts and presentations:


Initial steps: (2020)

  1. In particular, create a package sagemath-objects that makes Sage objects, the element/parent framework, categories, the coercion system and the related metaclasses available. This package would, for example, not provide or know about integers, polynomials, or matrices (thus avoiding all the dependencies on the various libraries implementing these). Ideally it would only have a build dependency on Cython and no runtime dependencies.

    (Doctesting sagemath-objects would still need more of Sage, but some it could also be done by mocking instead of with the real classes.)

    a) These facilities could see a wider use in the mathematical Python community, and in this way we could hope to benefit from a larger developer base. For example, we would hope that sagemath-objects could be ported for use with PyPy instead of CPython.

    b) Building and deploying a user package would be easier if it could depend on a small package such as sagemath-objects only instead of the whole multigigabyteness of Sage.

    This has been completed in Sage 9.6 (Modularization of sagelib: Break out separate packages sagemath-objects, sagemath-categories #29865).

  2. Remove the mechanism of OptionalExtensions from sagelib.

    Currently, a user would install, for example, the optional package tdlib and then rebuild sagelib so that the OptionalExtension sage.graphs.graph_decompositions.tdlib is built and installed.

    With this ticket, the user would instead install a new optional package sagemath-tdlib (which has tdlib as a dependency); this installs the Extension sage.graphs.graph_decompositions.tdlib (as a namespace package).

    This has been completed in Sage 9.2 (Replace use of module_list and OptionalExtension by extending find_python_sources #29701).

Not within the scope of this ticket:

Initially noted constraints and challenges: (2020)

Tickets for Sage 9.2: (2020)

see also Modularization changes in Sage 9.2 (release tour)

Tickets for Sage 9.3: (2021)

see also Modularization changes in Sage 9.3 (release tour)

Tickets for Sage 9.4: (2021)

see also Modularization changes in Sage 9.4 (release tour)

Tickets for Sage 9.5: (2022)

see also Modularization changes in Sage 9.5 (release tour)

Tickets for Sage 9.6: (2022)

see also Modularization changes in Sage 9.6 (release tour)

Tickets for Sage 9.7: (2022)

see also Modularization changes in Sage 9.7 (release tour)

Tickets for Sage 9.8: (2023)

see also Modularization changes in Sage 9.8 (release tour)

Tickets for Sage 10.0 (2023)

Tickets for Sage 10.1 (2023)

Tickets for Sage 10.2 (2023)

Tickets for Sage 10.3 (2023–2024)

Tickets for Sage 10.4 (2024)

See also: Modularization changes in Sage 10.4 (release notes)

Tickets for Sage 10.5 (2024)

See also: Modularization changes in Sage 10.5

Tickets for Sage 10.x (2024)

Wishlist tickets, loose ends

Related:

CC: @videlec @orlitzky @kiwifb @isuruf @tscrim @kliem @jhpalmieri @tobiasdiez @defeo @thierry-FreeBSD @anneschilling

Component: refactoring

Keywords: sd109, sd110, sd111

Issue created by migration from https://trac.sagemath.org/ticket/29705

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions