[Distutils] PEP 426 updated based on last round of discussion

Donald Stufft donald at stufft.io
Tue Jul 16 21:34:01 CEST 2013

On Jul 16, 2013, at 1:54 PM, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> Donald Stufft <donald <at> stufft.io> writes:
>> So to be clear, this means it's
>> {
>>    "requires": [
>>        "foo",
>>        "bar"
>>    ]
>> }
>> ? 
>> And it means that having multiple combinations of the same
>> extra/envs is disallowed so I'm going to have to collapse everything
>> back down since it's not stored that way at all?
> I posted a working example [1] showing how there's no need to have the same
> structure at the RDBMS layer and the JSON layer. I asked for more
> information about modelling difficulties you said you had encountered, but
> didn't hear anything more about it. AFAICT the code you were talking about
> isn't public - at least, I couldn't see it in the branches on your GitHub repo.
> As my example shows, it's possible to have a sensible RDBMS structure which
> interoperates with multiple entries in "requires". If I've misunderstood
> something, please let me know what it is.
> Regards,
> Vinay Sajip
> [1] https://gist.github.com/vsajip/5929707

The dependency models are located at https://github.com/dstufft/warehouse/blob/f438bdcb17a5ee9de8e209d3eb6c93cc4aee9492/warehouse/packaging/models.py#L280-L380

It's completely possible and if I came across as saying it wasn't then I failed to clarify myself properly. My point was that it was simpler using a single list of dictionaries, not a list of dictionaries itself containing lists because there was less support code required to transform between them. Every additional piece of code comes with an overhead in the form of tests, mental overhead, potential bugs etc. I was trying to advocate for less required code because it makes things simpler :)

I was asking for clarification here because my original plan if things were required to be a list was to make single entry lists, again to limit the need to include additional support code. It appears that this plan isn't inline with the current iteration of the PEP but I was making sure :)

I have a preference for not introducing more nesting, and making things match the modeling better but I'll make it work either way. I hardly think PEP426 will fail if it's using deeper nesting even if I dislike it.

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/20130716/131b1340/attachment.pgp>

More information about the Distutils-SIG mailing list