Is there a way to use Ruff version from PATH?

[FCamborda]

Hi,

currently we setup our pre-commit specifying a revision for Ruff.

repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
  # Ruff version.
  rev: v0.8.0
  hooks:
    # Run the linter.
    - id: ruff
    # Run the formatter.
    - id: ruff-format

This installs Ruff with version 0.8.0 and works very well. However, every time we upgrade our dependencies, we have to maintain different places where the Ruff version is defined.
We would like for pre-commit to use Ruff as-is found via PATH (either installed via Shell, or if installed in an isolated venv like with uv tool install).

[MichaReiser]

As I understand it, the main reason for using Ruff's pre-commit plugin is that it installs the specific Ruff version for you.

I'm not a pre-commit user myself, but could you try using the system plugin to run an arbitrary command, in this case, ruff?

[ssbarnea]

@MichaReiser Please close this issue, that request makes no sense as it is against core pre-commit concepts. But yeah, you have the right answer.

[bluenote10]

The problem is that ruff is also often pinned/installed in the venv so that it can be used by other developer tooling.

Having two definitions of the ruff version is a pain: It's a rather frequent issue that the two versions are not kept in sync, leading to inconsistencies when operating with two different ruff versions on the same code base. So far, I haven't found a reliable way to ensure the versions cannot go out-of-sync.

Thus, it is a quite sensible request to have a single source of truth of the ruff version. The simplest solution would be to allow using ruff from a venv so that there cannot be multiple versions to begin with.

Please close this issue, that request makes no sense as it is against core pre-commit concepts. But yeah, you have the right answer.

Perhaps it can be rephrased as "is there a way to use an externally defined ruff version" instead of "ruff version from PATH"? This would make it more aligned with pre-commit concepts (because the installation can still be isolated)., and still captures the need for having a single-source-of-truth of the version itself (not the specific installation).