People do frequently ask for several related things:
- “Default extras”: an extra that is overridden by the presence of other extras
- “Dependency groups” where your requirements can be satisfied by multiple sets of requirements (e.g. “Needs a database, if it’s postgres I need X, Y and Z, if it’s redis I need A and B, etc”)
- Build-time feature flags (e.g. “give me X but built against MKL”)
- Enhancing dependencies (i.e. “Recommends:”) — for example, when you have a fast and a slow version of your library where the slow version is harder to distribute / build.
- “Negative extras” - either an extra that is included by default but can be explicitly removed, or an extra that removes a dependency (this is another flavor of “enhancing dependencies” — your library comes with all the features it supports, and your users can declare a partial dependency on your library if they don’t use certain features).
I think these are all closely related and the use cases for each one gets jumbled up with all the others, because each mechanism lets you satisfy a few of the use cases from the others. For example, “default extras” lets you implement a single “dependency group”. “Feature flags” can often be implemented in terms of various extra-related logic by refactoring your application into a “core” with all the flag defaults, and then putting each additional feature into a separate package.
I agree with @njs’s suggestion that we look closely at the use cases here, because we may find that if we implement say #2 and #4, it would most closely satisfy the needs of everyone asking for #1, #3 and #5.