Repository navigation
Changes to black formatting #149
Description
I've noticed that black on my system is folding lines differently to what is in the repo, despite that also being formatted by black.
For example in base/vectors.py line 622 was
@overload
def angdiff(a: ArrayLike, b: ArrayLike) -> NDArray:
...
but black now formats it like
@overload
def angdiff(a: ArrayLike, b: ArrayLike) -> NDArray: ...
There's a discussion about this here. I'm using 24.8.0 from Aug 2024. TBH I like the new format better, but this is going to throw a lot cosmetic noise into the commits which is annoying -- the whole point of black was supposed to be stability and inflexibility.
Would appreciate discussion on this. I think there are only 2 options:
- pin the version of black that all contributors use, impossible to enforce
- accept that there will be a lot of unnecessary changes for a while until things settle down
Activity
myeatman-bdai commentedon Jan 14, 2025
Ah, just getting eyes on this.
We added a
.pre-commit-config.yamlfile that calls out the specific version of black and the other pre commit hooks (this was copied and paired down from what we use internally in our big repos). My apologies if this generated some friction. I think this gets to the enforcing a version of black for contributors. Runningpre-commit installfrom the root of the repo should get people setup.petercorke commentedon Jan 15, 2025
pre-commit installdoes cause the formatting to be fixed up on commit, but I'm using a Visual Studio extension which blacks code on every save. So code formatting keeps reverting back to the non standard one.So for any people (4.2M users) using this extension it's important to change the default setting:
petercorke commentedon Jan 15, 2025
I will remove/modify PR #152 and resubmit it without all the gratuitous format changes.
petercorke commentedon Jan 15, 2025
I'm trying to now commit the properly blacked files, and the pre-commit hooks kicked in (good thing) but now I can't commit (bad thing):
ruffis mostly fixated onimport *, not best practice, but pervasive in this package :(. It also doesn't seem to understand the@overloadsyntax for different type signatures.I don't see any
ruffconfiguration options inpyproject.toml, but I'm guessing you are not seeing this kind of behaviour.I tried adding to
pyproject.tomlbut there was no change in
ruffbehaviour.The
blackand trailing white space commands did their job, so their fails got turned into passes on subsequent commit attempts.I've not used pre-commits or
ruffbefore.myeatman-bdai commentedon Jan 17, 2025
I'm getting the same issue as you are when I try to commit the changes in PR 152 to a branch, a spew about star imports and the like. I generally haven't had this issue in the past, I'm not sure what has changed. I'm investigating now.
myeatman-bdai commentedon Jan 17, 2025
I think what's happened is that we added this
pre-commit-config.yamland then we (people at the institute) just haven't been actually installing it when we've been making changes to the repo. I'm going to make a quick PR to remove the pre-commit check, and then later we can have a big reformatting PR or the like to resolve this.petercorke commentedon Jan 18, 2025
For those who actually did the pre-commit install you still need to uninstall
before you nuke the
.pre-commit-config.yamlfile so it knows what to uninstall.Just removing the file, without uninstalling doesn't fix the problem.
petercorke commentedon Jan 21, 2025
Could one of the BDAI crew apply all the outstanding PRs and then run black 23.10 on the whole repo. It'll make life a whole lot easier for devs.
myeatman-bdai commentedon Jan 22, 2025
Yes, I will give it a shot.
myeatman-bdai commentedon Mar 7, 2025
Closed based on #161 getting merged.