Scan all shipped backend modules

This allowlist omits 115 shipped Python files under auth, hub, models, plugins, picker, state, and storage, along with top-level modules such as _platform_compat.py; it also names loggers.py even though loggers is a directory. These are active code paths—main.py directly imports _platform_compat, hub, picker, and auth, while routes import the other omitted packages—so a PR can use a Python 3.12+ stdlib API in any of them and pass this new floor check. With the 3.10 PR leg removed, that incompatibility is then discovered only after merge. Build the targets by scanning the backend tree and excluding only tests/vendor/cache directories instead of allowlisting selected modules.

Useful? React with 👍 / 👎.

Correct, and this was the worst possible shape for that lint: it looked like coverage while missing most of the tree, at exactly the moment it became the only thing checking the floor before a merge. Counted it -- 116 files, not far off your 115 -- and loggers.py matching nothing because loggers is a directory is the detail that shows the list was never verified against the tree.

Fixed in 2e210c1. It scans studio/backend and excludes only tests and vendored code, taking it from 307 files to 422. Verified rather than asserted: an itertools.batched call, which is 3.12, put into each of hub, auth, picker, state, storage, models, plugins and _platform_compat.py in turn. All eight are caught now; none of them was before.

Widening it immediately found something real, which I think is the strongest argument for your point: locale.getencoding is 3.11 and the floor is 3.10. It turns out to be correctly guarded, in a try/except AttributeError whose fallback is locale.getpreferredencoding(False), commented Python < 3.11. vermin reads names rather than control flow, so it cannot tell a guarded attribute lookup from an unguarded one. That single file is exempt with its reason printed on every run, and an exemption naming a path that no longer exists fails the lint, so it cannot outlive the guard it was written for.

The new guard test counts what the lint would hand to vermin against what is on disk, so narrowing the input back to a package list fails rather than quietly shrinking coverage. Reverting it to core only fails that test.

Run the test that protects this lint step

If a PR edits only workflow-trigger-lint.yml and removes this step, the floor check disappears without failing CI: Backend CI's path filter includes only its own workflow file, and this workflow runs three other guard tests but not test_backend_ci_matrix.py::test_the_floor_is_linted_on_every_pull_request. Therefore the newly added assertion that this invocation remains present is never collected for the exact workflow-only change it is meant to reject; invoke that guard from this unfiltered workflow as is already done for the adjacent workflow guards.

Useful? React with 👍 / 👎.

Right, and this is the third time this repo's paths filters have hidden a guard from the change it exists to reject. Backend CI's paths cover its own YAML and studio/**, not .github/workflows/**, so a pull request editing only workflow-trigger-lint.yml could delete the floor lint step and nothing would collect the assertion protecting it.

It runs from that unfiltered workflow now, next to the three guards already there for the same reason. Fixed in the same commit.

Keep guarded files in the Vermin scan

When a PR adds an unguarded post-3.10 API anywhere else in state_store.py, this predicate omits the entire file and the new floor lint passes even though the PR runs only Python 3.13. GUARDED documents only the single protected locale.getencoding() call, so excluding at file granularity creates a permanent unrestricted hole, and the coverage test explicitly permits it. The fresh evidence beyond the earlier allowlist issue is this new whole-file exclusion; suppress or sanitize only the known guarded occurrence while continuing to scan the rest of the module.

Useful? React with 👍 / 👎.

Correct, and it is the same mistake as the package allowlist one level down: I replaced a too-narrow input with a too-broad exemption. A new unguarded 3.12 call anywhere else in that module would have passed, on a pull request that runs only 3.13.

Fixed in 5d1ec33 by suppressing the call rather than the file. vermin honours a # novermin annotation, so comment parsing is on now and the single guarded call carries it with a note that the except below IS the guard and that vermin reads names rather than control flow. The file is back in the scan -- 422 files again rather than 421 -- and I checked your exact scenario: an unguarded itertools.batched call added elsewhere in state_store.py now fails the lint.

The coverage test no longer permits any file-level exemption at all, rather than permitting a recorded one, so reintroducing the exclusion fails it.

Include exercised CLI modules in the floor scan

A pull request touching unsloth_cli/** previously ran the backend suite on Python 3.10, and collected tests such as test_cli_mlx_trainer_activates_before_importing_trainer, whose subprocess imports and exercises unsloth_cli.commands.train. The replacement lint scans only studio/backend, so introducing a post-3.10 stdlib API on that CLI path now passes both the 3.13 PR leg and this lint, only failing the restored 3.10 run after merge. Include the shipped CLI modules exercised by this matrix in the Vermin targets.

Useful? React with 👍 / 👎.

Correct, and I checked the mechanism rather than the claim: studio-backend-ci lists unsloth_cli/** in its own paths filter and runs pytest unsloth_cli/tests as a step on every leg, so the 3.10 leg this replaces was executing shipped CLI code on the floor interpreter. Aiming the lint at studio/backend alone covers part of what was removed while reading like it covers all of it, which is the package-allowlist shape from the earlier round one level up.

Fixed in 375b6db. ROOTS is both trees and targets() walks each, 441 files rather than 422, still clean at 3.10. The guard asserts on what the lint would actually hand to vermin rather than on its source text, and dropping unsloth_cli back out fails it.

Scan matrix-run backend tests at the floor

When a PR uses a Python 3.11+ API such as tomllib anywhere under studio/backend/tests, this exclusion removes the file from the Vermin targets. However, the pytest matrix job runs python -m pytest tests/ from studio/backend on every matrix leg; after this change the PR's only leg is 3.13, so both it and the floor lint pass, while the 3.10 run fails only after merge. Test code must also execute on the matrix floor even though it is not shipped, so include these matrix-run tests in the scan or lint them separately.

Useful? React with 👍 / 👎.

Correct, and my exclusion comment had the wrong reason written into it: it said tests are not shipped, when shipping is not the question and execution is. pytest tests/ runs from studio/backend on every leg, so a 3.11 API in a test file is executed by the 3.10 leg exactly as one in a shipped module is, and with the pull request down to a single 3.13 leg both it and the lint would pass while main took the failure.

Fixed in 935af05. Only vendored code is excluded now, 1093 files rather than 441, and both test trees are already clean at 3.10, so this closes the hole at no cost today. Putting tests back into EXCLUDE_PARTS fails the new guard.

Restore the older interpreter legs on main

When code breaks a supported 3.10–3.12 runtime path without using a newer stdlib name—for example one of the explicitly listed sys.version_info branches—the Vermin scan passes, and this literal matrix also applies to push, so the break is never exercised after merge either. The fresh evidence beyond the earlier comments, which assumed failures would surface on a restored 3.10 main run, is that the final workflow now runs only 3.13 “on pull requests and on main alike”; retain the reduced PR matrix if desired, but restore the older legs for pushes to main.

Useful? React with 👍 / 👎.

Right that a break in an older runtime path using no newer stdlib name would have been executed nowhere, so I counted the branches rather than argue about the size of the hole.

Seven backend files carry a sys.version_info comparison, at 3.10, 3.12 and 3.14. The 3.10 ones were never straddled even by the old matrix, whose oldest leg WAS 3.10, so every leg took the same side of them and dropping legs loses nothing there. 3.14 is above every leg there has ever been. What a 3.13-only matrix genuinely stops executing is the pre-3.12 side of three files.

Rather than restore the legs, that side keeps a leg of its own: 3.11, the newest version that still takes it, running those three files and nothing else. 57 tests in under seven seconds, on both pull requests and pushes, beside the full leg rather than in front of it. The four full duplicate suites stay gone, which is the point of the change, and the branch coverage you are defending is back. In 8ac4452, with a guard that fails if that leg disappears or is moved to a version on the >= 3.12 side.

Assert that the sole leg is the actual ceiling

If a later workflow edit changes the only leg from 3.13 to 3.11 or 3.12, this guard still passes because those versions are merely greater than the 3.10 floor, even though the test is specifically intended to preserve the newest-interpreter coverage for removals and deprecations. Assert the known ceiling (currently 3.13), rather than only asserting that the leg is above the floor.

Useful? React with 👍 / 👎.

Correct, and the gap is exactly the one that matters: 3.11 and 3.12 are both above the floor while giving up the removals-and-deprecations coverage that is the entire reason the single leg is the newest one. Fixed in 8ac4452 by writing the ceiling down and comparing by name, so moving it is a decision made and defended in the same change rather than something that follows silently from an edit elsewhere. Pointing the full leg at 3.12 now fails the guard.