ruff-odoo

ruff-odoo is Vauxoo's fork of Ruff, shipping every upstream linter and formatter rule plus the OD and OAPP rule groups, ported from pylint-odoo and odoo-pre-commit-hooks.

The Odoo rules, how to enable them, and how to migrate from pylint-odoo: https://vauxoo.github.io/ruff-odoo/
Everything else — configuration, the formatter, editor integrations, the upstream rules — behaves exactly as upstream and is documented at https://docs.astral.sh/ruff/.

This file covers what differs from upstream Ruff for anyone installing or building the fork: why it exists at all, the command name, the packaging, and the version scheme.

Why this exists

Vauxoo's Odoo checks used to live in pylint-odoo (a Pylint plugin) and odoo-pre-commit-hooks, running next to the autofixing tools already present in the pre-commit stack. Three problems pushed us to port those checks into Ruff instead, and none of them was something a patch to those projects could have fixed.

Autofixes corrupted each other. Every tool rewrote the file on its own, with no idea of what the others had done to it. A fix applied by one hook routinely invalidated a fix another hook had just applied, or uncovered a violation that only became reachable after the first rewrite. So the run ended dirty, the command had to be run a second time, and that run pulled in yet another fix. Getting a repository to a fixed point — a run that proposes no changes — commonly took three or four passes of the same command. That is confusing on a developer machine and simply broken in CI, where there is one run and a dirty tree is a failure.

Ruff does that iteration internally: it lints, applies every non-overlapping fix, re-parses the result, and repeats until the file stops changing, discarding any fix that would have introduced a syntax error. One invocation, one stable file.

Pylint has no autofixes. Pylint only reports. Any check we also wanted fixed automatically had to be written twice — once as a Pylint checker that reports it and once as a separate fixer that rewrites it — with two sets of tests, two notions of what the pattern is, and no guarantee the two stayed in agreement as they were maintained. In Ruff a fix is attached to the diagnostic that produced it, so the rule that finds a problem is the same code that repairs it, and its fixture covers both.

Speed, which mattered more than anything else. A linter is only run as often as it is cheap to run. Pylint infers types through astroid, and a stack of separate hooks pays for a process start and a fresh parse of every file per tool. Ruff parses each file once, in Rust, in parallel across cores, and caches unchanged files between runs — fast enough to run on save and on every commit rather than only in CI, which is what makes the rules actually shape the code being written instead of being discovered at review time.

Why a fork, and not a separate repository

The obvious alternative was to keep the Odoo rules in their own project and just depend on Ruff. It does not work, for reasons that are structural rather than incidental:

Ruff has no plugin system. Rules are compiled into the binary; there is no dynamic loading, no stable ABI, and no "register a rule" entry point to call from the outside. That is a deliberate design choice upstream — it is part of why a single static binary can dispatch rules with no per-rule overhead — not a gap waiting to be filled.
A rule is not self-contained. Adding one touches files that upstream owns: the code-to-rule map in codes.rs, the linter enum in registry.rs, the dispatch inside the AST visitor in checkers/ast/analyze/, the settings struct behind lint.odoo, and the generated JSON schema and docs. There is no seam an external crate could attach to.
The internal crates are not a public API. ruff_linter describes itself as "an internal component crate of Ruff": it is versioned with the binary and refactored freely. A separate project built on it would break on close to every upstream release, which is a worse maintenance burden than a rebase.
A second tool would recreate the original problem. Even with all of the above solved, shipping the Odoo rules as a second binary means a second process, a second parse, a second fix pass over the same file, a second configuration file, and a second suppression syntax. The whole point is that the Odoo rules run in the same pass as everything else: one command, one AST, one --fix, one # noqa, one cache, one pyproject.toml.

The cost of this choice is having to rebase onto upstream Ruff, and that is accepted knowingly. The fork is arranged to keep that cost low: the Odoo rules live in their own directory, upstream files are touched as little as possible, and the ruff crate and its binary are left untouched behind a thin wrapper crate.

The `ruff-odoo` command

The published command is ruff-odoo, not ruff. It is the exact same CLI, only under a name that cannot collide with an upstream ruff installation, so both can live in the same environment:

$ ruff-odoo check   # Lint all files in the current directory.
$ ruff-odoo format  # Format all files in the current directory.

The Python module is ruff_odoo, so the CLI is also reachable without the console script:

$ python -m ruff_odoo check

Installation

The package is published to PyPI as ruff-odoo. It is not distributed through Homebrew, conda, Docker, or the standalone astral.sh installers — those channels ship upstream Ruff only.

$ # Run it without installing.
$ uvx ruff-odoo check

$ # Install it globally.
$ uv tool install ruff-odoo@latest

$ # Or add it to your project.
$ uv add --dev ruff-odoo

$ # With pip.
$ pip install ruff-odoo

Installing ruff-odoo alongside the upstream ruff package is supported, even in the same environment: ruff-odoo owns the ruff-odoo entry point and never touches ruff.

pre-commit

Use the mirror repository, which installs the prebuilt wheels:

repos:
  - repo: https://github.com/vauxoo/ruff-pre-commit
    # Use the latest release tag; see the version scheme below.
    rev: 0.16.3.34
    hooks:
      - id: ruff-check
      - id: ruff-format

The hook ids match astral-sh/ruff-pre-commit, so switching between upstream and this fork means changing only repo and rev.

This repository also defines the hooks directly (see .pre-commit-hooks.yaml), but pointing repo at it builds Ruff from source with maturin on every environment creation, which is slow and requires a Rust toolchain. Prefer the mirror.

Version scheme

Fork releases use four components, x.y.z.w:

x.y.z is the upstream Ruff release this fork is based on (for example 0.16.2).
w counts the fork's own releases, independently of that upstream base.

So 0.16.2.4 is the fourth Vauxoo release, built on upstream Ruff 0.16.2. When the fork is synced onto a newer upstream, x.y.z follows it and w carries over untouched: syncing 0.16.2.4 onto upstream 0.16.3 gives 0.16.3.4, and the next release is 0.16.3.5. The counter never restarts, so a fork version is never reused and never goes backwards.

The version lives in [project] version of the root pyproject.toml and is bumped by bump2version (see .bumpversion.cfg), which also creates the release tag. Tags are the bare version with no prefix (0.16.2.4, not v0.16.2.4); pushing one triggers the PyPI release workflow. Because every fork tag has four components, it can never be confused with one of upstream's three-component tags.

Cargo cannot express a four-component version, so crates/ruff_odoo/Cargo.toml keeps the three-component x.y.z and crates/ruff/build.rs reads the real version out of pyproject.toml at build time, exposing it as RUFF_ODOO_VERSION. A build made outside a checkout of this repository falls back to the Cargo version.

Reporting the version

--version prints the bare version and nothing else:

$ ruff-odoo --version
ruff-odoo 0.16.3.34

It stays bare on purpose: tools that shell out to the binary (ruff-lsp, for one) parse that output as a PEP 440 version and fail on anything appended to it.

The version subcommand is the verbose one. It adds the number of commits since the release tag and the commit the binary was built from:

$ ruff-odoo version
ruff-odoo 0.16.3.34+3 (b45cfcb38 2026-08-15)

The leading name is the binary that was actually invoked, so a locally built ruff dev binary introduces itself as ruff. A release build sitting exactly on its tag has no +N suffix.

For machine-readable output, ask for JSON:

$ ruff-odoo version --output-format json
{
  "version": "0.16.3.34",
  "commit_info": {
    "short_commit_hash": "b45cfcb38",
    "commit_hash": "b45cfcb38d111d9f446b195125290a19e4cf8a4e",
    "commit_date": "2026-08-15",
    "last_tag": "0.16.3.34",
    "commits_since_last_tag": 3
  }
}

Building from source

The ruff-odoo binary is a thin wrapper crate (crates/ruff_odoo) around the untouched upstream ruff crate; the only differences are the displayed command name and the error prefix. Keeping the ruff crate and its binary unmodified is what keeps rebases onto upstream cheap.

Both binaries build from this checkout, and either one is fine for development:

cargo run --bin ruff-odoo -- check path/to/file.py
cargo run --bin ruff -- check path/to/file.py

See AGENTS.md for the full development workflow, and CONTRIBUTING.md for upstream's.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

ruff_odoo-0.16.3.34.tar.gz (5.0 MB view details)

Uploaded Sep 6, 2026 Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

The dropdown lists show the available interpreters, ABIs, and platforms. Enable javascript to be able to filter the list of wheel files.

ruff_odoo-0.16.3.34-py3-none-win_arm64.whl (11.7 MB view details)

Uploaded Sep 6, 2026 Python 3Windows ARM64

ruff_odoo-0.16.3.34-py3-none-win_amd64.whl (11.7 MB view details)

Uploaded Sep 6, 2026 Python 3Windows x86-64

ruff_odoo-0.16.3.34-py3-none-win32.whl (11.3 MB view details)

Uploaded Sep 6, 2026 Python 3Windows x86

ruff_odoo-0.16.3.34-py3-none-musllinux_1_2_x86_64.whl (12.0 MB view details)

Uploaded Sep 6, 2026 Python 3musllinux: musl 1.2+ x86-64

ruff_odoo-0.16.3.34-py3-none-musllinux_1_2_i686.whl (11.5 MB view details)

Uploaded Sep 6, 2026 Python 3musllinux: musl 1.2+ i686

ruff_odoo-0.16.3.34-py3-none-musllinux_1_2_armv7l.whl (11.0 MB view details)

Uploaded Sep 6, 2026 Python 3musllinux: musl 1.2+ ARMv7l

ruff_odoo-0.16.3.34-py3-none-musllinux_1_2_aarch64.whl (11.3 MB view details)

Uploaded Sep 6, 2026 Python 3musllinux: musl 1.2+ ARM64

ruff_odoo-0.16.3.34-py3-none-manylinux_2_31_riscv64.whl (11.9 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.31+ riscv64

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (11.4 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ x86-64

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_s390x.manylinux2014_s390x.whl (12.0 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ s390x

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_ppc64le.manylinux2014_ppc64le.whl (12.7 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ ppc64le

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_i686.manylinux2014_i686.whl (11.8 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ i686

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_armv7l.manylinux2014_armv7l.whl (11.0 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ ARMv7l

ruff_odoo-0.16.3.34-py3-none-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (10.9 MB view details)

Uploaded Sep 6, 2026 Python 3manylinux: glibc 2.17+ ARM64

ruff_odoo-0.16.3.34-py3-none-macosx_11_0_arm64.whl (10.7 MB view details)

Uploaded Sep 6, 2026 Python 3macOS 11.0+ ARM64

ruff_odoo-0.16.3.34-py3-none-macosx_10_12_x86_64.whl (11.5 MB view details)

Uploaded Sep 6, 2026 Python 3macOS 10.12+ x86-64

ruff_odoo-0.16.3.34-py3-none-linux_armv6l.whl (11.2 MB view details)

Uploaded Sep 6, 2026 Python 3

File details

Details for the file ruff_odoo-0.16.3.34.tar.gz.

File metadata

Download URL: ruff_odoo-0.16.3.34.tar.gz
Upload date: Sep 6, 2026
Size: 5.0 MB
Tags: Source
Uploaded using Trusted Publishing? Yes
Uploaded via: uv/0.12.3 {"installer":{"name":"uv","version":"0.12.3","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"Ubuntu","version":"24.04","id":"noble","libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":true}

File hashes

Hashes for ruff_odoo-0.16.3.34.tar.gz
Algorithm	Hash digest
SHA256	`e58e8896a7bdbec85cf90b2044d92c830c7864759755b62fadaa449517f59683`
MD5	`f4f3ee815914bdc57fdf48cffa233dc0`
BLAKE2b-256	`02fccb0539317ec89fd6abd17b52a1562b1ccdecbe1171497dcfecdb797c3c02`

Algorithm	Hash digest
SHA256	`81e862c8b78de732ae3ba80b6d6bffc4e0911cc70e5676ca4e1d891e3606fe5b`
MD5	`e20d523f1b429948827ce6b31cd2a0c1`
BLAKE2b-256	`088a1a997a1483925df5891653e9829aed5a01523e3a9b94cc1c0150c398e9b0`

Algorithm	Hash digest
SHA256	`1c69d8baab06dea08b35438a0809828c6179b5eaf9d602b21803d6b4dd2f6cd8`
MD5	`14285e01d1ac8e10414dd4f447f8255e`
BLAKE2b-256	`facd1a5ad0d65bd9862449c2237f3169b224deb3d6d4dcf81a738e45a0f7388e`

Algorithm	Hash digest
SHA256	`c393fb0d44f1373e2403f0457f66927e2fc94803781edacc455ab1be44d2ff1d`
MD5	`ca3da7f7d921a30ecf0295d869e7b1ee`
BLAKE2b-256	`e179c6b7248066e537830a7ab277ccbdfe0a44173c3f7497161075324ebde1a8`

Algorithm	Hash digest
SHA256	`31bbda60bd766c54ccff4e4fd66858eb84d0dafd5b3bc0f5dd816129c4dcb1cd`
MD5	`56a266614f313391af68534cd1631320`
BLAKE2b-256	`4bef95cbd23ca45c825288dd5e63145fb261e4f3ffcc687bf59744fda1ffd782`

Algorithm	Hash digest
SHA256	`a7ccd05bc2e1705f1315a75c679a372f9028bb798de180762536e3ab23df8213`
MD5	`b6432e3b16c267566249f63903df7a54`
BLAKE2b-256	`75fcf0969318cb1f195579b100b229c7429da54916e52d97e25daa8b05eaad5d`

Algorithm	Hash digest
SHA256	`52c65113ec8d9cdba6c626a5764fe150b80cbb28073a069df76af0386e64f8d7`
MD5	`2d06ced1820482fd7a49cf2d64e11e44`
BLAKE2b-256	`a4fd7e5da33730c785450afc3325450c3f957c9f4607be7fdafbb2555ec86b45`

Algorithm	Hash digest
SHA256	`f6a5f6defe8483fe8af1a2bfd03b665f8b8020c8c7e979831433ec8c53091673`
MD5	`817ecd3460825f8af8631a8f0b101a48`
BLAKE2b-256	`042e1b0437b3bfbe1747d1f7db4afe7f1c49aa0c558c921121fc1c39c17208cd`

Algorithm	Hash digest
SHA256	`2fdd555c98c6eb68040d9b8574814a8e6af1c36b2e6740834040346d3ba0392f`
MD5	`1aaedc5583bb2a300580618b2561a65d`
BLAKE2b-256	`49f67fc8d3027a553598c319d8ed8b5778b1afad40e35b608e89c637f0e2e278`

Algorithm	Hash digest
SHA256	`52549b919ccc42ba1ea0e1140a838cf058b56571aafda7191520ba0be93c6167`
MD5	`a9fea72431512e29b20b30c7cc2e4307`
BLAKE2b-256	`4af54264d4938d20b881c6549ac679f14453c4372a280045bb4834179df0af63`

Algorithm	Hash digest
SHA256	`2ef04aca8d04a5ca44707131d901debafb65a0a0d344f508ff8b4b6a0c05b34a`
MD5	`b24898923d83fee7972cbba87f36b6f8`
BLAKE2b-256	`aa756365f2f7b3e8144d7a8e5c41129ee4a4268a7ba35d7cffd2d3ca74c9334e`

Algorithm	Hash digest
SHA256	`9314c519d7e1d7c7440cdcda715b2ea4a8d2ff280067fe35ef85a76622b79286`
MD5	`fb022ce7e847feb3797d068bc340ba57`
BLAKE2b-256	`1b985459f3f010cb43976bbfcb25fccf558da57745425fa6a9ffab24819ecbf5`

Algorithm	Hash digest
SHA256	`00090098ceaf379801efaf957ba7afe28057a1cdf38851b1e429af42b89a2552`
MD5	`117bba88ff8a6c38428c6ddf01920fd4`
BLAKE2b-256	`20047a6a3fa6c8301e40ce1349d18fa11540671aaa0f2b7bb01fe266d600c197`

Algorithm	Hash digest
SHA256	`65bbff015c95adc501fba8a92a935bc3cea19964a8549cda90ec37305bca6fb7`
MD5	`deb7539ee362d9c12b77cd38094b7d02`
BLAKE2b-256	`af4a112db0cf0f581be361adbba5e1a0b44282e9515703f20e62d35e5389e660`

Algorithm	Hash digest
SHA256	`920b643b98e1a608a0eb70e0db35eb7e2a6fe7da93aa481a31e6b8a6d53ad495`
MD5	`0d252367f109fccd592906523dac7b84`
BLAKE2b-256	`a521efa4bc2380a1126ae5bb0ab49b3205b9ed90f02cf73f6254fd642ebcdb27`

Algorithm	Hash digest
SHA256	`cdac6129487dc1e27da79f99f61aa28704d2917af1c3069c7803cac8fc2fcfb6`
MD5	`9dbaa8bad668fe0f312f57543e0fdbd8`
BLAKE2b-256	`7a75d5ea2b330845235744ac143ae0af59b1b6910cc98968bad3526f8084fd05`

Algorithm	Hash digest
SHA256	`230688af5186e8f55ef5f39eb1093b6a922493add9cf8ca9088645120c5ce8c5`
MD5	`97087090d9d67941d68fcad4ebe299f7`
BLAKE2b-256	`8b46f346d8cfe49241fee3db449d2599f76c83e2db6647a16cbb68575873ecb3`

Algorithm	Hash digest
SHA256	`abb8e7cd79b76d177cf22c15f3734a0c53c6a989780ad959f2dfe2e0598e3821`
MD5	`40a34ddda7c16461cc163ef1e697147d`
BLAKE2b-256	`f327c0259cf7b25d28d98d7be780bc59e9e61cc7a623528aa2666ce48b8089d2`

ruff-odoo 0.16.3.34

ruff-odoo

Why this exists

Why a fork, and not a separate repository

The ruff-odoo command

Installation

pre-commit

Version scheme

Reporting the version

Building from source

Project links

Key dates

2 maintainers

Credits

GitHub Statistics

License expression

Requires

Tags

Classifiers

Download files

Source Distribution

Built Distributions

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

File details

File metadata

File hashes

Release history Release notifications | RSS feed

The `ruff-odoo` command