On 20 July 2013 03:18, Daniel Holth <dho...@gmail.com> wrote:
> On Fri, Jul 19, 2013 at 11:23 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk> wrote:
>>
>>
>>>
>>> I would really like to see one more level of nesting:
>>>
>>> requires : { run : [ ... ], test : [ ... ] }
>>>
>>
>>
>> I've already changed distlib's code several times as the spec has evolved,
>> and would like not to see any more changes so that I can concentrate on some
>> real work ;-)
>>
>> Seriously, what's currently there now works OK, and the code is fairly
>> simple. I had suggested a variant with even less nesting - one single
>> "requires" list with each entry as it is currently, but having an additional
>> "kind" key with value ":run:", ":test:" etc. This has the merit that you can
>> add additional kinds without major changes, while processing code can filter
>> the list according to its needs at the time. This was shot down by Donald on
>> the basis that it would make things too complicated, or something. Seems a
>> simpler organisation, to me; any argument about additional time to process
>> is unlikely to be a problem in practice, and there are no numbers to point
>> to any performance problems. Currently, with pip, you have to download whole
>> archives while doing dependency resolution, which takes of the order of
>> *seconds* - *minutes* if you're working with Zope/Plone. Doing it in
>> tens/hundreds of milliseconds is sheer luxury :-)
>
> Either your proposal or mine would work out to be about the same. The
> advantage is that it helps people to conceptualize them as four
> instances of the same thing instead of four different kinds of things
> and it makes it easier to write a forwards-compatible implementation
> without looking for keys ending in _requires. It would also make the
> documentation significantly shorter.
Yeah, I'm mostly interested in being able to *explain* the new
metadata easily. Previously, merging the requirements wasn't
especially practical, due to the requires/may_require split. Now,
though, it's possible to merge them and have the keys match exactly
with the names used in ":run:", etc.
However, I don't think it's enough of a win to duplicate the
"requires" key at two different levels (inside the dependency
specifiers and as a top level field), so I'm happy with sticking to
"Flat is better than nested" on this one :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
