Creating a 'venv' virtual environment fails when it is unable to find Python. #10822
Comments
|
This functionality was working in both command prompts and conda prompts earlier today. After updating using This functionality continued to fail after uninstalling and reinstalling using the latest installer for Anaconda 3 on 32-bit Windows. This functionality was restored after uninstalling version 2019.03 and then installing version 2018.12 and again works in both command prompts and conda prompts. |
|
I encountered the same problem. I have to reinstall the version 2018.12.Otherwise, I am not about to create the virtual environment with the 'venv' command. |
|
I'm having the same problem with creating venv environments in PyCharm Community 2019 on a 64-bit install of both PyCharm and Anaconda, the full PyCharm traceback is: |
|
Thanks for the report. We believe this may be a problem with our venv/virtualenv packages. We will investigate as soon as we are able. |
|
In the meantime, you might want to try creating conda environments. There's a tab on the left side to choose. |
|
Conda environments work for 2019 64 bit but jupyter notebooks don't work for conda just venv. |
AFAIK this is not the case, what makes you say so? |
|
Thanks for the report. This should be fixed now. If you can help test [*] via:
.. we'd appreciate it. [*] this package was built securely and is a release candidate if that placates any security concerns. |
|
I have performed a quick test following the steps detailed in the original
issue, and I can confirm that the implemented solution has resolved the
issue that I was experiencing.
Thank you for your quick response to this issue!
Regards,
Tim
…On Wed, Apr 24, 2019, 5:14 PM Ray Donnelly ***@***.***> wrote:
Thanks for the report. This should be fixed now. If you can help test [*]
via:
conda update -c c3i_test2 python
.. we'd appreciate it.
[*] this package was built securely and is a release candidate if that
placates any security concerns.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#10822 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AECXRDNQDDABLTC6YSP3FZLPSDETTANCNFSM4HFLOYYQ>
.
|
|
I have the same problem while creating project interpreter (ie. virtual environment) via Pycharm Community Edition 2019.1.1. The command output is the same as given a few answers above by brendano257 ( I did
Could we hope for making it work? :( |
You should use |
|
Thanks for a quick response. Now, however, I get:
(running Pycharm as administrator doesn't help) |
|
I am hitting this issue with |
|
I tested the fix on 32-bit anaconda 3, using the command The fix worked well for me. I was able to create, activate, and update a virtual environment using |
|
Hmm, I'm on 64-bit. Maybe that's the difference? |
Do not use c3i_test2, the packages are available in defaults. |
|
I'm also seeing this issue on 64-bit conda 4.6.14. I've tried updating as per suggestions above, but no luck. |
|
Agreed with Chris. On 64-bit, |
|
Sorry, I cannot reproduce this. Can someone still having trouble (after We want to see in there: If you verify that is the version you have installed then please retry |
|
Thanks, mingwandroid. I followed your advice and it has unblocked me for the time being. It did lead to a concerning side-effect, however. I had python In any case it does do the job. I now have python However, the DOWNGRADE is a little alarming, and a I'm glad that my |
|
anaconda is a metapackage, representing a pinned state. That it changes to custom is of no concern - it just means that it's not the tested configuration that we released. Since anyone can change any package, it's impossible to test every possible combination. You can actually remove the anaconda metapackage with no consequence. It served its purpose in providing you with your initial set of packages. Removing it will allow |
|
@msarahan You're right of course. Thanks. I did |
|
Hi I am facing this issue while creating virtual environment using venv. python -m venv venv_name Error: [Errno 2] No such file or directory: 'C:\ProgramData\Anaconda3\lib\venv\scripts\nt\python.exe' My python and conda versons are Python 3.7.3 and conda 4.6.11 respectively. What is the solution to this? Some are suggesting to use 'conda update python'. I believe this command will upgrade my python to higher version. What if I wish to stick to the same version of python but need this issue fixed. Is this possible please? |
|
You are not using the latest python nor conda versions. Issues with venv were fixed in more recent versions. You need to simply update your software. Another thing you may want to take care about is to use only "The Anaconda Prompt", or to activate your base env correctly. I tested with Python 3.7.4 and 4.7.12 and the following worked fine: |
|
The venv fix is only in later python version and builds. Why don't you want to update python here? Conda will not update from 3.7 to 3.8 without you explicitly requesting that. |
|
If you use the anaconda prompt then yes activation is done for you already. I wanted the instructions to be as general as possible though and double activation is not a problem. |
|
Ok thanks - please can you confirm that the root cause of the issue is the python version and not the anaconda version? If that is the case, then why does venv work when I use the same python version without anaconda? Probably there is some conflict between anaconda and python? |
|
I have not checked the exact package versions but for the third time, yes this is the case) the bug was in our python builds and I personally fixed it a long time ago. Our python builds (and the builds from most other distributions) contain many changes from the official releases and sometimes those changes cause bugs. That's what happened here. If you report a bug against old software versions and/or builds, it is ideal if you can test with the latest versions and report on the results in the bug report. People sometimes think sticking to an exact python build is necessary when it really isn't and isn't in general advisable. CVE fixes are not always backported to old versions and when they are backported they still require a new build of that python minor version and for the end user to update to that version in order for the safeguards to take affect. Why do you think sticking to 3.7.3 is important. I should also note that you didn't give the build number so I wouldn't be able to tell you whether your installed python version has this bug or not. That info is given by conda list. |
|
@mingwandroid - its python 3.7.3 - h8c8aaf0_0 |
|
@tcrory Following steps worked for me:
Hit +1 if it worked for anyone else. PS: Yes I did try all the methods mentioned above by others and nothing worked for me. |
|
I just got the error message with Python 3.8. and the current anaconda version. However, the command Conda info: |
|
@jpdus Try this:
Hope it works 👍 |
|
Thanks, solved it by downgrading virtualenv to 20.0.33 . |
|
@basavarajsh98 Thanks it works !! |
I had the same problem, and this worked. Thanks a lot! |
This was the easiest fix, which worked for me. Solution involving copying python.exe files did not. Context: conda 4.9.2, Python 3.7.9, creating a venv by using pre-commit |
|
Thank you!(from Japan) |
|
Should this issue be reopened? Experiencing same issue when running tox. Can workaround by copying python executables or downgrading virtualenv however both are just workarounds and do not necessarily fix broken Conda + virtualenv. I think there's some assumptions here that require a test for presence of python.exe and fallback mechanism, or some changes to creation of the conda environment process to match updated expectations on Windows. Does an issue need to be opened in virtualenv project? It was introduced here in virtualenv 20.0.34. Possible source: @classmethod
def _executables(cls, interpreter):
system_exe = Path(interpreter.system_executable)
if cls.venv_37p(interpreter):
# starting with CPython 3.7 Windows ships with a venvlauncher.exe that avoids the need for dll/pyd copies
launcher = Path(interpreter.system_stdlib) / "venv" / "scripts" / "nt" / "python.exe"
executables = cls._win_executables(launcher, interpreter, RefWhen.COPY)
executables = chain(executables, cls._win_executables(system_exe, interpreter, RefWhen.SYMLINK))
else:
executables = cls._win_executables(system_exe, interpreter, RefWhen.ANY)
for src, targets, must, when in executables:
yield src, targets, must, whenThe workaround I used was to open an administrator command prompt and setup symlinks. set envname=myenv
mklink c:\tools\anaconda3\envs\%envname%\lib\venv\scripts\nt\python.exe c:\tools\anaconda3\envs\%envname%\python.exe
mklink c:\tools\anaconda3\envs\%envname%\lib\venv\scripts\nt\pythonw.exe c:\tools\anaconda3\envs\%envname%\pythonw.exe |
Same issue here, from multiple of my collogues. It just started popping up in the last few days, which leads me to suspect it could be something with the most recent virtualenv release. We've been able to resolve it by pinning virtualenv to 20.0.8. |
|
Same - with a fresh install of miniconda from earlier today (Windows x64, conda version 4.9.2, python 3.8.5), I'm unable to get pipenv to generate an environment: |
|
Same happens to me with a fresh install of miniconda in conjunction with pyenv. I described my output in the issue linked above. None of the proposed steps here is working for me. |
|
@msarahan, @mingwandroid it looks like there is still an issue when a command automated with tox (running in a conda environment on windows) internally relies on The use case is: the dev uses conda to create a environment and attempts to automate common tasks with Should I create a separated issue for that? |
|
I'm experiencing the same issue as @abravalheri |
and others
Actual Behavior
When attempting to create a virtual environment using the command
python -m venv env, the creation of the virtual environment will fail when venv is unable to find python. When this occurs, it throws an "Errno 2" and reports a problem with the following path:%LOCALAPPDATA%\Continuum\anaconda3\Lib\venv\scripts\nt\python.exeExpected Behavior
Python should be able to successfully create a virtual environment using the venv module without any errors.
Steps to Reproduce
python -m venv envAnaconda or Miniconda version:
Anaconda3-2019.03-Windows-x86.exe
Operating System:
conda infoconda list --show-channel-urlsThe text was updated successfully, but these errors were encountered: