[Distutils] Upcoming changes to PEP 426/440

[Nick Coghlan]

On 4 Jul 2013 21:35, "Donald Stufft" <donald at stufft.io> wrote:
>
>
> On Jul 4, 2013, at 7:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>>
>> On 4 Jul 2013 18:52, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>> >
>> > Nick Coghlan <ncoghlan <at> gmail.com> writes:
>> >
>> > > * "install": the installation specifier for the dependency
>> > > * "extra": as per the current PEP (for conditional dependencies)
>> > > * "environment": as per the current PEP (for conditional
dependencies)
>> > >
>> > > 4. The "install" subfield is compulsory, the other two are optional
>> > > (as now, using either of the latter creates a "conditional
>> > > dependency", while dependency declarations with only the "install"
>> > > subfield are unconditional)
>> > >
>> > > 5. An installation specifier is what PEP 426 currently calls a
>> > > dependency specifier: the "name [extras] (constraints)" format. They
>> > > will get their own top level section (similar to the existing Extras
>> > > and Environment markers sections)
>> >
>> > Is there a particular benefit of the install subfield being a single
>> > installation specifier, as opposed to a list of such specifiers? It's
>> > perhaps neither here nor there for machine-processed metadata, but I
expect
>> > this metadata would have human readers too. Not using a list would
lead to
>> > more verbose metadata.
>>
>> Hmm, I guess as long as it's consistent, the only difference when
processing is list.append vs list.extend.
>>
>> There's a little extra work when serialising to group like entries
together, but I'm OK with that (and that would be a SHOULD rather than a
MUST anyway).
>>
>> If I don't hear a good argument against it, I'll make that field a list.
>>
>> >
>> > 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
>
>
> 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.

The main benefit is that all the dependencies for an extra will typically
be in one place.

However, I briefly forgot the "machine readable" part again, and for that
TOOWTDI is to have one entry per dependency. Merging common criteria would
then be a UI thing with multiple ways to do it (e.g. whether to group by
extra or environment first for conditional dependencies).

If you allow a list instead, then you have the problem of offering two ways
to say the same thing (all in one entry or split across multiple entries).

So the install subfield will remain a single string in the data interchange
format, even if tools choose to structure it differently in their UI.

Note repeating the key names as well some subfield values doesn't bother me
- that's what streaming compression is for.

This is what happens when I don't write my rationale down, though - I
forget why I did things a certain way :)

Cheers,
Nick.
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130704/07394dbc/attachment-0001.html>