Skip to content

Fix: mypy in a pixi/conda dependency manifest is not a type-check failure - #390

Merged
PabloCodes7 merged 1 commit into
mainfrom
fix/pixi-dependencies-mypy-false-positive
Jul 20, 2026
Merged

PabloCodes7 merged 1 commit into
mainfrom
fix/pixi-dependencies-mypy-false-positive

Conversation

@PabloCodes7

Copy link
Copy Markdown
Contributor

What

A real failed run of pandas-dev/pandas (Unit Tests / Pyarrow Nightly, run 29719453153) was misclassified as python_type_check (0.53), pointing a maintainer at mypy . || pyright.

The actual failure was the pixi env update itself:

Error:   × Failed to update PyPI packages for environment 'pyarrow-nightly'
  ╰─▶ HTTP status client error (404 Not Found) ...
##[error]The process '/home/runner/.pixi/bin/pixi' failed with exit code 1

mypy never ran. It appears only in the per-environment bill-of-materials pixi prints before any job:

Dependencies: python, numpy, pytest, ..., pre-commit, ipython, mypy, scipy-stubs, ...

That single manifest line was \bmypy\b's only witness.

Fix

The classifier already discounts conda's - mypy=1.17.1 env.yml spec and its package table as bills of materials. This adds the pixi/rattler Dependencies: / PyPI Dependencies: listing to the same mention-only guard — matched only when the whole tail is a comma-separated list of package tokens, so a real resolver error (which carries prose, a path, or a code) is untouched. With mypy only ever declared, the run now settles on unknown (decline to auto-repair).

A mypy that actually ran and failed still trips python_type_check on its real diagnostic (covered by tests).

Verification

  • Committed real excerpt: examples/real-world/pandas-29719453153-excerpt.log — python_type_check 0.53 before, unknown 0.15 after.
  • New regression test: tests/test_pixi_dependencies_not_typecheck.py (manifest is discounted; a real mypy error, and a manifest line next to a real failure, still classify as python_type_check).
  • Full suite green: 989 passed, 742 subtests; ruff check + ruff format --check clean; no change to any existing fixture's class (benchmark top-1 across the 40 classes intact).

…lure

A pixi/rattler env resolve prints one bill-of-materials line per environment
(`Dependencies: python, numpy, ..., mypy, scipy-stubs, ...`) before any job
runs. On pandas-dev/pandas's `Pyarrow Nightly` update (run 29719453153) — which
died inside pixi with a 404 fetching a nightly wheel — that manifest line was
`\bmypy\b`'s only witness, so the log came out `python_type_check` at 0.53 and
pointed a maintainer at `mypy . || pyright` for a dependency download.

Discount the pixi/rattler `Dependencies:` / `PyPI Dependencies:` listing the
same way the conda `- mypy=1.17.1` env.yml spec and package table are already
discounted, matched only when the whole tail is a comma-separated list of
package tokens. A real resolver error (prose / path / code) is untouched, and a
mypy that actually ran and failed still trips python_type_check. The run now
declines to `unknown`.

Regression test + committed excerpt from the real run. Full suite green
(989 passed, 742 subtests), ruff clean, no benchmark regression.
@PabloCodes7
PabloCodes7 merged commit 3ec2027 into main Jul 20, 2026
5 checks passed
@PabloCodes7
PabloCodes7 deleted the fix/pixi-dependencies-mypy-false-positive branch July 20, 2026 18:49
@PabloCodes7 PabloCodes7 mentioned this pull request Jul 21, 2026
PabloCodes7 added a commit that referenced this pull request Jul 21, 2026
Cut 0.7.4 from main. The last release, 0.7.3 (2026-07-16), predates ten
false-positive fixes that are sitting on main and not on PyPI: an installed
pytest read as a failing test run (#376), a passing test's title read as a
secrets failure (#380), a PHPUnit assertion read as a Composer failure (#378),
Flutter's cached Gradle Wrapper (#382), Cabal's dependency resolution read as
Maven (#383), Crystal and dune's make targets read as C/C++ (#384, #385), a
parenthesized 504 (#391), mypy in a pixi manifest (#390), an unset TERM read as
a missing secret (#392), a warning-only yarn install and a recovered checkout
(#393), and a verdict held up by invocations alone reporting diagnosis-level
confidence (#395). Every one of those is a wrong answer a maintainer gets today
from pip install patchrail.

Version bumped in the four places that spell it out (pyproject, __init__,
README quickstart, uv.lock), CHANGELOG's Unreleased section dated, and the
real-world benchmark's release-status paragraph corrected: it no longer claims
six fixes are unreleased.

Co-authored-by: PabloCodes7 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant