-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix: CI: isort GitHub action doesn't report expected issues #116
Fix: CI: isort GitHub action doesn't report expected issues #116
Conversation
Hmmm, looks like I've hit a snag - I can't immediately fix the existing codebase, as the isort CI check is giving me more errors than when I run isort locally, even though commands appear to be equivalent. Looks like local command is ignoring the example .py files which are outside the main package, CI including them; and there are maybe some unexpected subtleties when configuring isort using BTW I've switched to ruff format as a replacement for isort +black on other projects. |
f9e7471
to
0c38672
Compare
Lint existing codebase with isort + black to allow fixed CI in #116 to pass checks
0c38672
to
e86d22e
Compare
Did it work as expected? |
No, in short. I've fixed files inside However there seem to be subtle differences in behaviour of |
One option would be to only enforce isort on [PS I do think this may not be feasible to fully fix, as |
I am always very pragmatic. Better get something that works partially, and fix the rest later (if needed) than having nothing at all. |
OK, I'll do that, probably later today, after tidying up. Thanks |
… which appears to have bugs and config documentation gaps
3f9c098
to
4c49a73
Compare
…le behaviour which matches equivalent local command in root directory
4c49a73
to
50b80cf
Compare
I did misconfigure the black compatibility for the official isort action originally, but doesn't seem to be any documentation on how to do it correctly, and in any case it doesn't show diffs like it's supposed to (raised isort-action #90). So I've re-implemented using command-line interface.
It should really be configured to take config from
pyproject.toml
, but that's a possible enhancement; this is restoring expected functionality.NB isort checks are expected to fail on this PR until existing codebase has corrected isort rule run on it. I think is clearest if I do this in another PR. Will do a dry run in my own fork first...