Set black up in the pre-commit with a specific version. When you make a commit it will black the files being committed using the specific version of black. As it's a subset, it's fast. As it's a specific version, it's not going back and forth.
It doesn't… people use a million different distributions. Forcing everyone to use a single version of black means that people will just not bother with your project.
The authors of black just don't understand that it'd be ok to introduce new rules to format new syntax, but it isn't ok to just change how previous things work.
This is mostly nonsense and FUD. We have virtualenvironments, requirements files, setup.py with extra_requires that can all be used to manage versions without relying on the particular packages installed on an OS. Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning.
And if they are not, then maintainers can pull, run black over the diff, and commit.
CI prevents poorly formatted code from entering main.
The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill.
Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.
> Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.
Yes, it would work very well if said tool didn't change its mind every 6 months, generating huge commits at every bump
> Most people contributing to open source would be familiar with at least some of these methods and if they are not it’s a good opportunity for learning.
You seem unfamiliar with the fact that other people aren't necessarily clones of yourself and might not behave like you.
> CI prevents poorly formatted code from entering main.
If you run black on CI… which of course I don't since every time they make a new version I'd have the CI start failing.
And no pinning is not a "solution"… it's at best a workaround for badly written software.
> The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill.
If you have 10 lines of code, I guess your diff can't be more than 10 lines. If you have more than 10 lines…
I’m working in a Python code base with multiple millions of files and not for the first time. It’s not the problem you make it out to be. The changes between black versions have been almost unnoticeable for years.
since developing in python should be done in a virtual env to start with, I fail to see how this will be any problem.
The pre-commit documented version of black will be installed in the venv of the project, problem solved.
pre-commit is very useful, in my opinion. When organising code from a lot of Python developers at least, getting the boring stuff like formatting, import ordering, linting, mypy etc. sorted is a time saver.
Do you know how slow all of that is? Do you want to run all of that per every commit? The result would be people making a monocommit rather than incremental commits that is easy to review one by one.
Reformatting the whole code every version isn't so good. It's also very slow.