-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add ruff to pre-commit hooks #41
Comments
Quick update: I moved The transition was painless, so unless you object @grovduck I think I would recommend we do the same for |
@aazuspan, man, good timing on this one ... I was just complaining over in #40 that I'm having issues with some of the pre-commit (specifically I'm all for this change if you think it will work well. Do you get a sense for whether I should perhaps merge in #40 (with the duplicated tests) before you tackle this or vice versa? I'm happy to sit tight if you think this would be a pretty straightforward transition and also happy to merge in the PR if that makes sense. I know we could also do it concurrently and I'm fine with that as well. Quick question without doing a lick of research: will ruff make it easier to avoid the typing errors that I've managed to push over and over, i.e. does it have any |
I was hoping there was a lint rule in there that would catch these kind of backwards compatibility issues ( Maybe we need to reconsider including |
- Remove sourcery from pre-commit per discussion in #40 - Replace flake8 and isort with ruff - Add new checks via ruff including pyupgrade This also brings everything into compliance with the new checks: - Replace nested context managers with single block - Remove unused param from `test_estimators_support_dataframes` - Move noqas in docstrings. Ruff wants them placed at the end of the multiline string, not on the offending line. - Remove unused noqas.
@grovduck, regarding testing across Python versions, I just come across a config option in |
@aazuspan, this sounds great!
I poked around for a bit, but I couldn't find any guidance on how to do this in hatch's docs or elsewhere. Have you found any links to know the mechanism for how hatch might find the different interpreters? This sounds like a great solution if, as you say, we can set up a reliable way to set up the interpreter finding! |
I haven't found any official docs, but this discussion links to this code which shows that hatch uses the That same discussion and this one both suggest pyenv as a solution for setting up multiple Python versions, but installation on Windows is a hassle. I've been experimenting with that, but still haven't gotten anything to work quite right... Python environment management isn't any fun 😫 |
Wow, I can tell you are already waist-deep into it! I know you'll want to solve this - if there's anything I can do to help test, please let me know. |
Adding |
In the interest of cleaning out old issues, I'm going to close this now and hold off on opening a new one until we find ourselves needing local Python version testing (fingers crossed we won't!). |
pyupgrade standardizes syntax, including type annotations, to a minimum Python version. That should make it easier to maintain consistency, especially as we drop support for older versions of Python.
Good overview of the tool: How to Upgrade Syntax with pyupgrade
EDIT: Rather than adding
pyupgrade
, we could switch to ruff which supports almost all of the features ofpyupgrade
,flake8
,isort
, and a variety of other linters (includingflake8
extensions likebugbear
anddocstrings
.) In addition to being much faster than our current tools, this would consolidate almost everything into a single tool.@grovduck let me know if you have any preferences here on tooling. Otherwise I'll probably try migrating
sankee
toruff
over the weekend to get a better idea of whether there are any sticking points, and report back.The text was updated successfully, but these errors were encountered: