How can build backends avoid breaking users when they make backwards incompatible changes?

Packaging
28

I’m not at all comfortable with the idea of framing this in terms of expectations on build backends, or what frontends can do to help “fix” problems caused by build backends making incompatible changes. The setuptools issue that triggered this discussion is very polarised, with people looking to assign blame (or at the very least, “responsibility”) and I don’t want to be part of that.

Where I think build frontends fit in, is that they are intermediaries, enabling one set of users (developers) to interact with another (build backends). In that context, setuptools is just as much a user of pip as the developer, and we should be looking at how pip can help setuptools manage their deprecation process better[1].

So why don’t we ask the setuptools maintainers what they would like from build frontends? Not right now - emotions are too high at the moment - but once things have cooled down, we should work with setuptools to understand how we can help things go more smoothly in future.

  • There was no way for setuptools to get the deprecation warning in front of their users? Then frontends could add a way for backends to issue “priority warnings”, which will be displayed even when normal output is suppressed.
  • The advice setuptools gave their users to use PIP_CONSTRAINT didn’t work? Find out why, fix any bugs, and add functionality if needed.
  • Legacy projects without a pyproject.toml were the issue? Maybe frontends should default to a specific version of setuptools, rather than just assuming the latest is still compatible with legacy projects?
  • Projects can’t easily manage a staged rollout of new build backends? Maybe we need a --build-constraint mechanism that can be used to put an upper limit on backend versions.

The point is, let’s not try to solve “the problem” in the abstract. Let’s treat it like we would any other case where one of our users (in this case setuptools) hits an issue - understand the problem and work on a solution with the user.

  1. As an aside, I’ll say that while I may not agree with the way setuptools managed the recent deprecation, I will defend their right to do what they feel is in the best interests of their project and their users ↩︎

13 Likes