On Tue, Mar 26, 2013 at 3:15 PM, PJ Eby <[email protected]> wrote: > More specifically, I was hoping to move the discussion forward on > nailing down some of the details that still need specifying in a PEP > somewhere, to finish out what the "new world" of packaging will look > like.
I'm deliberately trying to postpone some of those decisions - one of the reasons distutils2 foundered is because it tried to solve everything at once, and that's just too big a topic. So, *right now*, my focus is on making it possible to systematically decouple building from installing, so that running "setup.py install" on a production system becomes as bizarre an idea as running "make install". As we move further back in the tool chain, I want to follow the lead of the most widely deployed package management systems (i.e. Debian control files and RPM SPEC files) and provide appropriate configurable hooks for *invoking* archivers and builders, allowing developers to choose their own tools, so long as those tools correctly emit standardised formats understood by the rest of the Python packaging ecosystem. In the near term, however, these hooks will still be based on setup.py (specifically setuptools rather than raw distutils, so we can update older versions of Python). > OTOH, I suppose a case could be made for checking PKG-INFO into source > control along with the rest of your code, in which case the problem > disappears entirely: there'd be no such thing as a "raw" source in > that case. > > The downside, though, is that there's a small but vocal contingent > that believes checking generated files into source control is a sign > of ultimate evil, so it probably won't be a *popular* choice. > > But, if we support "either you have a setup.cfg specifying your > archiver, or a PKG-INFO so an archiver isn't needed", then that would > probably cover all the bases, actually. Yeah, you're probably right that we will need to support something else in addition to the PKG-INFO file. A PKG-INFO.in could work, though, rather than a completely independent format like setup.cfg. That way we could easily separate a source checkout/tarball (with PKG-INFO.in) from an sdist (with PKG-INFO) from a wheel (with a named .dist-info directory). (For consistency, we may want to rename PKG-INFO to DIST-INFO in sdist 2.0, though) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
