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

[Nick Coghlan]

On 17 Jul 2013 05:34, "Donald Stufft" <donald at stufft.io> wrote:
>
>
> 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.

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.

I should add a section discussing this decision in "Rejected Design Ideas",
though.

Cheers,
Nick.

>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130717/4cbd0736/attachment.html>