I’m thinking in terms of failure modes, which is why I think we should go via sdist – failing always is better than failing sometimes – for a faulty backend, for example, an install could work when done with
pip install . but not
pip install name which get the sdist built from that directory on PyPI.
This kind of failure can become tricky/frustrating for the user to debug and I strongly prefer to not have that happen.
I guess it comes down to should pip trust backends to do the right thing always, I’m not too comfortable with that given that it’s not guaranteed by PEP 517 and it’s super easy to mess up anyway. PEP 517 also says:
To ensure that wheels from different sources are built the same way, frontends may call build_sdist first, and then call build_wheel in the unpacked sdist.
So, yea, I don’t think I’d trust all backends would implement this in the manner we’d need, to be willing trade off users being exposed to the (IMO) confusing failure modes, especially since the benefit is a single reduced subprocess call for installations from directories/VCS.
Anyway, going via sdist would be an improvement over status quo so I don’t think this concern is a blocker.
If someone really wants pip to skip that extra subprocess call, I’m open to being convinced otherwise after we’ve rolled this out into the wild, treating this as an optimization.