On Jun 30, 2013, at 7:21 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 30 June 2013 18:53, Vinay Sajip <vinay_sa...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
