I’m confused. I don’t think I said that, but if I did, I’ll stick with “I’m confused”, because I guess I must be
From a front end point of view, I still think that pip should just be calling
build_wheel and getting a wheel back, and that’s it. Pip’s users have pointed out that we can’t just do that in the case of setuptools, and so we currently copy the build tree. We’d like to not do that (because copying the build tree triggers a whole load of other issues our users care about). But if setuptools doesn’t work in such a way that we can call
build_wheel multiple times on the source directory the user supplies, then so be it. PEP 517 isn’t explicit on the backend’s responsibilities so we have to live with that.
The current proposal may or may not be linked to that issue. It’s designed to help with incremental builds, at least for setuptools (I don’t know if any other backends would benefit). I’m fine with that. The proposal doesn’t say anything about how front ends would use the interface, so to that extent “what pip will do” is irrelevant here. It’s possible that pip will choose to use the interface in a way that doesn’t make incremental builds any easier with pip (maybe as a result of trying to use it as a workaround for the issue of copying the source tree). If that’s a problem, then the proposal needs to make more demands on how front ends use it. It’s the converse of the problem we have with
build_wheel not specifying enough restrictions on the back end, I guess. And I suspect we’ll hit the same problem, that we won’t be able to get consensus on over-constraining front ends.
I’m not sure this aspect of the discussion is particularly productive any more, though, so I suggest we let it drop.