On Tue, Mar 26, 2013 at 2:48 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On Tue, Mar 26, 2013 at 3:15 PM, PJ Eby <p...@telecommunity.com> 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.
Right--what we really need here is something akin to the debian/rules file, only not a shell script :) I like the hook idea. It's the "so long as those tools correctly emit standardised formats" that's the problem. > 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). That pretty much eases the concerns I brought up in the "backwards compat" thread. >> 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). I'm partly in favor of just saying, "there should be a PKG-INFO in your version control to be considered a valid python distribution". Intermediate formats like a setup.cfg or Nick's JSON format seem kind of unnecessary to me--why have two different formats to describe the same thing? In cases where the metadata needs to be mutated somehow--such as attaching revision numbers to the version--some sort of PKG-INFO.in like you suggest would be great. But I don't see why it should have a different format from PKG-INFO itself. I'd think it would just be a superset of the metadata format but with support for hooks. Basically akin to what d2to1 does with setup.cfg, but without the unnecessarily different-looking intermediate format (I do agree that a JSON format would allow a much greater degree of expression and flexibility, but I'm not entirely sure how I feel about having one file format that generates an entirely different file format). > (For consistency, we may want to rename PKG-INFO to DIST-INFO in sdist > 2.0, though) +1 Thanks, Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
