I don't get why people expect no breaking changes [LWN.net]

I don't get why people expect no breaking changes

Posted May 22, 2025 17:08 UTC (Thu) by dbnichol (subscriber, #39622)
In reply to: I don't get why people expect no breaking changes by vmpn
Parent article: Recent disruptive changes from Setuptools

There are 2 difference here from a regular library API break:

1. This is a build tool. The expected input to it is released software that, by definition, can't be changed to adjust to the API changes. Imagine if GNU Make decided to stop supporting some old Makefile features that have long been considered undesirable. That might be just fine for your project that builds with make, but you could hardly expect this new version of GNU Make to be adopted since it would break builds of released software. In other words, breaking the API of a build tool has a big impact since the typical API consumer is frozen.

2. Unfortunately for setuptools, the latest version is used implicitly for all Python old source releases. That puts it in a situation where API breaks are especially damaging since there's no opt-in. With hindsight, it probably would have been better to take distutils from Python 2.7 or something like that and brand that as the implicit default build tool.

I don't get why people expect no breaking changes

Posted May 29, 2025 22:00 UTC (Thu) by zahlman (guest, #175387) [Link]

> With hindsight, it probably would have been better to take distutils from Python 2.7 or something like that and brand that as the implicit default build tool.

distutils specifically would just not have cut it. By the time it was removed from the standard library it was considered an unmaintainable mess that nobody really knew what to do with.

It would have been nice for Setuptools to be able to extract a "core" build system that is restricted to the part that actually implements PEP 517 (discussed in other comment threads), which could then be used separately from the part that enables workflows on the developer's machine. Flit and Hatch work this way (using flit-core and Hatchling respectively). However, a "Setuptools-core" would have to have been restricted to only handling projects that can configure everything in `setup.cfg` (and `pyproject.toml`) since `setup.py` is the same file used for implementing, for example, arbitrary new sub-commands for command-line developer use, or for setting up tests in arbitrary Python code (subsequently run with `setup.py test`).