On Thu, May 30, 2013 at 2:28 PM, holger krekel <hol...@merlinux.eu> wrote: > Hi Nick, > > I am actually missing a "goals" section in this PEP. Who can/should use > the PEP's new formats and definitions? Is it meant to fit well for > python2.6, PyPy, Jython, etc? Also, what the intention/roadmap for > adoption, how can existing and new tools deald with or distinguish > old-style and PEP426 packaging semantics? I think such "process" aspects > would provide very valuable context for the many players in the field. > > best, > > holger
I agree that this pep says a lot about how it's different than previous metadata but doesn't seem to have a clear single purpose. We hope to accomplish a lot of things, but this PEP is just concerned with defining an interchange format for the data we already have in [setuptools-based] setup.py, and some additional things we think we will need to get where we want to go. In particular this PEP does not say anything about entirely replacing setup.py.. What Metadata 2.0 does help to do is to represent a lot more of the information that's locked up in setup.py (or obfuscated by coming out different ways depending on the system) so that other tools can deal with it instead of necessarily having setup.py take charge of everything from development to installation. Along with wheel and the filesystem layout (.dist-info directories) we aim to have a clean, well documented, static interface between development/build and install, making it much easier to work on one half of the problem or the other. A future meta-build system will define an API or interface for the things that setup.py does. Existing setup.py scripts will be only the first available implementation. The format is designed to work with all current versions and implementations of Python. The end user shouldn't really notice anything different until some number of packages stop using setup.py. The key insight this time is that "setup.py install" is more harmful than other kinds of setup.py and is the first thing we should get rid of. No one actually parses PKG-INFO so I expect the Metadata 2.0 transition to be relatively painless. The semantics are intended to be as backwards compatible as possible. A future version of setuptools will be able to produce and consume the new and old formats, and distlib provides an alternate consumer. Daniel Holth _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
