• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

Background

I am working on a project called data-diff (https://github.com/datafold/data-diff), which supports a lot of optional 3rd party libraries, mostly connectors to different databases. We provide them as "extras", so that users can install them easily if they wish. For example, they might run pip install data-diff[mysql, snowflake, bigquery].

For the most part, these libraries play nice with each other, except that sometimes they don't. For example, adding the databricks connector (https://github.com/databricks/databricks-sql-python) is somehow causing a conflict with snowflake on numpy/pandas/etc., which can only be resolved, if at all, by taking all these libraries years back, which is bad for both features and security.

This kind of conflict resolution really isn't necessary for our use case, because it's very unlikely for someone to install both databricks and snowflake, and even when they do, we would much prefer to give them a special error message, over the alternative which is removing databricks from "extras" entirely.

It would be great if poetry offered some solution to this situation, where extras conflict, but don't have to co-exist.

Request (simple)

One way to do it would be to add an option to make some extras exclusive of one another, so they can't be installed together, but also don't affect each other's dependencies.

Maybe add the option to make dependency groups exclusive. Anything within a groups can be installed together, but deps from separate groups cannot.

Request (ideal)

What I really want in this situation, is to be able to install dependencies in their own "virtual env", so that when they import their dependencies, they import them from their own private cache.

That would allow all these 3rd party libraries to play nice with each other, no matter what.

This might be beyond the scope of poetry, in more ways than one. But I also think it could be useful for a lot of other scenarios..