Replies: 2 comments 1 reply
-
@diazona Thank you for the detailed explanation. Here is my proposal:
Before discussing ruff, it's important to address testing on Python 3.6. While I currently perform tests locally with Python 3.6, considering pull requests, it's crucial to automate tests on Python 3.6 in CI. I would like to modify the release.yml to include tests on Python 3.6, in addition to the existing tests on Python 3.10. Furthermore, when creating the pre-commit CI job, I would like to ensure that it includes testing on Python 3.6 as well. Regarding ruff, I believe it's sufficient to perform checks based on Python 3.10. From a linter perspective, I don't anticipate significant differences between Python 3.6 and 3.10. Additionally, due to Python's backward compatibility, syntax considered invalid in Python 3.10 should also be invalid in Python 3.6. Therefore, I consider the checks in Python 3.10 to encompass those in Python 3.6. Considering the possibility of utilizing syntax or features introduced in Python 3.7 or later during pypipe modifications, in such cases, ruff checks may pass, but errors are expected in Python 3.6 tests (pytest) if the tests are properly written. Out of curiosity, I checked pypipe with ruff version 0.0.233:
These errors don't impact functionality. While not detected in the latest version of ruff, I suspect this difference is due to variations in ruff's checking policies. Personally, I prefer these errors not to be detected, so I am inclined to use the newer version of ruff. If using the latest version of ruff, as you suggested, employing pre-commit.ci in the CI job seems like a better idea. Please feel free to point out any inaccuracies in my understanding. |
Beta Was this translation helpful? Give feedback.
-
@diazona Thanks for your advice. I understand the issues you pointed out. |
Beta Was this translation helpful? Give feedback.
-
Hi @bugen, I thought this would be a good place to continue the discussion from #20 (comment) about how to use the ruff pre-commit hook while supporting Python 3.6.
Let me lay out all the information I know about this - some of it you might also know already, but hopefully the rest is useful - and you can decide how to proceed.
ruff
target-version
ruff needs to target a specific Python version. It won't recommend changes to the code that would be invalid in earlier Python versions than the target one. Current versions of ruff only support specifying Python 3.7 or later as the target version. However, in order to keep your code compatible with Python 3.6, you should set the target version to 3.6; otherwise there is a risk that ruff will insist you change something in a way that would be invalid in Python 3.6.
So, as long as you want to ensure that the code of pypipe always passes ruff's checks, you cannot safely use a recent version of ruff. You could, of course, continue to do what you're doing right now, namely setting
target-version
to Python 3.10 and just hoping that ruff does not require you to make any changes that would be incompatible with Python 3.6. Personally I wouldn't call that "safe", though.If you want to continue with the "unsafe" approach, that's totally fine. But otherwise, you have to do one of the following:
ruff in pre-commit
If you're going to use ruff as a pre-commit hook, the second option - allow ruff to fail - is not realistic, because the whole point of pre-commit is to (try to) ensure that the hooks pass on every commit. So you're left with using an earlier version of ruff and setting the
target-version
to Python 3.6 (or, really, don't set it at all, and allow it to use the target version specified in theproject.requires-python
key ofpyproject.toml
. From my experience with another project, I know that the latest version of ruff which lets you do that is 0.0.233. So your ruff pre-commit hook would need to look something like this (copied from my other project):Then there is the question of how you actually run these pre-commit hooks. I mean, sure, ideally all developers should be installing the hooks locally and running them locally. But that doesn't always happen. So it is quite useful for you to have a CI job that runs pre-commit.
Using pre-commit.ci
The most common way to have a CI job that runs pre-commit is to register your project with pre-commit.ci. It's a service that will automatically run pre-commit for you on every pull request (or maybe on every push?) and on every update to the main branch. Pretty much all you have to do is register and approve that service to have access to your repo, and then everything will be set up for you - it's quite easy. You don't have to set up any workflows or runners or anything.
However, part of the pre-commit.ci service is that it will periodically make a pull request that updates all your pre-commit hooks to the latest versions. (Basically, this is because every hook used in every project that uses pre-commit.ci has to be cached by them, and they don't want to have to cache many very old hook versions.) You can configure how often these pull requests happen, but you cannot disable them. So if you're using an older version of ruff, like you have to do to safely stay compatible with Python 3.6, the service will periodically make pull requests trying to update the ruff hook (and sometimes other hooks). You'll have to either manually modify those pull requests to "reset" the version of the ruff pre-commit hook back to 0.0.233, or reject them.
Using Github Actions (or pre-commit.ci lite)
The alternative is to set up your own Github Actions job that runs pre-commit. You can use pre-commit.ci lite to help with this, or you can do it manually. Either way, you'll have to add a step to one of your workflow files, presumably
ci.yml
. I don't think it should be too hard, especially if you follow the "pre-commit.ci lite" instructions. However, this way you won't get automatic version updates to any pre-commit hooks at all.Beta Was this translation helpful? Give feedback.
All reactions