typeshed_source_unpinned analyze

The active typeshed source is not pinned to an exact commit, so type checks are not reproducible across machines and CI

Basilisk type-checks your code against typeshed, the community's standard-library and third-party type stubs. Which revision of typeshed is active decides which symbols and signatures exist, so two machines resolving different typeshed contents can disagree about whether the same code type-checks.

Basilisk bundles a vetted typeshed snapshot inside the binary and serves it by default. A build-time snapshot is not a user pin: upgrade Basilisk and the snapshot moves. When no typeshed-commit is set — or when a custom typeshed-path folder is used, whose contents can change on disk — Basilisk raises this advisory to say the type-checking baseline is not reproducible.

Pin an exact python/typeshed commit so every machine and CI run resolves byte-identical stubs. A pin fails closed — Basilisk never silently substitutes another commit:

[tool.basilisk]
typeshed-commit = "…full 40-character SHA…"

This is an ordinary Basilisk diagnostic. Grade it like any rule — raise it to an error in CI, or silence it once you have accepted the unpinned default:

[tool.basilisk.rules]
"typeshed_source_unpinned" = "error"   # or "off" to silence

It is reported out of band — on the CLI's stderr banner, in the editor's Server Info panel, and as MCP status — and never as a Python diagnostic, so it can never affect conformance.

Canonical documentation

How to handle it

This Basilisk-specific rule is off by default. Enable its stubs tag when the policy fits your project, then configure its severity globally or per path in pyproject.toml.

Canonical URL: https://www.basilisk-python.dev/errors/typeshed_source_unpinned