Issue #2259: Updates Policy exception for black (python-black) - fesco

fesco

#2259 Updates Policy exception for black (python-black)

Closed: Accepted 4 years ago by jforbes. Opened 4 years ago by churchyard.

A new version of black was released, 19.10b0. We are at 19.3b0 in Fedora 31. I'd like to update it, but it subtly breaks backwards compatibility.

Black is a code formatter with very strict rules. One of the benefit of using black is the determinism of its output. By running black on code twice, it is guaranteed (well, claimed) to produce no changes. When updating it however, new changes might appear on a codebase that was previously considered "OK".

According to the project creator, there is "a bunch of fairly minimal changes to formatting".

https://twitter.com/llanga/status/1187675966694449152

However, nothing specific is mentioned in the chnagelog:

https://black.readthedocs.io/en/stable/change_log.html

I expect our users to prefer the latest version of black over total stability of its output.

Things that would make it more likely to grant a request:

✘ The package is a "leaf" node. Nothing depends on it or requires it.
- cranc, python-elpy, python-slackclient BuildRequire black
- emacs-blacken requires black on runtime, possibly to allow users to run it
- cc @lenkaseg @lbazan @limb @melmorabity
- python-slackclient builds on rawhide with new black
- cranc was not tracked by koschei
- python-elpy was not tracked by koschei

✘ The update fixes a security issue that would affect a large number of users.
✔️ The update doesn't change ABI/API and nothing needs to be rebuilt against the new version.
✔️ The update fixes serious bugs that many fedora users are encountering.
- mostly compatibility with new features that our users might start using with Python 3.8.

Things that would make it less likely to grant a request:

✘ The update converts databases or resources one way to a new format.
✘ The update requires admin intervention for the service to keep working (config file format changes, etc)
✔️The update causes behavior changes (something that was denied is allowed, etc)
✘ The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)
✘ [as in "not only"] The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations).

churchyard commented 4 years ago

One thing to also consider: Both versions are marketed as betas. Hence the stability might not be considered crucial by users.

churchyard commented 4 years ago

Here's a Fedora 31 PR with a scratchbuild: https://src.fedoraproject.org/rpms/python-black/pull-request/4

sgallagh commented 4 years ago

I've tried out the scratch-build from https://pagure.io/fesco/issue/2259#comment-607778

It seems to work fine and for the set of my packages I tested it on, I didn't actually encounter any new formatting adjustments.

Given that this is a formatting tool and all changes will affect how it formats the output, I think it's reasonable to consider the Stable Updates Policy to apply primarily to the CLI options (we don't want to break scripts that are using it).

As far as its claims of idempotence, I'd say that's largely irrelevant, but if we wanted to treat that as "API", then we should only require that two runs of the same version against a file produce the same output.

tl;dr: +1 from me