I’ve made a draft PR at feat: support PEP 771 by henryiii · Pull Request #226 · pypa/pyproject-metadata · GitHub. That would allow scikit-build-core, meson-python, and pdm-backend to try it out.
I think it would be good to ensure that developers understand that default-extras are not less “weighty” than a normal dependency; most users will be getting them, and dependencies of dependencies can’t opt out easily, so it’s not intended to add dependencies you think many users won’t need. It’s a way to allow opting out for certain cases (or to pick between backends, etc). This could be both mentioned in the PEP, and be part of the eventual update to the packaging guide. The pytest example is a good one, maybe something like that could be included.
I wonder if listing a larger collection of examples of packages that plan to use the feature would help? build will build packages over a second faster by default, with fewer crashes, for example. And build will also get better for bootstrapping in the long run.
Also, the prevalence of pipx run and uvx combined with Wasm might be a reason we are seeing more need for this now, as these tools are much nicer if you can jus type the package name, but Wasm really cares about minimal dependencies in webpages and you don’t need things like click or rich on Wasm, there’s no CLI. repo-review and validate-pyproject both would really benefit from this.
If [] is added (a fork of pip was just used to show this to be possible a day or two ago), then [typo] should be identical to []. I think that also makes this feature simpler: x is shorthand for x[default-feaures], and including the brackets means you are listing the extras explicitly without defaults. Much easier to reason about and teach. It’s also nicely backward compatible, so if a adds a default extra, and b depends on a and doesn’t need the default extra, then b can explicitly depend on a[] and it will work on older versions of pip.
It might be worth mentioning that package can reexport default extras. You can depend on a[], reexport a’s extras, then re-export a’s default extra. I’d do that with sp-repo-review, which currently reports sp-repo-review[cli] -> repo-review[cli], with default extras it could do the same with defaults.
I think “MAY implement a user facing mechanism” to opt out sounds good. I’d say tools like pip and uv could wait to see if overuse of this features by packages that have dependencies becomes an actual problem before adding such a flag. In fact, uv’s override feature might be very easy to extend to allow it to override default extras too - in that case, there wouldn’t even be a new required flag.
From what I can tell, this isn’t really an issue with default features (otherwise, you could make a PR to remove the features in the packages that had the issue!), but just with lots of dependencies in general. Rust makes it very easy to use dependencies, and extra dependencies don’t affect the end user, but only compilation (for the most part), so having lots of dependencies is common. uv, for example, has over 110 direct dependences listed in its Cargo.toml. Unlike Python, Rust is not “batteries included”, and core things like Regex and AST parsing require dependencies. That’s not an indication that default features don’t work.
I’ll probably try to turn some of these suggestions into PRs toward the PEP.