Sun, Jun 30, 2013 at 12:47 PM, Donald Stufft <don...@stufft.io> wrote:
>
> 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.
It is the same amount of hard. The dependency resolution system would
probably want to build an identical requirements[kind][extra] data
structure once no matter what the input looked liked by looping over
the very short list a single time, or perhaps expand the extra names
to all start with ":run:" + extra_name etc. The most important thing
would be to avoid having the actual installer code do anything
different based on the category of dependency so that pip doesn't wind
up with 5 different install commands.
> 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
>
>
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
