Explore opt-out and include-by-default extras

[ghost]

Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)

---

In sqlalchemy-77 and other use cases, I've encountered a situation where extras as simple opt-in dependencies are inadequate.

In particular, the deprecation of Feature, which does provide opt-in and opt-opt, quickly exposes the need for opt-out, especially when the apparent most common use case for Features is to include C extensions. In this case, the preferred default installation is to include the C extensions but to exclude them in exceptional cases.

Since the 'extras' feature does not enable opt-opt, it means that the use of extras to define the preferred dependency list is not possible. The package must define the bare minimum dependencies and then all other dependencies are extras.

I believe what is needed is a way to define dependencies to be included and excluded dependencies, perhaps with a default inclusion list. This description would be more complex than the current list of extras and would have an impact on metadata formats (as the package metadata would necessarily need to incorporate these aspects).

However, if this were implemented, it would allow projects like SQLAlchemy, MarkupSafe, CFFI, and PyMongo to easily declare preferred but optional dependencies. If implemented as dependencies, as extras are, it would further allow these artifacts to be resolved at run time, by the installer, rather than at build time, as Features require. Doing so would allow these aspects to be decoupled from the build process and greatly simplify the setup.py aspects of these projects - moving toward a more declarative packaging system.

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/163

[peterbrittain]

I've hit a similar situation on my project and have been thinking about how to solve this without going for a full blown opt out policy (given that nothing has happened in 3 years on this issue)...

Would it be acceptable to provide a default set of extras if none are specified by the user (or in the dependency from another package)? That way, developers could specify recommended combinations if the user has no preference, but it still leaves the existing function working exactly as it does today. I think this solves all the existing use cases I've seen without getting into more complex opt-out logic (which is presumably what has held this up).

I'd be happy to try to code this alternative up if it was an acceptable middle ground between Features and extras...

[peterbrittain]

Looks like someone else has suggested defaults for another use case - see #1139