Add ruff to pre-commit hooks about sknnr HOT 9 CLOSED

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.

from sknnr.

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!).

from sknnr.

Quick update: I moved sankee over to ruff, and as you can see it allowed me to simplify the pre-commit config substantially. I replaced everything but black with ruff, and added some additional checks in the process (you can see all the supported options here).

The transition was painless, so unless you object @grovduck I think I would recommend we do the same for sknnr. Probably the only downside would be if you like to run tools individually or use more advanced options that might not be available in the ruff CLI.

from sknnr.

@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 sourcery). I'm guessing sourcery is not in ruff and I think that would be just fine.

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 tox-like capabilities to check the matrix of python versions?

from sknnr.

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 tox-like capabilities to check the matrix of python versions?

I was hoping there was a lint rule in there that would catch these kind of backwards compatibility issues (ruff is aware of the target Python version), but I don't think there is.

Maybe we need to reconsider including tox. I guess the other alternative would be to always develop in the minimum supported version environment, but that's a hassle...

from sknnr.

@grovduck, regarding testing across Python versions, I just come across a config option in Hatch that allows you to specify a matrix of Python versions and test against one or all of them. Hatch still needs to be able to find interpreters for the requested versions locally (not sure of the best way to get that set up reliably), but I'm thinking this might be a simpler solution than adding in tox.

from sknnr.

I just come across a config option in Hatch that allows you to specify a matrix of Python versions and test against one or all of them

@aazuspan, this sounds great!

Hatch still needs to be able to find interpreters for the requested versions locally (not sure of the best way to get that set up reliably)

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!

from sknnr.

I haven't found any official docs, but this discussion links to this code which shows that hatch uses the virtualenv.discovery.builtin.get_interpreter function to locate Python versions. The docs for virtualenv have some details on how Python versions are discovered, which seems to be based on having them defined on the system path.

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 😫

from sknnr.

Adding ruff is resolved by #43, but I'll leave this open for the moment until we resolve or split off the question of Python environment testing with Hatch or tox.

from sknnr.