On 4 Jul 2013 21:35, "Donald Stufft" <don...@stufft.io> wrote: > > > On Jul 4, 2013, at 7:00 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> >> On 4 Jul 2013 18:52, "Vinay Sajip" <vinay_sa...@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@python.org >> > http://mail.python.org/mailman/listinfo/distutils-sig >> >> _______________________________________________ >> Distutils-SIG maillist - Distutils-SIG@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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
