On 7 July 2017 at 08:59, Thomas Kluyver <tho...@kluyver.me.uk> wrote: > On Thu, Jul 6, 2017, at 11:51 PM, Paul Moore wrote: >> On reflection, I'm less concerned about this than I was. If you wanted >> to propose a stripped down version of PEP 517 which assumed it was the >> backend's responsibility to ensure reproducible isolated builds, I'd >> be willing to listen. But the proposal would need to include some >> pretty strong requirements on precisely what we're asking of backends >> - if build isolation is pip's problem to solve, then I'm happy for us >> (the pip devs) to take that responsibility, and agree hooks that we >> need to do so, but if we're assuming backends handle it for us, I >> think we need to document clearly what we're assuming (because >> frankly, the pip devs are the ones with the experience of the >> potential issues). > > How does this sound to you: > > """ > If build_directory is not None, it is a unicode string containing the > path to a directory where intermediate build artifacts may be stored. > This may be empty, or it may contain artifacts from a previous build to > be used as a cache. The backend is responsible for determining whether > any cached artifacts are outdated. When a build_directory is provided, > the backend should not create or modify any files in the source > directory (the working directory where the hook is called). If the > backend cannot reliably avoid modifying the directory it builds from, it > should copy any files it needs to build_directory and perform the build > there. > > If build_directory is None, the backend may do an 'in place' build which > modifies the source directory. The semantics of this are not specified > here. > > In either case, the backend may also store intermediates in other cache > locations or temporary directories, which it is responsible for > managing. The presence or absence of any caches should not make a > material difference to the final result of the build. > """
That sounds pretty good. One reservation I have (I told you I was paranoid :-)) is that it's not *just* "If the backend cannot reliably avoid modifying the directory it builds from" that's the issue. There's also the possibility that the user may have some "junk" files in the build directory that affect the build, which shouldn't be there. An untested example, which is not at all likely in practice but illustrates my point, would be if a developer was testing their code and dumped a temporary zipfile.py in the project directory to see how the code handled corrupted/overridden stdlib modules. After finishing the test, they forget to clean up and then do "pip wheel .". With an in-place build, flit picks up the zipfile.py instead of the stdlib one, and fails with a potentially very confusing error message. As I say, that's a very contrived scenario, but it does illustrate how "unexpected junk in the source tree that wouldn't be there in the make sdist and unpack route" could affect build results. But apart from this very minor niggle, I like your wording. >> this is a case where flit is >> *not* a good example of a backend, as it avoids the nasty cases by >> design). > > Agreed. Enscons is a better example, though, and Daniel seems confident > that out-of-tree builds are feasible. Agreed. I don't really know anything about enscons, but I'm happy to accept Daniel's view. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
