>
> 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 :-)
Let's not keep on chopping and changing parts of the JSON schema unless there
are actual progress stoppers or missing functional areas, as we recently
identified with exports/scripts. It looks as if you and I are the only ones
actually implementing this PEP at present, so let's work on interoperability
between our implementations so that we can e.g. each build wheels that the
other can install, and so on. Interoperability will help confirm that we
haven't missed anything. AFAIK distlib tip is up to date with PEP 426/440 as
they are today - someone please tell me if they find a counter-example to this
assertion.
Regards,
Vinay Sajip
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
