Skip to content

Support for "virtual packages" / dependencies on interfaces? #222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
rgommers opened this issue Mar 23, 2023 · 6 comments · May be fixed by #450
Open

Support for "virtual packages" / dependencies on interfaces? #222

rgommers opened this issue Mar 23, 2023 · 6 comments · May be fixed by #450
Labels
Proposed new type PURL qualifiers component type: abstract Proposed new type
Milestone
PURL-TBD

Comments

@rgommers
Copy link

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 rgommers mentioned this issue Mar 23, 2023
Open
@rgommers
Copy link
Author

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.

@johnmhoran johnmhoran added the Ecma standard Part of the Ecma standard for PURL label Nov 5, 2024
@jaimergp
Copy link

jaimergp commented Mar 6, 2025

@pombredanne @johnmhoran - is this something that could make it into the standard PURL spec?

@jaimergp jaimergp mentioned this issue Mar 11, 2025
Open
@jkowalleck
Copy link
Member

jkowalleck commented Mar 19, 2025 •
edited
Loading

here is a real-world example for "virtual" runtime dependencies in php/composer:

see the docs https://getcomposer.org/doc/04-schema.md#provide

how this is applied:
i write a library, that needs any implementation of that psr/log interface, so i would add psr/log-implementation as a dependency on my library. something like a peed-dependency in npm.

{
    "name": "my-lib",
    "require": {
      "psr/log-implementation": "^3.0"
    }
}

downstream users of my library are required to bring this psr/log capability. either they provide it themselves,

{
    "name": "my-app",
    "require": {
      "my-lib": "1.33.7"
    },
    "provide": [
       "psr/log-implementation": "3.0.0"
    ]
}

or they add another dependency, that provides it (like monolog/monolog). ...

{
    "name": "my-app",
    "require": {
      "my-lib": "1.33.7",
      "monolog/monolog": "3.8.1"
    }
}

that being saied, i do not have any need for a special behaviour/handling of viartual packages. from my SBOM perspective, a virtual component has no purl, as there is no deliverable - it is just an ordinary component in a dependency tree ...

@jkowalleck
Copy link
Member

jkowalleck commented Mar 26, 2025 •
edited
Loading

here is a package ecosystem that has this concept of virtual build time dependencies: https://vite.dev/guide/api-plugin#virtual-modules-convention

Virtual modules are a useful scheme that allows you to pass build time information to the source files using normal ESM import syntax.

@jaimergp jaimergp mentioned this issue Apr 4, 2025
Merged
@johnmhoran johnmhoran added this to the 1.1 milestone Apr 5, 2025
@jaimergp jaimergp linked a pull request Apr 6, 2025 that will close this issue
Open
@jaimergp
Copy link

jaimergp commented Apr 6, 2025

I opened #450 in case anyone tracking this issue wants to take a look.

@jkowalleck
Copy link
Member

jkowalleck commented Apr 9, 2025 •
edited
Loading

since #450 is showing a clear vision, here is another thing to consider:
what about language compiler-plugins and -extensions?
In php, this clearly exists: see https://thomasventurini.com/articles/require-php-extensions-for-your-project-through-composer/

@johnmhoran johnmhoran removed the Ecma standard Part of the Ecma standard for PURL label May 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Proposed new type PURL qualifiers component type: abstract Proposed new type
Projects
None yet
Milestone
PURL-TBD
Development

Successfully merging a pull request may close this issue.

Add virtual type jaimergp/purl-spec
4 participants
@rgommers @jaimergp @jkowalleck @johnmhoran