pixi: add root lint tasks - #2442
Conversation
The root `pixi.toml` declared `ruff` as a dependency but no task ever used it, so there was no repo-wide `pixi run <task>` entry point for linting -- contributors had to know to invoke `pre-commit` directly, and `AGENTS.md` tells agents to prefer pixi tasks over raw tool invocations. Add a dedicated `lint` feature/environment with three tasks: pixi run lint # pre-commit run --all-files (the CI equivalent) pixi run lint-staged # pre-commit run (staged files only) pixi run lint-install # install the git hook All three route through pre-commit rather than calling ruff directly. That is deliberate: `.pre-commit-config.yaml` applies per-hook `exclude` patterns (generated `*.pyi` files, `_fast_enum.py`), so a bare `ruff check .` reformats 232 files that CI intentionally leaves alone. Routing through pre-commit keeps the task and pre-commit.ci in agreement by construction. `ruff` stays in the environment for ad-hoc use. The feature uses `no-default-feature = true` so the linters are not solved into the cu12/cu13/docs environments. `pixi.lock` migrates from format v6 to v7 as a side effect of re-locking with pixi 0.73; the other three workspace lockfiles are already on v7. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Verified the empty-dispatcher-environment concern raised in the description: with |
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
mdboom
left a comment
There was a problem hiding this comment.
In the interest of reducing complexity, what's the advantage of any of this once the pre-commit hook is installed (which should be the default for the highest safety of slipping by pre-commit)?
What
The root
pixi.tomldeclaredruffas a dependency but no task ever used it, so there was no repo-wide entry point for linting. Contributors had to know to invokepre-commitdirectly, andAGENTS.mdtells agents to prefer pixi tasks over raw tool invocations.Adds a dedicated
lintfeature/environment with three tasks:Why route through pre-commit instead of calling ruff directly
This was the interesting part.
.pre-commit-config.yamlapplies per-hookexcludepatterns — generated*.pyifiles andcuda/bindings/_internal/_fast_enum.py. A bareruff check --fix .at the root does not honour those, and reformats 232 files that CI intentionally leaves alone (I hit this while developing the change). Routing every task throughpre-commitkeeps the task and pre-commit.ci in agreement by construction, with no second copy of the exclude list to drift.ruffstays in the environment for ad-hoc use (pixi run -e lint ruff format <file>).Notes for reviewers
no-default-feature = true, so the linters are not solved into thecu12/cu13/docsenvironments.ruffout of[dependencies]leaves those three environments with an empty package set. They exist only to dispatch into the sub-package manifests, so this is intentional — but it does meanpixi run -e cu13 ruff ...no longer resolves. Happy to keepruffin[dependencies]instead if you'd rather preserve that.pixi.lockmigrates from format v6 to v7 as a side effect of re-locking with pixi 0.73. The other three workspace lockfiles are already on v7, so this brings the root in line.Verification
pixi run lintruns the full suite green with zero file modifications — SPDX, generated-file seals, cuda-version pins, mypy, cython-lint, lychee, actionlint all pass.PLC Local Security Evidence (Advisory)
Local advisory checks only. Authoritative release gates remain Pulse, SonarQube, Coverity, BlackDuck, nSpect, ScanSpect, OSRB, and Anchore — none of the rows below are release-gate results.
gitlab-master.nvidia.com:5005(needs a PAT withread_registry)pixi.lockis a conda+PyPI lockfile; pip-licenses reads only installed Python distribution metadata and has nopixi.lockparser. BlackDuck + OSRB remain authoritative