PEP 804: An external dependency registry and name mapping mechanism

Packaging Standards
42

Thanks for the feedback, @mhsmith!

For consistency, I think this should say “specifier” rather than “identifier”.

Noted, will update.

Since the placeholder may expand into multiple tokens, it wouldn’t make sense for the item to contain any other text, so suggest changing “include a {} placeholder” to “be a {} placeholder”. Or maybe, for future extensibility, the placeholder should be given a name like {specifiers} .

The choice of “include” there is intentional. In some package managers you may need some boilerplate around the placeholder of the specifier. More specifically, cases like --package={}. That said, it feels like this can be done in the specifier_syntax dict too, so I’ll double check whether we can remove it.

What’s the distinction between exact_version and equal , and how does this relate to the DepURL? The conda example uses == for exact_version and = for equal , but conda defines = as something which doesn’t correspond directly to any PEP 440 operator.

  • exact_version is a literal string equality, just like PEP 440 ===. However, some package managers don’t have the notion of operators, so we need to provide this subset of functionality separately too.
  • equal is PEP 440 ==, which has dual behaviour: literal version matching, and fuzzy matching (if requested with a .* suffix). The closest mapping between PEP440 and conda is the one described in the example (conda’s = is always PEP440 ==x.y.*).

not_equal is not one of the operators allowed in PEP 725; I guess this is an oversight.

It is not included in PEP 725 because some package managers do not support it, and we want to avoid the presence of incompatible DepURLs for now. However the specifier_syntax dict does specify all operators in case that changes in the future. I understand this is confusing though, so I’d be happy to clarify further if needed.

This shouldn’t have braces.

Good catch! Will fix.

1 Like