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
miniconda3 py2.7 env picks up packages outside env #8770
Comments
IMHO this is not what the purpose of conda should be. |
That is a use case, yes. It is not conda's purpose, though. I have been bitten badly by this issue many times before. I don't like this feature of python. Still, it is a feature, and we can't capriciously remove features from upstream. |
@mingwandroid @msarahan I understood that you don't want to change this behaviour, that's why I closed the ticket. However from the amount of tickets related to this it seems that many people expect a different behaviour. You should also be aware that this causes unwanted side effects. In my case for example, I told conda explicitly to install numpy 1.16.4 and |
Oh yes, we understand. We find this behavior unintuitive as well, but you have to understand that this isn't our decision. The greater Python community specified this behavior in pep 370: https://www.python.org/dev/peps/pep-0370/ If we get rid of that, we are seen as a non standard python distribution and get flak for it. What you describe as a side effect is the intent of pep370. Conda is correctly installing numpy for you, but the version you already have in your user site packages folder gets found first. Remember, conda is not the same thing as python. Just because a conda package is installed doesn't mean python won't find a different thing earlier in its search path. We could perhaps make a package, say "safe-mode" that would set all the env vars such that python would strictly use only software from the conda env, but we can't disable pep370 behavior by default. |
@msarahan I'm pretty sure that conda did NOT correctly install numpy in the specified version. It was not in the site-packages directory of the environment. In |
That's fun. If it's missing from the env site packages dir, that's a bigger problem. Can you zip up the conda-meta folder from your env and upload it here? |
All the testing I did must have confused me. Actually it is the other way around. Conda installed numpy in the proper version, but in |
No problem. Always glad when there's not a terrible conda issue to try to figure out. |
@msarahan I beg to disagree that implementing in conda a way to disable Python adding user site to Meanwhile I would like to provide a workaround which works for me, using Bash under Linux, and with conda configured not to activate the $ conda config --set auto_activate_base false Create an alias for alias conda='export PYTHONNOUSERSITE=1; conda' This will set and export the To verify that the workaround is working, run: $ exec $SHELL
$ conda activate
$ python -m site which on my system outputs:
|
Yes, and you should set it whenever you need it. I don't believe that conda should do anything like that though. Your Alias approach is what I would recommend but I would call it something other than conda! Something like conda-nolocal |
Thanks for the tip, I will rename the alias. |
I'm not convinced that conda should not do this. I understand the logic to say that conda should not mess with "standard" python behavior, but there is an argument to say that standard python behave is, in fact, otherwise: Admittedly, I am relatively new to conda: I tend to think of conda environments somewhat similar to python virtual environments, at least conda environments other than "(base)". Please correct me if this is incorrect thinking (as my entire argument below is based on this view). When I create a python virtual environment, it uses python from that virtual environment, and similarly it only uses python packages installed in that virtual environment. When I activate a conda environment, it clearly uses the version of python installed under miniconda and not the python that was installed on my system prior to my installing miniconda. Therefore I would expect that it would also only use the python packages installed (at least) under miniconda (if not only those installed in the particular conda environment). That's my argument for this. At the very least it would be nice if this was part of the conda configuration, so that one can configure whether a conda environment will include previously installed python and/or python packages. (And, imho, the default configuration should be that a conda environment is isolated). The alias workaround is a good workaround! (Thanks Alain). However, personally my preference is to avoid aliasing commands, unless absolutely necessary, since it is not uncommon for me, from day to day, to find myself working on a number of different machines (owned by various organizations) with various environments, and then I have to remember that something may not be working because a command is aliased on one machine but not another. That's my two cents. You get what you pay for ;-) Thoughts? Comments? |
Hi there, thank you for your contribution to Conda! This issue has been automatically locked since it has not had recent activity after it was closed. Please open a new issue if needed. |
Current Behavior
When I create a conda environment with python 2.7, the python installation picks up packages that I installed with the system python 2.7 before using conda (e.g. with
pip install --user
in my home directory).Steps to Reproduce
Note the
/home/users/sdiehl/.local/lib/python2.7/site-packages
path which should not be there.Expected Behavior
The purpose of conda should be to isolate the environment from any previously installed packages either in the user's home or system-wide.
Environment Information
`conda info`
`conda config --show-sources`
`conda list --show-channel-urls`
The text was updated successfully, but these errors were encountered: