On Jul 16, 2013, at 1:54 PM, Vinay Sajip <vinay_sa...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
