Support for "virtual packages" / dependencies on interfaces?

[rgommers]

Hi, thanks for all your work on PURL, it looks excellent. I have a question/proposal, but let me first give some context on why I'm asking. Right now I am co-authoring a proposal for external dependency specifications for Python packages, and we're considering adopting PURL as the format to reference packages that are not present on PyPI and therefore cannot be captured in existing metadata for Python projects.

A package can have different types of dependencies at build-time and at runtime. All the concrete ones, like "version 3.1.0 of libfoo" or "the bar program from crates.io" are already covered by PURL. However, there are more abstract dependencies too, such as "a C compiler", or "a BLAS library" (BLAS is a standard interface/API with multiple libraries "providing" an implementation). Right now I don't see any way to express that with PURL, nor did I find a previous discussion about it. And a generic PURL type does not seem appropriate. Packaging ecosystems like Conda-Forge or Debian typically are able to express such a concept, and expose it to packagers and sometimes even users. For example, Debian uses update-alternatives to allow switching between different BLAS libraries; another package that uses BLAS will then transparently switch from one provider to another (e.g., libatlas to libopenblas).

Right now I sketched out something PURL-like, using virtual: instead of pkg: as the scheme. However, I'd like to ask if you'd consider including this in PURL. A couple of options we thought of:

(1) An abstract PURL type, with the namespace component being used for the kind of abstract/virtual dependency. This could look like (can use virtual instead of abstract here):

• pkg:abstract/compiler/c for compilers. other examples: pkg:abstract/compiler/cpp, pkg:abstract/compiler/rust, etc,
• pkg:abstract/interface/blas for interfaces. other examples: pkg:abstract/interface/openmp, pkg:abstract/interface/mpi, pkg:abstract/interface/lapack, etc.

(2) A new virtual: or vpkg: scheme. This would

• virtual:compiler/c (or vpkg:compiler/c)
• virtual:interface/blas (or vpkg:interface/blas)

For the scheme:type/namespace/name PURL components, option (1) would make namespace mandatory probably, defined to compiler or interface, and perhaps other kinds of virtual dependencies. Option (2) would use type instead of namespace for the kind of dependency (compiler or interface, maybe others in the future), so that'd fit slightly better in that respect. But it'd be a new scheme rather than a new type, so it'd be a larger change in that respect.

These abstract/virtual dependencies clearly cannot apply to SBOM's, but they're quite important for packaging systems. The process of building or installing software package transforms virtual into concrete dependencies.

Does this seem of interest?

[rgommers]

I'll note that the Python Enhancement Proposal including this virtual package concept is now available: https://peps.python.org/pep-0725.

If a PURL maintainer has thoughts on the virtual package question in this issue, it'd be great to hear them.