On 3 June 2017 at 13:38, Donald Stufft <don...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
