Opened 5 years ago

Last modified 4 years ago

#23465 new enhancement

Groundwork for 'abstract' spkgs

Reported by: Erik Bray Owned by:
Priority: major Milestone: sage-wishlist
Component: build Keywords:
Cc: Luca De Feo Merged in:
Authors: Erik Bray Reviewers:
Report Upstream: N/A Work issues:
Branch: u/embray/build/abstract-spkg (Commits, GitHub, GitLab) Commit: bff1d78ae1b0c489c70d1b0f75ee0df59e0b2f96
Dependencies: Stopgaps:

Status badges


Sage has some sets of packages (currently all in pairs, but theoretically of any size) of which one can be chosen to fulfill a particular dependency. Most notably with have python2/python3, mpir/gmp, and openblas/atlas, as well as a few other examples I've identified.

Currently this is handled as special cases, but I'm working toward generalizing this case, as having a more formal way to handle this case will be useful for future work.

This proposes a kind of "abstract" spkg, inspired partially by Debian's virtual packages, but not exactly the same hence a different name. Abstract packages don't install any files. They have a version (for the sake of consistency), but it is always "0.0.0". Multiple real packages can be said to "provide" an implementation of an abstract package, and only one such package is selected at any given time as the provider for an abstract package. An abstract package can then be used as a dependency of other packages, and should be used, in most cases, where multiple real packages can provide that dependency.

This implementation is currently effectively little different from what existed before, but instead of having special variables in the Makefile ($(PYTHON), $(BLAS), etc.) use the abstract packages. The main advantage of using abstract packages for this is that it's a little more transparent, and it also reuses the package concept as a way of enumerating available abstract packages and their metadata. This isn't fully taken advantage of by the work in this ticket, but this will be helpful for other work I'm doing, especially #22510.

In addition to the "python" (for python2/python3), "mp" (mpir/gmp), and "blas" (openblas/atlas) abstract packages, this also adds two abstract packages:

  • boost, which can be provided by boost_full, or boost_cropped, where boost_full is renamed from the original "boost" optional package
  • pari_seadata, which can be provided by either pari_seadata_small, or the full pari_database package

Another possibility I identified for an abstract package is database_stein_watkins/database_stein_watkins_mini, but neither is currently a dependency of any other package, so I left it alone for now. And gap/gap3 don't have an abstract package simply because I don't think gap3 can actually be used by Sage as a replacement for GAP 4, so it wouldn't make sense to cover in an abstract package.

It should be noted that two providers for an abstract package may, in general, be installed simultaneously (e.g. python2/python3). However, there are some cases where it does not make sense to install them simultaneously. This lays some groundwork for one package to "replace" another, but this doesn't make a lot of sense except as part of #22510, since it's not otherwise easy to uninstall a package.

Possible TODO items for this ticket or a related on:

  • Add additional metadata to abstract packages. Maybe they should still at least have an SPKG.txt explaining what they're for.
  • Rework how providers for abstract packages can be selected at configure time, so that this can be done in a standard way.
  • Fix the awkward package 'types' of some of the abstract package providers. For example, 'python2' and 'mpir' are considered 'optional' packages, even though they are actually standard requirements, and as such there are some hard-coded special cases for them. This ticket doesn't immediately fix this issue, but I think it will help.

Change History (5)

comment:1 Changed 5 years ago by Erik Bray

I'm working on a solution to #21524 that I'll probably rework this on top of if/when that's ready.

comment:2 Changed 5 years ago by Luca De Feo

Cc: Luca De Feo added

comment:3 Changed 5 years ago by Erik Bray

Milestone: sage-8.1sage-8.2

comment:4 Changed 4 years ago by Erik Bray

Milestone: sage-8.2sage-8.3

comment:5 Changed 4 years ago by Erik Bray

Milestone: sage-8.3sage-wishlist

This would still be good to do, but I'm going to need to come back to it, esp. in the context of #24919.

Note: See TracTickets for help on using tickets.