2009/12/23 "Martin v. Löwis" <mar...@v.loewis.de>: >> 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
