Enable black formatter

[gthvn1]

Black is a PEP 8 compliant opinionated formatter with its own style.

[stormi]

What problem is this PR solving in the first place? The commit message says "We want to use Black that is a PEP 8 compliant opinionated formatter", but it's not enough of a reason, as black is not just something that helps you being compliant with PEP 8 (as pycodestyle does already), but also decides that there's only one right way to format, and this is the main change which is not motivated in the commit message.

While not entirely against, I have several concerns:

• We use the same branch of this repo for XCP-ng 8.2 LTS, XCP-ng 8.3, and future development. Either we'll have to change this to maintain a 8.2 branch, or we'll have to push dozens of uneeded changes to a LTS.
• We already have pycodestyle, which forces us to respect basic formatting rules but also leaves space for adaptation. On the other hand, black only accepts one version of how it should be formatted, which is a lot stricter than PEP 8.
• Not everyone develops with autoformatters in an IDE. We have some who use console editors too. They will have to either remember to run black after a change, or see their PRs rejected. This is also something that can make it harder for external people to contribute. See how hard it is already to ask most first-time contributers to do simple changes in their PRs.

[gthvn1]

The main reason is to have a better homogeneous code that is more readable IMHO. But I understand your remarks so we can ignore the PR no worries. Another annoying thing is that it breaks a little bit the search using "git blame" to understand some changes. I'm using it for bigger project and refactoring is always annoying for git search...

And about the setup of IDE, it is true that it's up to the developer to setup its environment but you can setup your IDE or setup some git hook in your local repo or run it manually and there are probably other ways to do it. It is not a big constraint IMHO.

[stormi]

It is not a big constraint IMHO.

I'm afraid it is for occasional contributors. It raises the bar for people who sometimes already struggle with git and github. We can always help them, but experience shows the more things we ask, the more some are prone to giving up.

[benjamreis]

I'm all for it.

[ydirson]

My experience with formatters is that they sometimes get in the way when something complicated has to be formatted specially to make it easier to understand. I have a general dislike for that kind of tools.

[Wescoeur]

My experience with formatters is that they sometimes get in the way when something complicated has to be formatted specially to make it easier to understand. I have a general dislike for that kind of tools.

It's why there is a specific feature in many formatters to handle these cases: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#ignoring-sections

[Wescoeur]

I'm afraid it is for occasional contributors. It raises the bar for people who sometimes already struggle with git and github. We can always help them, but experience shows the more things we ask, the more some are prone to giving up.

I will try to be pragmatic:

• How many contributions do we have on python projects, and more specifically this repo?
• How likely is it that someone who is already struggling with git will have trouble to exec a format command manually?
• Also someone who contributes on python probably knows how to use pip to install a dependency. In the worst case we can help.

[ydirson]

My experience with formatters is that they sometimes get in the way when something complicated has to be formatted specially to make it easier to understand. I have a general dislike for that kind of tools.

It's why there is a specific feature in many formatters to handle these cases: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#ignoring-sections

I would have to use it much too often, and that defeats the whole purpose of the tool.

But this is a discussion we should have a project level, not on any particular project like this.

[Wescoeur]

I would have to use it much too often,

How can you be totally sure about that?

But this is a discussion we should have a project level, not on any particular project like this.

I completely agree. But complicated to set up currently on the installer, and even less on SMAPIv1. But for v3 it is clearly up for discussion in my opinion.

[gthvn1]

My experience with formatters is that they sometimes get in the way when something complicated has to be formatted specially to make it easier to understand. I have a general dislike for that kind of tools.

It's why there is a specific feature in many formatters to handle these cases: https://black.readthedocs.io/en/stable/usage_and_configuration/the_basics.html#ignoring-sections

I would have to use it much too often, and that defeats the whole purpose of the tool.

Sometimes when the code is to complicated to be formatted means that code needs to be rewritten. I don't say it is always the case and I'm sure that we will find cases where disabling formatting is justified. But when there are issues with formatting it is often a good time to think differently ;-)

[ydirson]

How can you be totally sure about that?

By simply running it on a single file I wrote recently

[ydirson]

Must be discussed at project level first