PEP 804: An external dependency registry and name mapping mechanism

[stefanor (Stefano Rivera)]

@rgommers

If anyone knows a good person to ask, it’d be great to hear that or to ping them directly to please have a look.

I’m probably the best person to talk to for these issues. I think I’m more involved here than anyone else in the Debian community.

General to this proposal. External dependencies have been a headache forever, and making it easier for users to navigate this is long-overdue.

So, Debian context:

• Debian packages use a standardized approach to map PyPI modules to Debian packages. The python package providing a public module is typically: python3-{import_name}. That’s not always true. Some sub-communities within Python use a prefix, like python3-django-X. And Python applications (that aren’t typically used as a library) will just be named after the application.
• It doesn’t make any sense to map an exact dependency into a Debian (or probably any distro) package in a generic context. Debian packages have a packaging revision encoded in the version (e.g. python3.14 version 3.14.0-4 has the -4 Debian suffix). So, exact dependencies of upstream versions map to version ranges of Debian packages. (python3.14==3.4.0 would map to python3.14 >= 3.4.0, python3.14 << 3.4.1~).
• The specifier_syntax scheme doesn’t look like it allows any way to transform versions PEP-440 pre-release versions into sensible Debian package versions. (Any part of the version that starts with a|b|rc gets a ~ prefix, which sorts it above an empty string in Debian version comparisons.)

Other feedback:

• The meaning of “query packages” is not defined. I can guess that it means “Display information about the named package (which may or may not be installed)” from context, but this could be spelled out. Other potential meanings: Looking up potentially installable packages, Listing installed packages, Searching for packages matching keywords.
• How do we handle packages that change name across distro versions. e.g. library packages usually contain the SONAME to allow co-installability of multiple versions during the transition. In your example Ubuntu mapping, dep:generic/libffi maps to libffi8, but a couple of releases ago that would have been libffi7. So, do we list all potential variants of the package name? Or do we version the registry by distro release?
• The distinction between build, host, and run is not clear in either PEP. It took me a while to understand that this is about providing context in interpreting a PURL. I raised this in the PEP725 thread, but both PEPs could make this clearer.
• I don’t see any built-in primitives to make derived distributions simple. I guess any Debian derivatives could just be mapped to the same mapping file as Debian (assuming we can have a single file that covers all releases), but we could have an inheritance mechanism to allow derivatives to override things.