[Distutils] Upcoming changes to PEP 426/440

[Daniel Holth]

On Fri, Jul 5, 2013 at 4:25 AM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
> 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

I would really like to see one more level of nesting:

requires : { run : [ ... ], test : [ ... ] }

The parser and the specification will be simplified by putting all of
the the requirements categories inside a uniform dict instead of
having magic _-separated top level key names that have to be mapped to
the "run", "meta", "test" category names.

That way the top-level parser can just check:

if metadata['requires'].keys() contains only the allowed values:
parse_requirements(metadata['requires'])

Then parse_requirements() works the same no matter how many
requirements categories there are.