[Distutils] Upcoming changes to PEP 426/440

[Daniel Holth]

I don't think you can get around the complexity. Consider:

{extra:'foo', condition:'platform == win32', install=[]}
{extra:'foo', condition:'platform == linux', install=[]}

They have to be flattened into a single list of all the 'foo' extras
that are installable in the current environment anyway. It's exactly
the same work you might try to avoid by worrying about whether install
is a list.

On Thu, Jul 4, 2013 at 9:45 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> On 4 Jul 2013 22:32, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>>
>> Donald Stufft <donald <at> stufft.io> writes:
>>
>> > I would prefer a single entry. It makes the serialization format map to
>> > the
>> > modeling simpler, and I think it's simpler for humans too. I don't see
>> > much
>> > benefit to making it a list except arbitrarily adding another level of
>> > nesting.
>>
>> It's a question of
>>
>> {
>>   "install": ["a", "b", "c"]
>> }
>>
>> versus
>>
>> {
>>   "install": "a"
>> },
>> {
>>   "install": "b"
>> },
>> {
>>   "install": "c"
>> }
>>
>> and I can't see why you think the latter is in any way better.
>
> The basic problem with the list form is that allowing two representations
> for the same metadata makes for extra complexity we don't really want. It
> means we have to decide if the decomposed version (3 separate entries with
> one item in each install list) is still legal.
>
> What I will do is draft PEP text for the list version that explicitly
> declares the decomposed form non-compliant with the spec. If I think the
> extra complexity looks tolerable, I'll switch it over.
>
> Cheers,
> Nick.
>
>>IMO
>> implementation details (such as "it's easier for the Django ORM to map
>> it")
>> should not take precedence over other considerations of
>> readability/simplicity. In any case, I can't see why there would be any
>> particular modelling problem with the scheme I've suggested.
>>
>> Is the modelling work you're doing public? I had a quick look at your
>> warehouse repo (github.com/dstufft/warehouse) and I don't see any models
>> beyond User and Email. Is that the correct location? I'd be happy to take
>> a
>> closer look to get a better understanding of what modelling problem you're
>> seeing/foreseeing.
>>
>> FYI the metadata that I'm maintaining on red-dove.com is stored in a SQL
>> database. While my SQL schema is not yet fully aligned with the PEP (as
>> it's
>> WIP), I don't see any modelling problem between an RDBMS backend and any
>> of
>> the JSON formats which have been published in the various revisions of the
>> PEP. Some more detail would help :-)
>>
>> Regards,
>>
>> Vinay Sajip
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
>