[Distutils] Upcoming changes to PEP 426/440

[Vinay Sajip]

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> The basic problem with the list form is that allowing two representations
> for the same metadata makes for extra complexity we don't really want. It
> means we have to decide if the decomposed version (3 separate entries
> with one item in each install list) is still legal.

I'm not sure how prescriptive we need to be. For example, posit metadata like:

{
  "install": ["a", "b", "c"],
  "extra": "foo"
},
{
  "install": ["d", "e", "f"],
  "extra": "foo"
},
{
  "install": ["g"],
  "extra": "foo"
}

Even though there's no particular rationale for structuring it like this,
the intention is clear: "a" .. "g" are dependencies when extra "foo" is
specified. As long as the method by which these entries are processed is
clear in the PEP, then it's not clear what's to be gained by being overly
constraining.

There are numerous ways in which dependency information can be represented
which are not worth the effort to canonicalise. For example, the order in
which extras or version constraints are declared in a dependency specifier:

dist-name [foo,bar] (>= 1.0, < 2.0)

and

dist-name [bar,foo] (< 2.0, >= 1.0)

are equivalent, but in any simplistic handling this would slip past e.g.
database uniqueness constraints. More sophisticated handling (by modelling
below the Dependency level) is possible, but whether it's worth it is debatable.

Regards,

Vinay Sajip