Changes in Black internals may break Darker

[akaihola]

We're using Black's Python API directly. Black doesn't yet define a public API (see psf/black#779), so changes in Black may break Darker. This has in fact already happened at least twice.

To get an early warning about such changes, we could add a GitHub Action workflow for testing against Black main instead of its latest release.

[akaihola]

@flying-sheep, you may be interested in this – we just fixed one incompatibility in #189.

[akaihola]

Changes in Black internals just broke Darker, see #270 (and earlier contributed patches in #267, #268 and #269; thanks @jabesq, @yoursvivek and @Mystic-Mirage).

Some post-mortem brainstorming might help with coming up with ideas to protect against this.

[yoursvivek]

I would say, there was a gap in version check with-in this project itself. Black upgraded a major version bump ("black==22.0") and are allowed to do breaking change as per any versioning guidelines.

Darker should limit black to minor version compatibility check. Moving forward using black~=22.0. I do acknowledge that darker would need more releases to bump black version but better than broken package.

[akaihola]

Hi @yoursvivek, thanks for pointing this out!

But isn't 22.1 the first non-beta-numbered release from Black? As long as the version number looked similar to 21.1b1 I always assumed no compatibility guarantees from Black anyway.

Also, Black's version numbers look like year/month based and not SemVer, so are you sure they would now delay any non-breaking changes until 23.1?

I've also learned that Black doesn't actually commit to any kind of a public Python API. So we're using Black internals anyway. See psf/black#779 for more information.

Of all the options I can think of, I like most the idea to add one more automated test environment which installs master / main checkouts of dependencies (esp. Black) instead of latest releases. This way we'd get an early warning of new incompatibilities and could make a compatibility release even before the dependency publishes the compatibility breaking release.

[yoursvivek]

so are you sure they would now delay any non-breaking changes until 23.1?

Well, I'm not. Just believed so in good faith.

Of all the options I can think of, I like most the idea to add one more automated test environment which installs master / main checkouts of dependencies (esp. Black) instead of latest releases. This way we'd get an early warning of new incompatibilities and could make a compatibility release even before the dependency publishes the compatibility breaking release.

This sounds more resilient plan.