PEP 725: Specifying external dependencies in pyproject.toml

[rgommers (Ralf Gommers)]

@fungi

Some prior art, though focused primarily on system package managers
in GNU/Linux distributions

Thank you @fungi, that is very helpful. I wasn’t aware of these tools yet. The use of name mapping between package managers is a key use case of this new metadata, and we did start on a second PEP and aim to prototype a generic mechanism like that. The prior art section has several other examples of name mapping tools, for R, Fedora and conda-forge: https://github.com/rgommers/peps/blob/pep-name-mapping/pep-9999.rst. This draft is nowhere near ready for submission, but there is a detailed worked example that will hopefully be insightful to how tools can use the [external] metadata.

@FRidh

If I am correct they’re added to the list because meson can use these tools for dependency detection, right? Then I would expect them to be native to the build machine.

You are completely right, that example has to be fixed. And yes, it may be quite useful to annotate each example with more comments as to what the dependencies are and why they are where they are. I’ll aim to do that in a follow-up PR.

@barry-scott

How are virtual deps resolved?
Does each platform provide a plugin to do the mapping?

I hope the link to the “name mapping” PEP draft above helps answer this. I’ll note that I wouldn’t expect any resolving to happen for a build command like pip install some-pkg (at least in the near future); only for things like recipe generators or error messages.

@barry-scott

Virtual C will work for a lot of projects, but some must have gcc or llvm.
H is that expressed?

How are minimum versions managed for tools like C compilers and packages?

If you must have GCC or Clang specifically, then that’s a regular PURL instead of a virtual package. So pkg:generic/gcc.

For minimum versions, see the open issue on PURL version specifiers. And in addition I’d also expect that one would check that in their build config files for a compiler, and error out for too-old versions.

@petersuter

Does this support vcpkg?

PURL by design can be extended to any package manager, and I see that a vcpkg contributor opened a PR a few weeks ago to do exactly that: A purl spec for the C/C++ package manager vcpkg by michaelbprice · Pull Request #245 · package-url/purl-spec · GitHub.

That said, vcpkg is almost always not the canonical location for a package, so I’d expect it to be quite rare for a Python package to contain pkg:vcpkg/ (just like it should be quite rare to see pkg:conda/, pkg:brew/ or pkg:nix/). You’re supposed to refer to the primary upstream package location, so another language-specific repository like pkg:cargo/ or otherwise a pkg:generic/ or the VCS repo like pkg:github/.