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

I don't get why people expect no breaking changes

Posted May 21, 2025 18:30 UTC (Wed) by vmpn (subscriber, #55435)
Parent article: Recent disruptive changes from Setuptools

If you want software to be maintainable long term, you have to have ability to make backwards incompatible releases to clean up technical debt.

While breaking consumers of the app is not great they have to bare some responsibility for consumption of new major version that documents the incompatibly.

to post comments

I don't get why people expect no breaking changes

Posted May 21, 2025 18:58 UTC (Wed) by mb (subscriber, #50428) [Link] (7 responses)

>some responsibility for consumption of new major version

Well, have you read the article section "Reporting and updating"?

>If you want software to be maintainable long term,
>you have to have ability to make backwards incompatible releases to clean up technical debt.

That depends on what the technical debt is, what the advantage of removing it is and how many downstream users are affected.
This ratio doesn't look too good for a hyphen removal that breaks 12000 packages.

I don't get why people expect no breaking changes

Posted May 21, 2025 19:16 UTC (Wed) by vmpn (subscriber, #55435) [Link] (6 responses)

> Well, have you read the article section "Reporting and updating"?
I did and I find the response stating you been warned for 3+ years and took no action to remediate, so please don't be surprised your workflow broke right on the money.

I don't get why people expect no breaking changes

Posted May 21, 2025 19:51 UTC (Wed) by mb (subscriber, #50428) [Link] (5 responses)

It takes one package in the dependency chain that I don't have control over to break the build.

Please always keep in mind the benefit and the costs of breaking changes as a trade off.
A simple breakage that breaks 12k packages easily wastes several years of net human worktime. So is it worth it to save you 5 hours of maintenance cost during the next 5 years?

It's always easy to expect everybody to update and do the work, if you don't have to actually spend/pay the work.

I don't get why people expect no breaking changes

Posted May 22, 2025 0:40 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (4 responses)

> It's always easy to expect everybody to update and do the work, if you don't have to actually spend/pay the work.

We can turn that around very easily. The Setuptools developers were, technically, under no obligation to revert the change at all. They could just as easily have said "What part of 'NO WARRANTY' and 'major version bump' did you not understand?" and WONTFIXed all the bug reports. That they were generous enough to revert their change should be taken with gratitude, not contempt for the change having been made in the first place.

I don't get why people expect no breaking changes

Posted May 22, 2025 5:51 UTC (Thu) by mb (subscriber, #50428) [Link]

I was not talking about whether to revert or not, but whether to deprecate or not.

I don't get why people expect no breaking changes

Posted May 22, 2025 10:00 UTC (Thu) by tux3 (subscriber, #101245) [Link] (2 responses)

If we take the view that the setuptools developers are under no obligation to play nice and be considerate, then it stands that their users are under to obligation to respond with gratitude. You're perfectly allowed to do that, but it always cuts both ways.

You can take a "let others deal with it" attitude, but you can't force users to like it. Doing unpopular things is a reliable way to become unpopular.

I don't get why people expect no breaking changes

Posted May 29, 2025 5:05 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (1 responses)

FOSS is a gift. Gratitude is the normal social response to gifts. Nobody was forced to use Setuptools. Or at least, the Setuptools developers themselves did not force anyone to use Setuptools.

I don't get why people expect no breaking changes

Posted May 29, 2025 6:41 UTC (Thu) by Wol (subscriber, #4433) [Link]

> FOSS is a gift. Gratitude is the normal social response to gifts.

??? Depends on the giver.

Don't remember the story (I don't like Dickens), but he wrote a wonderful short about about a Christmas meal thrown for "the deserving" (or maybe undeserving).

Oh - and as far as development "aid" is concerned, most gift horses most definitely SHOULD be looked in the mouth.

Cheers,
Wol

I don't get why people expect no breaking changes

Posted May 22, 2025 17:08 UTC (Thu) by dbnichol (subscriber, #39622) [Link] (2 responses)

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 27, 2025 10:25 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

Python dumped distutils in favour of setuptools. Because being too static and unmoving is not a good characteristic in python.

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`).