[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Nick Coghlan]

On 3 June 2017 at 13:38, Donald Stufft <donald at stufft.io> wrote:
> However, what I was able to find was what appears to be the original reason
> pip started copying the directory to begin with,
> https://github.com/pypa/pip/issues/178 which was caused by the build system
> reusing the build directory between two different virtual environments and
> causing an invalid installation to happen. The ticket is old enough that I
> can get at specifics it because it was migrated over from bitbucket. However
> the fact that we *used* to do exactly what you want and it caused exactly
> one of problem I was worried about seems to suggest to me that pip is
> absolutely correct in keeping this behavior.

FWIW, I'll also note that in-place builds play merry hell with
containerised build tools, volume mounts, and SELinux filesystem
labels.

In-place builds *can* be made to work, and when you invest the time to
make them work, they give you all sorts of useful benefits
(incremental builds, etc), but out-of-tree builds inherently avoid a
lot of potential problems (especially in a world where virtual
environments are a thing).

As far as "out-of-tree caching" is concerned, all the build systems
I'm personally familiar with *except* the C/C++ ones use some form of
out of band caching location, even if that's dependency caching rather
than build artifact caching.

As an example of the utility of that approach, Atlassian recently
updated the Alpha version of their Pipelines feature to automatically
manage cache directories and allow them to be shared between otherwise
independent builds:
https://confluence.atlassian.com/bitbucket/caching-dependencies-895552876.html

Cheers,
Nick.

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