Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Ruff #175
Ruff #175
Changes from 1 commit
664ebef
97139cb
8f8c15f
a9659e2
b5cab45
64f78cd
072e6ac
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah here's the philosophical rub. We've talked about how appropriate it is to automatically fix bad code for the developer in a way that they aren't brought into the loop so they can learn to be better.
This does bring them into the loop a little bit, by not auto-committing the results at least. So I'd like to keep it that way, if/when we make the auto-formatting auto-committed.
I'd personally prefer to keep such checks out of the commit hooks altogether because of my WIP-commit-heavy workflow. I assume your workflow is different.
Anyway, we don't need to agree on this kind of thing. Just raising the point again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, per this and our chat off PR about this last night, I did some digging and found that pre-commit supports hooks at basically every lifecycle stage, so i've moved this check to pre-push. It didn't look like it is installed normally, so you have to specify the stage with
pre-commit install --hook-type pre-push
, but it then does the linting only on push to remote.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting... OK - we have the
pre-commit
instructions in our CONTRIBUTING.md docs usually (I think that's what we named them). - maybe those need updating.It's annoying that pre-commit isn't more turnkey, but fine 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yep, meant to do that and spaced out - bumped the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the other hand, formatting I find it awkward to push in front of the dev - they didn't do anything wrong really. So this I'd like to see return to auto-commit status at some point, once we trust it (which off-PR we talked about as the reason for this change).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be
None
alright?! Geeze...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was my least favorite addition. we could disable it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That wouldn't help here exactly, because these were explicit Optionals not implicit.
But I can see the logic for disallowing implicit optional - like if change the default value to not be
None
anymore, it's a little surprising for that to also change the type of the arg itself. But that's the kind of argument for a library with a strict API and not just devs making code.I'm fine either way. Disabling individual rules is a little annoying, config wise, but maybe it's a win overall.