Opened 7 months ago

Last modified 4 months ago

#31164 new enhancement

Add user packages from https://wiki.sagemath.org/SageMathExternalPackages as optional/experimental packages — at Version 4

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-9.4
Component: build Keywords:
Cc: slelievre, gh-mwageringel, vdelecroix, slabbe, tmonteil Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description (last modified by mkoeppe)

At least some of them are probably not in worse shape than many of our current optional/experimental packages.

By including them as optional/experimental packages in build/pkgs:

  • they would be automatically included in our reference manual and Sage website (see #29655)
  • The GH Actions workflows tox-optional.yml and tox-experimental.yml will run them, providing continuous integration that will allow use to catch unintended breaking changes during the Sage development cycle

In this ticket, only pip-installable packages listed on PyPI will be added.

This adds an incentive to package authors to bring their packages to this form.

The packages will be added as "pip" packages instead of "normal packages", https://doc.sagemath.org/html/en/developer/packaging.html#package-source-types These do not come with tarball information and do not have to pin the version, so by default the latest version on PyPI would be installed. Hence there is no additional maintenance burden from updating the packages.

Change History (4)

comment:1 follow-up: Changed 7 months ago by vdelecroix

Before proceeding, I would like to understand what package developers and package users would gain by declaring Python packages as sage optional packages. For now, I would only consider doing this if

  • package versions were not tight to sage versions. In the curent setup a package upgrade needs a ticket review and, when merged, has to wait for a new sage version.
  • there is no serious continuous integration for packages (as they have eg for gap)

comment:2 in reply to: ↑ 1 Changed 7 months ago by mkoeppe

Replying to vdelecroix:

Before proceeding, I would like to understand what package developers and package users would gain by declaring Python packages as sage optional packages. For now, I would only consider doing this if

  • package versions were not tight to sage versions. In the curent setup a package upgrade needs a ticket review and, when merged, has to wait for a new sage version.

The solution here is to use pip packages instead of normal packages. https://doc.sagemath.org/html/en/developer/packaging.html#package-source-types

These do not come with tarball information and do not have to pin the version, so by default the latest version on PyPI would be installed.

  • there is no serious continuous integration for packages (as they have eg for gap)

Well, we do have workflows on GH Actions that at least tries to install all optional and experimental packages!

comment:3 Changed 7 months ago by mkoeppe

  • Description modified (diff)

comment:4 Changed 7 months ago by mkoeppe

  • Description modified (diff)
Note: See TracTickets for help on using tickets.