@steve.dower I think this largely misses the point I outlined, which is in the ecosystem backend requires are special, and they are not controllable like install requirements, so breaking changes do have a bigger impact.
If a user has an install time transitive dependency on foo>=1 and in the future foo v3 is released that breaks their application they can add the constraint foo<3 and move on with their day.
However for build backends users may not have some luxury, given the example:
- bar requires on build backend
foo>=1 foo v10breaksbarbuild process- baz requires build backend
foo>=10
The user tries to pip install build bar and baz together:
- pip downloads bar
- pip downloads build backend foo v10 which breaks bar and the install fails
So the user follows the guidances and uses a pip’s constraints file:
- User puts
foo<10in pip constraints file - pip downloads bar
- pip downloads build backend foo v9 which succeeds in building bar
- pip downloads foo
- pip tried to resolve build backend requirement
foo>=10with constraintfoo<10, resolution fails, and install fails
There is currently no single install command available to build these two packages together.
The user could build bar and baz manually themselves, put the wheels in a directory, point pip to that directory, and try the install again, but this assumes the user knows exactly which version of bar and baz they want, they might not, these might be transitive dependencies in a complicated requirement list that requires significant backtracking.
But even if the user does know which versions they want, we’re now asking users to manually build individual packages themselves with per package build constraint files. Which is generally not asked of at all from users for install requirements.