Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore opt-out and include-by-default extras #163

Open
ghost opened this issue Mar 10, 2014 · 2 comments
Open

Explore opt-out and include-by-default extras #163

ghost opened this issue Mar 10, 2014 · 2 comments
Labels
critical enhancement Needs Triage

Comments

@ghost
Copy link

@ghost ghost commented Mar 10, 2014

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.


@peterbrittain
Copy link

@peterbrittain peterbrittain commented Oct 6, 2017

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
Copy link

@peterbrittain peterbrittain commented Oct 17, 2017

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

@pganssle pganssle added the Needs Triage label Oct 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical enhancement Needs Triage
Projects
None yet
Development

No branches or pull requests

2 participants