On Fri, Jul 5, 2013 at 4:25 AM, Vinay Sajip <vinay_sa...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig