[Distutils] Upcoming changes to PEP 426/440

[Donald Stufft]

On Jun 30, 2013, at 4:26 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> Donald Stufft <donald <at> stufft.io> writes:
> 
>>> 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.
> 
> I take Nick's points regarding his preference and the reasons for it, but
> I'm not convinced by "harder". Having actually implemented the processing
> logic in distlib, it didn't seem especially hard to me. We already have more
> "kinds" than the other dependency systems Nick mentioned: one advantage of a
> single list of the kind I described is that you could in theory add
> additional "kinds", for example ":doc:", without much impact. Not that I'm
> arguing for any such addition - I'm quite aware of YAGNI. However, the fact
> that the single-list offers such possibilities is satisfying (as in, it
> feels right), and having implemented the multiple-list solution in distlib
> already, it just struck me that a single list would be more elegant. Leaving
> ORMs aside, I'm pretty sure if I was just working at the RDBMS layer, this
> is how I would structure the dependencies - using a single "dependency" table.
> 
> It's a matter of detail as to exactly how a tool would process the single
> list - I'm reasonably confident that a readable/understandable and
> sufficiently performant implementation is achievable using a single pass
> over the JSON, and furthermore, worrying about multiple passes at this stage
> feels like premature optimization.


I'm not worried about the speed or performance, I'm worried about how annoying it is to write a tool that processes it. I optimize for the API it presents. Given your suggestion the first thing I'd do is take the single list and split them into multiple lists for easier processing. It's the (IMO) natural thing to do given a single list like that given the phased nature of installation. If it feels natural to split it, then you might as well split it up front and save the implementers from needing to do so. You might disagree, and that's fine. But it's not a performance based argument.

As to the other question of adding new things, you can add a new top level keyword just as easily too in a completely backwards compatible fashion. If I was nitpicking i'd stick it in "dependencies": {"runtime": […], "build": […]} just for organizations sake. But I'm perfectly happy with them being top level key words too.

> 
> Regards,
> 
> Vinay Sajip
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
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/4d5f0d83/attachment.pgp>