<p dir="ltr"><br>
On 17 Jul 2013 05:34, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br>
><br>
><br>
> On Jul 16, 2013, at 1:54 PM, Vinay Sajip <<a href="mailto:vinay_sajip@yahoo.co.uk">vinay_sajip@yahoo.co.uk</a>> wrote:<br>
><br>
> > Donald Stufft <donald <at> <a href="http://stufft.io">stufft.io</a>> writes:<br>
> ><br>
> >> So to be clear, this means it's<br>
> >><br>
> >> {<br>
> >>    "requires": [<br>
> >>        "foo",<br>
> >>        "bar"<br>
> >>    ]<br>
> >> }<br>
> >><br>
> >> ?<br>
> >><br>
> >> And it means that having multiple combinations of the same<br>
> >> extra/envs is disallowed so I'm going to have to collapse everything<br>
> >> back down since it's not stored that way at all?<br>
> >><br>
> ><br>
> > I posted a working example [1] showing how there's no need to have the same<br>
> > structure at the RDBMS layer and the JSON layer. I asked for more<br>
> > information about modelling difficulties you said you had encountered, but<br>
> > didn't hear anything more about it. AFAICT the code you were talking about<br>
> > isn't public - at least, I couldn't see it in the branches on your GitHub repo.<br>
> ><br>
> > As my example shows, it's possible to have a sensible RDBMS structure which<br>
> > interoperates with multiple entries in "requires". If I've misunderstood<br>
> > something, please let me know what it is.<br>
> ><br>
> > Regards,<br>
> ><br>
> > Vinay Sajip<br>
> ><br>
> > [1] <a href="https://gist.github.com/vsajip/5929707">https://gist.github.com/vsajip/5929707</a><br>
><br>
> The dependency models are located at <a href="https://github.com/dstufft/warehouse/blob/f438bdcb17a5ee9de8e209d3eb6c93cc4aee9492/warehouse/packaging/models.py#L280-L380">https://github.com/dstufft/warehouse/blob/f438bdcb17a5ee9de8e209d3eb6c93cc4aee9492/warehouse/packaging/models.py#L280-L380</a><br>

><br>
> 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 :)<br>

><br>
> 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 :)<br>

><br>
> 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.</p>

<p dir="ltr">Yes, in this case I think improving the brevity of the serialisation format will be an aid to debuggability, even though the primary purpose of the format remains communicating between tools. </p>
<p dir="ltr">I should add a section discussing this decision in "Rejected Design Ideas", though.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
><br>
> -----------------<br>
> Donald Stufft<br>
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
><br>
><br>
> _______________________________________________<br>
> Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/distutils-sig">http://mail.python.org/mailman/listinfo/distutils-sig</a><br>
><br>
</p>