Explore opt-out and include-by-default extras

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

Review the current extras and Feature behavior described in the issue, along with how setup.py expresses dependencies and how package metadata represents them. Define the opt-out and include-by-default semantics, then determine the metadata and dependency-resolution changes needed before implementation.