Contributors mailing list archives

Browse archives


Re: black version upgrade for v14 ?

ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 04/10/2020 14:46:41
I vote for #3


No dia 04/10/2020, às 13:42, Frederik Kramer <> escreveu:

Hi Stephané,

i'd go for updating black to the new version, if we can somehow
run an trial on v13 how much manual corrections would be necessary on
already green PRs (i.e. option 2). If the number is high (say > 100)
i'd go for option 1 (i.e. stayin on the old version of black and wait
for more stability). It the number < 100 id update for v13 AND v14
(with a nice message for developers what changes for them and of course
an apologies to those who have to rework PRs already green).
Option 3 only adds complexity through case difference so i tend to rule
that option out.

Best Frederik

Am Sonntag, den 04.10.2020, 12:22 +0000 schrieb Stéphane Bidoul:

> Hi contributors,


> I have a question for you, before creating the 14.0 branches. (I hope

> it will not degenerate into a religious war, but I want to ask

> nevertheless :)


> The black code formatter we use has a new version that, among other

> fixes and improvements, resolves the infamous trailing comma issue

> [1]. It also does some reformatting in the docstrings. When we use

> it,

> it therefore applies some different code reformatting here and there.


> In the long run, using it is definitely a good thing. In the short

> term I'm not so sure, hence this message.


> So I see 3 possibilities:


> 1. keep black to the same version in 13 and 14 and wait until black

> hits 1.0 to upgrade


> This is the less disruptive approach right now but we need to

> continue

> coping with the trailing comma "bug". This postpones the moment when

> we will need to decide between options 2 and 3 below (possibly

> involving more branches).


> 2. upgrade black now in 13 and 14


> We can automate that but it will have the drawback of making some

> existing 13.0 green PRs unmergeable, requiring manual intervention on

> them before merging.


> 3. upgrade black in 14 and keep 13 as is, let PSC upgrade manually in

> 13 if they want to.


> With this approach there will be some code formatting differences

> between branches 13 and 14 which may make code migration slightly

> more

> difficult, and may create some cherry-pick conflicts in forward- and

> backports.


> What are your thoughts / vote? In doubt, update

> .pre-commit-config.yaml in your favorite repo to replace 19.10b0 with

> 20.8b1 and run "pre-commit run -a" to see what it does exactly.


> [Note A similar reasoning exists for prettier but it mostly impacts

> javascript-heavy repos only. So there I believe it's ok to upgrade

> prettier in 14 and keep it as is in 13, especially since there were

> some hacks necessary to use it in 13 that we don't want to carry over

> in 14]


> -sbi


> [1] 


> _______________________________________________

> Mailing-List:

> Post to:

> Unsubscribe:

Dr.-Ing. Frederik Kramer
initOS GmbH
An der Eisenbahn 1
21224 Rosengarten
Phone:  +49 4105 56156-12
Fax:    +49 4105 56156-10
Mobil:  +49 179 3901819
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke

Sitz der Gesellschaft: Rosengarten – Klecken
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155

Post to: