I didn’t bother to provide my example because I’m still mulling whether or not or when I’d actually use this, and it’s tangled up with pre-commit (which has its own issues), but I do have such a case. I have to wait for support in pip to be more or less universal to pull it off, which I think is a common problem for “making hard dependencies into parts of the default extra”.
For check-jsonschema, one of my primary targets is usage under pre-commit. Pre-commit doesn’t have a mechanism[1] which lets me default select extras for my package, except by creating a new and separate project to serve the hooks, as a wrapper over the original. If I were doing things over from scratch, I’d split the project, but it’s too disruptive for me to justify at this point.
Because almost all of the builtin hooks target YAML files, I’m including a YAML parser by default. That means that even if you just want to use check-jsonschema on, you know, JSON, seeing as the tool is for JSON Schema, not “YAML Schema”, you need to install a YAML parser. That’s silly.
I would like to make the YAML parser optional, but without removing it from the install experience provided to pre-commit users or naive pipx install check-jsonschema users or homebrew users (should brew include the default or not?), etc.
I’d also like to move the vendored schemas provided by check-jsonschema – necessary for those pre-commit hook users – into a separate data package which gets picked up by default. So although I’d be “adding a package” in that case, it’s for the purpose of making it possible to build a slimmer install.
I could even make the requirement for regress (Rust-backed ECMAScript regex engine) into a soft dependency with more work, making for an even more minimal install.
All that is to say: I made some imperfect decisions 3 or 4 years ago, and default extras might give me a low impact way of making the core of my package smaller without negatively impacting users.
Okay; there’s my example. Does that mean that you’re wrong, that adding default extras won’t lead to bloat? No. I really don’t know. I’m actually concerned about exactly what you point at, that many of these cases seem to be taking things which are optional and including them by default. But I think it’s notable that you can only consider moving things around like this once support for default extras is nearly universal, so anyone wanting to make such moves would necessarily be a late adopter.
As a separate matter, I don’t think matrix testing is directly pertinent here? That’s already a massive and frequently underestimated problem in terms of compatibility. I frequently see projects missing testing of their lower bounds for dependencies, the full matrix of extras (or a significant chunk of it), all supported Python versions, or all supported platforms. The PEP could hardly make this worse if it wanted, but it’s not materially impacted by the addition of default extras, is it?
As far as I know. Someone can correct me if I’m wrong. ↩︎