[Distutils] Builders vs Installers

[Nick Coghlan]

On Tue, Mar 26, 2013 at 3:15 PM, PJ Eby <pje at 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.

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   |   ncoghlan at gmail.com   |   Brisbane, Australia