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

Conda environments don't follow the protocols that virtualenv/venv do (setting sys.prefix to the virtualenv and sys.base_prefix to the prefix of the underlying system installation). #9788

Closed
hongyi-zhao opened this issue Mar 26, 2020 · 7 comments
Labels
locked [bot] locked due to inactivity pending::discussion contains some ongoing discussion that needs to be resolved prior to proceeding source::community catch-all for issues filed by community members stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity

Comments

@hongyi-zhao
Copy link

Hi,

See the discussion here. Could you guys please let conda follow the protocols that virtualenv/venv do?

Regards

@mingwandroid
Copy link
Contributor

Conda isn't designed in this way.

Conda environments are deliberately isolated from each other. Conda is a package manager for multiple languages so this pythonism doesn't fit well with it.

This is unlikely to change because of the following considerations.

Attempting to ape python venvs in conda would make conda much worse and would only be achievable with some egregious hacks.

My opinion of virtual environments, from an ecosystem design perspective (which informs my work on conda) , at a high level, is that it should not be possible to escape the encapsulation of each environment and this prefix distinction does just that. I cannot think of a good reason to allow such leakage and would love to hear of some (honestly I would!)

You should be able to use the python stdlib's venv module though just fine with conda to get the behavior you are after. You can create venvs in any conda environment you wish and those will follow the virtualenv modus operandi.

It's not correct to think of conda environments as equivalent to venvs. You cannot install an R interpreter (in any useful way) into a python venv, for example.

@kalefranz
Copy link
Contributor

Extensive related discussion at #7173

@kalefranz
Copy link
Contributor

xref: #5861

@kalefranz kalefranz added source::community catch-all for issues filed by community members pending::discussion contains some ongoing discussion that needs to be resolved prior to proceeding labels Apr 28, 2020
@pradyunsg
Copy link

I'm pretty sure that this can be closed.

@hongyi-zhao
Copy link
Author

hongyi-zhao commented Aug 31, 2021

What's the solution now?

@pradyunsg
Copy link

pradyunsg commented Aug 31, 2021

Solution to which problem?

This issue seems to be asking that conda environments behave like Python virtualenvs -- which is not a correct model for the abstraction. Conda is a "separate software distribution ecosystem" from the perspective of https://packaging.python.org/overview/, and it shouldn't behave like Python virtualenvs (https://packaging.python.org/overview/#virtualenv).

@github-actions
Copy link

github-actions bot commented Sep 1, 2022

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

  1. Verify that you can still reproduce the issue at hand
  2. Comment that the issue is still reproducible and include:
    - What OS and version you reproduced the issue on
    - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

@github-actions github-actions bot added the stale [bot] marked as stale due to inactivity label Sep 1, 2022
@github-actions github-actions bot added the stale::closed [bot] closed after being marked as stale label Oct 1, 2022
@github-actions github-actions bot closed this as completed Oct 1, 2022
@github-actions github-actions bot added the locked [bot] locked due to inactivity label Oct 1, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 1, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity pending::discussion contains some ongoing discussion that needs to be resolved prior to proceeding source::community catch-all for issues filed by community members stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity
Projects
None yet
Development

No branches or pull requests

4 participants