mingwandroid
commented
5 years ago Why not use venv instead? It's built in to python.
Closed danyeaw closed 5 years ago
mingwandroid
commented
5 years ago Why not use venv instead? It's built in to python.
danyeaw
commented
5 years ago @mingwandroid I at least tried to do that with the second example above python3 -m venv venv
leducvin
commented
5 years ago I can confirm the same errors as reported by @danyeaw using either methods.
However, I found out that:
python3 -m venv --without-pip venv, the command exits without any errors, but the virtualenv is completely broken. Almost empty in fact. python.exe isn't even present in the Scripts directory.python3 -m virtualenv --no-setuptools --no-wheel --no-pip venv, the command also exits without any errors. At first glance the virtualenv seems OK. Once activated, if python is launched, it complains it cannot find libpython3.7m.dll.Don't know if this helps anyone. I'm not sure what to make of it.
zegervdv
commented
5 years ago I'm having the same problem and something similar trying to install a local python package using python setup.py install.
It seems to be a problem with (amongst others) the os.stat command:
>>> os.stat('/z/home/user')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
FileNotFoundError: [WinError 3] Path not found: '/z/home/user'I am running the command in python from that very directory, so it certainly exists.
danyeaw
commented
5 years ago Anyone in the know want to point us in the right direction to fix this please.
Alexpux
commented
5 years ago Native Windows programs don’t understand UNIX paths, so no one MINGW builded program will work with UNIX paths
danyeaw
commented
5 years ago Virtualenv seems to be using Windows paths, so I'm not sure that is at least the issue that I was seeing.
zegervdv
commented
5 years ago No indeed, tried it from the CMD prompt and it still fails with the same error for venv.
I still find it weird that python setup.py install tries to use UNIX paths on Windows though. Or is python confused because I'm running it from bash?
zegervdv
commented
5 years ago No, even from the Windows CMD it still gives me the same error and it's using a UNIX path:
File "C:/msys64/mingw64/lib/python3.7\genericpath.py", line 96, in samefile
s1 = os.stat(f1)
FileNotFoundError: [WinError 3] The system cannon find the path specified: '/home/user/test'The error is similar enough to what virtualenv is throwing, so even though it is printing Windows style paths in the terminal, it still seems to be using UNIX paths internally.
octabode
commented
5 years ago It looks like you might have renamed your python.exe executable to python3.exe? I got this same error after following install instructions that had me rename python.exe to be version specific. I renamed it back and python -m venv venv worked fine.
danyeaw
commented
5 years ago @octabode python3.exe is the executable for Python 3 in mingw. It may be possible that python2.7 virtualenv's work, I don't know. All my python development is with Python 3.
norstbox
commented
5 years ago This is a showstopper for Python 3 development on MSYS2, because venv is an essential part of it. Tools like pipsi and pipenv depends on venv.
From venv docs.python.org:
Changed in version 3.7.2: Windows now uses redirector scripts for python[w].exe instead of copying the actual binaries.
Can this be the cause of the problem?
FlyingWombat
commented
5 years ago Any update on this? I can confirm this is still a problem:
$ which python3
/mingw64/bin/python3
$ pacman -Qi mingw-w64-x86_64-python3 msys2-runtime bash
mingw-w64-x86_64-python3 3.7.3-4
msys2-runtime 3.0.7-1
bash 4.4.023-1
$ python3 -m venv .venv
Error: [WinError 2] The system connot find the file specified
deanmsands3
commented
5 years ago I was able to solve mine through a VERY convoluted process. Will post more when I get home from work. One of the biggest "simple" hurdles is telling venv to copy instead of symlink (The shutil library believes Windows should not be using symlinks). Off the top of my head, I think the other big hurdle was populating "C:\msys64\mingw64\lib\python3.7\venv\scripts\nt" similarly to a standard native Windows Python install (i.e. using the installer from python.org).
FlyingWombat
commented
5 years ago Oh, so it's library issues?
In the meanwhile, I've been just using the standard Python Installer by adding "/c/Program Files/Python37{/scripts}" to the top of my PATH. venv works fine, even in bash. I guess their build script would be a good place to get ideas to fix this.
Alexpux
commented
5 years ago @deanmsands3 @FlyingWombat @danyeaw try to apply patch from this commit https://github.com/msys2/MINGW-packages/commit/8aaa5f2d46444e8685f76c3d56b6800ae3c842a2
deanmsands3
commented
5 years ago Thanks, @Alexpux Let's give this a shot... Oh, right. I also had to manually copy over all the Python packages.
deanmsands3@sandbox MINGW64 /c/Workspaces/Python/env
$ python3 -m virtualenv mP3.7
Using base prefix 'C:/msys64/mingw64'
New python executable in C:/Workspaces/Python/env/mP3.7/bin/python3.exe
Also creating executable in C:/Workspaces/Python/env/mP3.7/bin/python.exe
Installing setuptools, pip, wheel...
Complete output from command C:/Workspaces/Python...P3.7/bin/python3.exe - setuptools pip wheel:
Traceback (most recent call last):
File "<stdin>", line 3, in <module>
ModuleNotFoundError: No module named 'pkgutil'
----------------------------------------
...Installing setuptools, pip, wheel...done.
Traceback (most recent call last):
File "C:/msys64/mingw64/lib/python3.7\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "C:/msys64/mingw64/lib/python3.7\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "C:/msys64/mingw64/lib/python3.7/site-packages\virtualenv.py", line 2472, in <module>
main()
File "C:/msys64/mingw64/lib/python3.7/site-packages\virtualenv.py", line 763, in main
symlink=options.symlink,
File "C:/msys64/mingw64/lib/python3.7/site-packages\virtualenv.py", line 1016, in create_environment
install_wheel(to_install, py_executable, search_dirs, download=download)
File "C:/msys64/mingw64/lib/python3.7/site-packages\virtualenv.py", line 969, in install_wheel
call_subprocess(cmd, show_stdout=False, extra_env=env, stdin=SCRIPT)
File "C:/msys64/mingw64/lib/python3.7/site-packages\virtualenv.py", line 855, in call_subprocess
raise OSError("Command {} failed with error code {}".format(cmd_desc, proc.returncode))
OSError: Command C:/Workspaces/Python...P3.7/bin/python3.exe - setuptools pip wheel failed with error code 1
Well seems need more changes for virtualenv. Feel free to do some investigation)
Alexpux
commented
5 years ago @danyeaw I have more changes but virtualenv.py contain blobs that also need to be changed
Alexpux
commented
5 years ago @danyeaw @deanmsands3 @FlyingWombat this is more fixes - https://github.com/msys2/MINGW-packages/commit/d583e5a01308503abc9fb5605ee7fb91fcbe7ab9
I can't do anything more here myself. Feel free to contribute more suolutions
Alexpux
commented
5 years ago Problem seems that python from venv not see modules from host python
danyeaw
commented
5 years ago I just tested this with the latest python3 x86_64 packages, and creating a virtualenv works perfect for me. Thanks @Alexpux for all your effort getting this going 🎉 . Are others still having issues? If not I think we can close this.
danyeaw
commented
5 years ago To be clear: Using the mingw64 shell still fails:
$ python3 -m venv venv
Error: [WinError 2] The system cannot find the file specifiedUsing the msys2 shell works using the same command.
Alexpux
commented
5 years ago When you use MSYS shell you use MSYS python, not MINGW one
danyeaw
commented
5 years ago Well it sounds like I was incorrect saying this is fixed then. I'll see what I can figure out as well.
spaceotter
commented
5 years ago I ran into this issue while trying to use pipenv. Note that there is now also an unrelated bug with python 3.7.4 and virtualenv: https://github.com/pypa/virtualenv/issues/1380 So even if you fixed this, the latest python3 in msys2 probably won't work.
danyeaw
commented
5 years ago Virtualenvs should be fully working using the python3 -m venv syntax. For everyone who also ran in to this issue, give the new package a spin. Pipenv may also work, I've tested Poetry which provides similar package management and it works great.
spaceotter
commented
5 years ago @danyeaw, thanks for working on this isssue.
I updated to mingw64 python 3.7.4-2 and reinstalled all the pacman python packages, including virtualenv 16.1.0-2, and I can make a virtualenv with python -m venv testvenv. I still get this error when using
virtualenv testvenv.
Pipenv looks busted too, same error. Maybe because it uses the virtualenv package instead of the built in venv.
The python.org Windows distribution works normally, so that's what I'm still using at the moment.
danyeaw
commented
5 years ago @spaceotter Using the virtualenv script is deprecated in Python 3.6+. I am planning on submitting another PR to remove the python3-virtualenv package entirely from mingw.
Which error are you getting with pipenv? Pipenv installs fine for me, and then I run across this bug in click: https://github.com/pallets/click/issues/1065 when I try to launch it.
The Windows distribution of Python will always be preferred for users who just want to use Python in Windows, because it is officially support by the Python core team. However, some of us are building cross platform tools and mingw64 is the only option to provide a Windows version.
spaceotter
commented
5 years ago I don't know how you're getting an error in click, that's not even installed in my system. The error is nearly identical to your original post: it can't find 'pkgutil' when creating the virtualenv and bails. If python3-virtualenv is going away, I guess I'll take the issue to the virtualenv repository.
Out of curiosity - what do you mean by cross platform tools? Are you redistributing parts of msys2?
danyeaw
commented
5 years ago @spaceotter Thanks for helping to test that virtualenv creation is fixed btw, I forgot to mention that in my previous post :smile:. As long as you are successfully able to create a virtualenv using the recommended way in Python, doesn't that suit your needs?
Click is a dependency of Pipenv, it is what Pipenv uses to create a nice CLI.
I am a core developer of Gaphor. In order to run and package the application for Windows, I have to build this GTK app using mingw's GCC for Windows, and then package it up with Python and all of dependencies so that I can provide a nice exe installer. There is no other way for me to build the app using the GTK and pycairo dependencies that it has, well unless you get everything working using Visual Studio with gvsbuild. I played around building GTK using gvsbuild, but I have no idea how you can get PyGObject and pycairo to successfully pip install using that. MINGW is how many applications that are built on a traditionally POSIX software stack, for example GIMP, LibreOffice, Blender, and VLC have support for Windows.
LeydenJar
commented
4 years ago Just had this issue. It happened because nodeJS installed python2.7 and added it to the path, perhaps it has overriten the python3 path. Adding the python 3 instalation file to the path again and putting it before the python2 file in the path list solved my problem. Now when I run python on the comand line it actually runs python3. It changes when I switch the order in the path
Juliodonadello
commented
10 months ago Hello, I had this issue. I was using python 3.11 and a ML library needed a lower python version. So i installed python 3.9 with it's env variable renamed to python39. When using python -m venv env (the 3.11 version is invoque) the virtual environment is created correctly in my repo. When using python39 -m venv env (the 3.9 version is invoque) the env folder is created but with many missing files and i get the error mentioned in this post: "Error: [WinError 2] El sistema no puede encontrar el archivo especificado" (in spanish) I tried every solutiuon mentioned here but i couldn't get it work. Can someone tell me if I am missing something?
i attach some info: C:\Users\jdonadel>python39 -m venv C:\Users\jdonadel\repos\speech2text\venv_test Error: [WinError 2] El sistema no puede encontrar el archivo especificado
C:\Users\jdonadel>where python C:\Users\jdonadel\AppData\Local\Programs\Python\Python311\python.exe C:\Users\jdonadel\AppData\Local\Microsoft\WindowsApps\python.exe
C:\Users\jdonadel>where pip C:\Users\jdonadel\AppData\Local\Programs\Python\Python311\Scripts\pip.exe C:\Users\jdonadel\AppData\Local\Programs\Python\Python39\Scripts\pip.exe
C:\Users\jdonadel>python -m pip --version pip 23.2.1 from C:\Users\jdonadel\AppData\Local\Programs\Python\Python311\Lib\site-packages\pip (python 3.11)
C:\Users\jdonadel>python39 -m pip --version pip 20.2.3 from C:\Users\jdonadel\AppData\Local\Programs\Python\Python39\lib\site-packages\pip (python 3.9)
I seems like my python39 env variable is not correctly shown in "where python" but i am able to use it under in "python39 -m pip --version"
workarround: I did a modification in the pyvenv.cfg file to use the 3.9 path in these values: home version executable command
This is somewhat related to #2745, but the original issue posted is different, so I thought it would be worthwhile having an issue posted for virtualenv failing.
I would like to have Python virtualenv's working in msys2. When trying to make a virtualenv:
Or trying it the now recommended way:
These are the installed Python 3 packages: