Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> As an application developer, I really stand with Tarek here. Not sure what specific point of Tarek you are supporting, though. I think we want something stronger than that since they were not really used by the community and removed and replaced by something better. Using them should raise a warning so developers abandon them, so it would be "don't use 1.1 anymore" > > Yes. But that is a software warning message to be implemented within > the installation software. The important thing is what is in the > metadata. That's my point, not Tarek's, though (the text you quote and that you seem to object to is from Tarek). >> I am just describing the needs and the end user PoV with the reference >> implementation that happens to be used by *all* tools out there. > > That's good. That's what we need right now. Why then bother with describing the data format, when you *really* want people to use the API? Shouldn't you then define the API instead, and leave the format as an implementation detail? I'm fine with having a sample implementation that tools *may* use, but it should be possible to implement the PEP without the sample implementation (and indeed, PyPI may not use that sample implementation, as it has already implemented most of the PEP, to support earlier versions). >> So that will happen in the code of course, but we need the PEP to state >> clearly >> wether metadata 1.0 and 1.1 should be dropped by implementations or not. > > +1 > >>> It would be also incompatible with existing consumers that expect >>> a Python package to have an earlier version of the metadata. >>> Dropping 1.0 may be fine though - but again, this is out of scope >>> here. > > That's a software implementation issue. Not a metadata issue. Above you say that the PEP should specify whether to keep or drop 1.0 and 1.1, and now you say that whether dropping 1.0 is not a metadata issue (and, presumably, out of scope of the PEP)??? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
David Lyon wrote: > On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" > wrote: > >> Martin's point is that the PEP process doesn't *have* "reference" >> implementations. It has *sample* implementations. It may be useful >> to refer to a sample implementation as an example.. > > Fair enough. But otoh, asking for sample implementations on this > type of project can skew the PEP towards a particular implementation > or product. Nobody is "asking" for sample implementations. Instead, I'm asking that what Tarek calls a "reference implementation" should be called a "sample implementation" instead. I'm asking for that precisely to avoid a skew towards a particular implementation. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
2009/12/23 "Martin v. Löwis" : >> So that will happen in the code of course, but we need the PEP to state >> clearly >> wether metadata 1.0 and 1.1 should be dropped by implementations or not. > > Ok. We should recommend that implementations support these versions > indefinitely. I see no point in dropping them. > > But then, this is really up to the implementations. OK, that's fine with me. So I'll remove references to deprecated fields in PEP 345, which will just describes 1.2, and I will also remove the fact that it was marked as the replacer of PEP 314 in the header. [..] >> PyPI doesn't produce PKG-INFO files AFAIK, it just consumes them, no ? > > Correct - but that's also an implementation of the PEP. > >> I am referring to the implementation in Distutils that produces 1.0 >> *or* 1.1 PKG-INFO files. > > But it works both ways. Applications that consume then need to decide > what versions they want to consume. They know it because it is marked in the file in the first line. e.g. a reader has to be able to read all versions. IOW they are not the ones that decide what metadata version a distribution contains. >>> Please do keep distutils out of PEP 345. The remaining occurrences >>> (such as what the "interpret_marker" function does) should be removed. >> >> That's the reference implementation of a PEP 345 reader/writer that >> happens to be in the stdlin. For what reason should we remove it from >> the PEP ? > > Because there shouldn't be a reference implementation. If we have > both a spec and an a reference implementation, then we need to define > what happens in case they conflict. If the reference implementation > is right, implementers of the PEP would *also* need to study the > reference implementation to find out what conforming behaviour is. > > This is bad; the PEP should be the only definition of the metadata > format. Ok, I'll remove that part. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
On Thu, Dec 24, 2009 at 10:26 AM, "Martin v. Löwis" wrote: > David Lyon wrote: >> On Thu, 24 Dec 2009 10:31:09 +0900, "Stephen J. Turnbull" >> wrote: >> >>> Martin's point is that the PEP process doesn't *have* "reference" >>> implementations. It has *sample* implementations. It may be useful >>> to refer to a sample implementation as an example.. >> >> Fair enough. But otoh, asking for sample implementations on this >> type of project can skew the PEP towards a particular implementation >> or product. > > Nobody is "asking" for sample implementations. Instead, I'm asking that > what Tarek calls a "reference implementation" should be called a > "sample implementation" instead. I'm asking for that precisely to avoid > a skew towards a particular implementation. I'll remove it and push it in Distutils documentation, then might just provide a link in the PEP References. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
> I'll remove it and push it in Distutils documentation, then might just > provide a link in the PEP References. That sounds fine to me. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2
Martin v. Löwis wrote: >> I'll remove it and push it in Distutils documentation, then might just >> provide a link in the PEP References. > > That sounds fine to me. That would address my questions as well - someone looking for a guide on how they should deal with different versions of the metadata on the production and consumption side can look at how distutils deals with it, leaving the PEP as a pure spec for the metadata format without distutils API details mixed in. (where it makes sense in explaining the use cases for the different fields, I'm fine with referencing distutils API details though) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
