[Distutils] Builders vs Installers

Nick Coghlan ncoghlan at gmail.com
Tue Mar 26 19:25:48 CET 2013

On Tue, Mar 26, 2013 at 9:15 AM, PJ Eby <pje at telecommunity.com> wrote:
> On balance, I think I lean towards just having a simple way to specify
> your chosen archiver, so that installing from source checkouts and
> dumps is possible.  I just find it annoying that you have to have
> *two* files in your checkout, one to say what tool you're using, and
> another one to configure it.

Ah, you have uncovered part of the cunning plan behind
Setup-Requires-Dist and the metadata extension system in 2.0+: once we
have the basic hooks in place, then we should be able to embed the
config settings for the archivers and builders in the main metadata,
without the installer needing to understand the details. Allowing
embedded json also supports almost arbitrarily complex config options.

For metadata 2.0, however, I'm thinking we should retain the
distutils-based status quo for the archive hook and the build hook:

Archive hook: python setup.py sdist
Environment: current working directory = root dir of source
checkout/unpacked tarball

Build hook: python setup.py bdist_wheel
Environment: current working directory = root dir of unpacked sdist

The install tool would then pick up the files from their default
output locations.

Installing from a checkout/tarball would go through the full daisy
chain (make sdist, make wheel from sdist, install the wheel), and
installing from sdist would also build the intermediate wheel file.

The only entry points inspired hook in 2.0 would be the post-install
hook I have discussed previously (and will write up properly in PEP
426 later this week).

In theory, we could have separate dependencies for the "make sdist"
and "make wheel" parts of the chain, but that seems to add complexity
without adequate justification to me. The runtime vs setup split is
necessary so that you don't need a build chain on your deployment
targets, but it seems comparatively harmless to install the archiver
onto a dedicated build system even if you're only building from sdists
(particularly when I expect most Python-specific tools to continue to
follow the model of handling both archiving and building, rather than
having completely separate tools for the two steps).

> (What'd be nice is if you could just somehow detect files like
> bento.info and setup.cfg and thereby detect what archiver to use.  But
> that would have limited extensibility unless there was a standard
> naming convention for the files, or a standardized format for at least
> the first line in the file or something like that, so you could
> identify the needed tool.)

Yeah, I plan to use future releases of the 2.x metadata to define
hooks for this. We can also start experimenting in 2.0 through entry
points and the structured metadata format I will be defining for the
post install hook. (Daniel has an entry points extension PEP mostly
written, we just haven't got around to publishing it yet...)

In the meantime, formalising the "setup.py sdist" and "setup.py
bdist_wheel" invocations should provide a useful stepping stone to a
setup.py-is-optional future.


> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list