_resolved_key includes extras, causing re-entrant bootstrap failure

[LalatenduMohanty]

_resolved_key includes extras, causing re-entrant bootstrap failure when same package is encountered with different extras

Problem

_resolved_key() in bootstrapper.py includes req.extras in the seen-check key, so setuptools-scm and setuptools-scm[toml] are treated as different packages for duplicate/cycle detection. This causes a re-entrant bootstrap failure when the same package appears in the dependency tree with and without extras.

Failure chain

maturin
 └─ setuptools-rust (build-system)
     └─ setuptools_scm (build-system, no extras)     ← marked as seen
         └─ vcs-versioning (build-system)             ← wheel not yet built
             └─ hatchling (build-system)
                 └─ pluggy (build-backend)
                     └─ setuptools-scm[toml] (build-system)  ← NOT seen (extras differ)
                         └─ build_env.install(vcs-versioning) ← FAILS: wheel not on server

The second encounter with setuptools-scm[toml] bypasses the _has_been_seen check and tries to install vcs-versioning into its build environment — but vcs-versioning hasn't been built yet because we're still inside the recursive call stack of the first setuptools-scm bootstrap.

Root cause

_resolved_key() at bootstrapper.py:1287-1295:

def _resolved_key(self, req, version, typ):
    return (
        canonicalize_name(req.name),
        tuple(sorted(req.extras)),  # ← extras should not be here
        str(version),
        typ,
    )

Extras affect which install dependencies are selected, not the wheel build. _add_to_build_order() already correctly ignores extras (uses name + version only).

Why now?

setuptools-scm 10.0.2 (released 2026-03-25) added vcs-versioning as a build-system requirement. vcs-versioning uses hatchling, which depends on pluggy, which depends on setuptools-scm[toml] — creating the re-entrant loop that exposes this bug.

The _resolved_key extras bug has always been latent — this is the first time a real-world dependency graph triggers the same package with different extras during a single bootstrap.

Currently worked around by pinning setuptools-scm<10 in e2e/constraints.txt (#982, #983).

Proposed fix

Remove extras from _resolved_key. A wheel build is the same regardless of extras — they only influence install dependency resolution.

[LalatenduMohanty]

This alone wont fix the issue of circular dependency which setuptools-scm 10.0.2 introduced pypa/setuptools-scm#1302

[LalatenduMohanty]

As @dhellmann mentioned #985 (comment) this is as designed.