Deciding on a black version

[xhluca]

This repo's black version is currently locked to 19, so using the latest version might break the CircleCI black tests. Should we upgrade it to 20.8 and black all of the existing apps? This will likely trigger a re-deploy of all apps so might take a few hours, and might break some app.

[emmanuelle]

Don't get me started on black... This kind of problem is the reason why I think black has more cons than pros. Maybe someone should write a tool which would check whether a code is consistent with some version of black, which is usually just what people are interested in (call it grey maybe?). OK, this ranting does not help, I know :-).

I think that once you've chosen to use black, if you're collaborating with various people the only way to go is to use the latest version of black, otherwise people will use different contradicting versions. I had the problem recently since with plotly.py we pinned the version of black, but this means I can't work with other people who have more recent versions (I can of course in a venv but you don't want to add black to all your requirements).

[alexcjohnson]

Hmm having multiple versions of black kind of defeats their own raison d'être. "Any color you like" indeed... I suppose this is why they're still tagging their releases as beta but that's a bit of a cop-out.

That said I do like having it - I think between Black and Prettier our code reviews have become noticeably less noisy. And it doesn't seem to me as though there's a whole lot changing from version to version. I just did a trial run updating dash from 19.10b0 to 20.8b1 and only 7 of 90 files had any changes, most just one line. So it feels like the cost of taking @emmanuelle 's suggestion (including the likelihood of breaking an app) is fairly low, mostly it's just a matter of organizing our upgrades across Plotly repos that share developers.

I've been thinking about dependency management more generally across the Dash ecosystem (cc @Marc-Andre-Rivet) - there are a few things we want to loosen (plotly/dash#1466, plotly/dash#1457) but a lot of other places we've let our deps stagnate, and I'd like to propose we follow a pattern used by the DE platform team and do an upgrade sweep early in the cycle of each enterprise release. Not that there's anything necessarily tying our open-source work to the enterprise release cycle, it just seems like about the right cadence for this, and if we do it as a coordinated sweep across all our repos no one will be caught in cross-repo conflicts.

[thclark]

I'd suggest using pre-commit to apply black, and/or do it in a github action to apply it on push. That way you can specify the absolute same version that everybody uses. Here's an example where we implemented that in pre-commit at octue

BTW You'll want to use black >=22 because at some point there was an accidental breaking change that cause it to be incompatible with some versions of click. The black team solved it now though; just don't pin to an older version.