[Distutils] Upcoming changes to PEP 426/440

[Donald Stufft]

On Jun 30, 2013, at 7:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 30 June 2013 18:53, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:
>> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> 
>>> No, because the semantic dependencies form a Cartesian product with
>>> the extras. You can define :meta:, :run:, :test:, :build: and :dev:
>>> dependencies for any extra. So if, for example, you have a "localweb"
>>> extra, then you can define extra test dependencies for that.
>>> 
>>> The semantic specifiers determine *which sets of dependencies* you're
>>> interested in, while the explicit extras define optional subsets of
>>> those.
>> 
>> Isn't that the same as having an additional field in the dependency mapping?
>> It seems like that's how one would organise it at the RDBMS level, anyway.
>> 
>> {
>>  "install": "localweb-test-util [win] (>= 1.0)",
>>  "extra": "localweb",
>>  "environment": "sys_platform == 'win32'",
>>  "kind": ":test:"
>> }
> 
> 
> We don't get the same level of payoff by switching to a "kind"
> subfield, because all five dependency fields already use the same
> internal syntax. Whether you're keying off the top level field name,
> or keying off a "kind" subfield, the processing code will still be
> identical across all five kinds of dependency.
> 
> As far as data modelling goes, Warehouse actually splits the different
> kinds of dependency as distinct ORM classes. This allows various
> useful details (like the descriptive names for each kind of
> dependency) to be handled directly in the data model, rather than
> needing to be tracked separately.
> 
> While the two forms are functionally equivalent, I still prefer
> multiple top level fields, as I consider it both easier to document
> and more consistent with the approach used by other packaging systems.
> 

Using a kind subfield actually is harder and requires more work. There's no way around needing to process each conditional dependency and check if they match, however each "kind" is always going to be an all or nothing kind of deal. You either want to process all of the dependencies of a certain kind, or none of them. As it stands right now you can just unconditionally loop over each dependency in a run_requires. However if all there was was required, you'd need to look over the entire list and check the kind subfield. Even worse if the order you install a "kind" matters (e.g. need to install build_requires prior to install run_requires) you'll need to  loop over the list multiple times.

I pushed for this change for the same basic reason I'm against the change you're mentioning. I think in order to make things easier for processing the first thing a tool would do given a single unified list with a subfield of "kind", is split them into several variables (wether variables in their own right, or as keys in a dictionary). If the natural inclination is to split them, we should just split them up front and make things simpler. Similarly I felt that it was more natural for a tool to want to condense the *_requires and *_may_requires so that they could easily run it though a single codepath without needing conditionals scattered all over.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130630/3aff277a/attachment.pgp>