This was reported in tox-dev/tox#1648, then in pypa/pip#8894, and now here.
When trying to use tox on MSYS2 (MINGW64), I am getting several errors when packages are installed:
ERROR: Cannot uninstall 'distlib'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
The same procedure works on powershell or on GNU/Linux.
To reproduce, see https://github.com/eine/tox/actions/runs/264949167 and the corresponding commit: eine/tox@9b702f8. The error is seen in https://github.com/eine/tox/runs/1143520398?check_suite_focus=true#step:4:28.
See https://github.com/pypa/pip/issues/8894#issuecomment-696114771.
Like on Linux installing to the system with pip is likely not going to end well. You either can install with --user
or use a venv:
python -m venv _venv
source _venv/bin/activate
pip install tox
There might be other things broken with our Python etc of course.
This may be only dependency issue. tox requires virtualenv and disutils. I have:
pip install virtualenv.makepkg -si. tox/virtualenv requires distutils v0.3.1 which is pending in update queue. This is the main cause.Is it possible to make/add a mingw-w64-python-virtualenv package?
Is it possible to make/add a mingw-w64-python-virtualenv package?
we've had to patch venv in Python to make it work IIRC. We'd probably need to do something similar for virtualenv. I was kinda hoping that with the end of Python 2 virtualenv would be superseded by venv.
@lazka, I tried both options (venv and --user). Both seem to fix the distlib issue, but both fail afterwards:
WARNING: test command found but not installed in testenv
cmd: D:/a/_temp/msys/msys64/mingw64/bin/python.EXE
env: D:/a/tox/tox/.tox/.package
Maybe you forgot to specify a dependency? See also the allowlist_externals envconfig setting.
DEPRECATION WARNING: this will be an error in tox 4 and above!
...
=================================== log end ===================================
ERROR: FAIL could not package project - v = InvocationError("D:/a/tox/tox/.tox/.package/Scripts/python _venv/lib/python3.8/site-packages/tox/helper/build_requires.py setuptools.build_meta '' ''", 2)
Is this related to MSYS2 too?
@Biswa96, I tried installing virtualenv first, but it fails. See https://github.com/eine/tox/runs/1152783091?check_suite_focus=true.
we've had to patch venv in Python to make it work IIRC. We'd probably need to do something similar for virtualenv. I was kinda hoping that with the end of Python 2 virtualenv would be superseded by venv.
Per https://github.com/pypa/virtualenv/issues/1366 and https://www.youtube.com/watch?v=o1Vue9CWRxU it's not going to go away anytime soon.
thanks, good to know
This likely means the next step should be someone packaging virtualenv and making it work with our Python.
I added another test where mingw-w64-x86_64-python-colorama mingw-w64-x86_64-python-tox are installed through pacman, instead of installing mingw-w64-x86_64-python-pip and then pip install tox. I get an explicit error about virtualenv not being found: https://github.com/eine/tox/runs/1158452753?check_suite_focus=true#step:4:22. That is consistent with your comments above.
However, on the one hand I don't understand how is it that mingw-w64-x86_64-python-tox exists if virtualenv has never been packaged. I mean, that tox package should have never worked, should it?
On the other hand, the errors above are reported after virtualenv is said to be installed: https://github.com/eine/tox/runs/1158452793?check_suite_focus=true#step:4:39. My understanding is that only "simple" packages can be installed through pip. Other "more complex" packages don't work, even though installation seems successful. Those need to be specifically packaged and installed through pacman. Is this correct? Are there any guidelines about this?
This likely means the next step should be someone packaging virtualenv and making it work with our Python.
Is there any discussion about why MSYS2's Python cannot look like any other normal Python?
We prefer the Linux like layout.
I think there was really three separate issues with mingw python and virtualenv that were preventing virtualenv (and projects like pre-commit, tox, and poetry that depend on virtualenv) from working:
Tox is now working for me:
```
$ tox
py38 installed
...
Results (2.08s):
93 passed
_______________________________________________________ summary _______________________________________________________
py38: commands succeeded
@danyeaw, thanks a lot for looking into this! That's a nice set of patches!
I updated https://github.com/eine/tox/blob/msys2/.github/workflows/msys2.yml and I run it several times:
pip install -U tox --progress-bar off, I got the error described in #7134: https://github.com/eine/tox/runs/1272961479?check_suite_focus=true#step:4:58.pip install -U . --progress-bar off from tox's repo, I get a different error: https://github.com/eine/tox/runs/1273000829?check_suite_focus=true#step:4:68.mingw-w64-x86_64-python-tox fails because virtualenv is missing: https://github.com/eine/tox/runs/1273000887?check_suite_focus=true#step:4:21.Would you mind helping me understand which of the cases in https://github.com/eine/tox/blob/msys2/.github/workflows/msys2.yml is expected to work after these patches are merged and new versions are released?
My PR will fix the first case.
For the second case, this is a different issue I have seen as well when trying to build a package (no wheel exists, you don't have wheel installed, or you are trying to install from source)
For the third case, someone would need to package virtualenv.
@danyeaw should this be fixed upstream? Installing virtualenv through pacman, and tox either through pacman or pip, I get the error reported above: https://github.com/msys2/MINGW-packages/issues/7014#issuecomment-697098281
@eine I don't think the updated package has made it in to the repo yet. @lazka how do the repo versions get rebuilt?
Oh, #7227, #7229.
The last change was for venv though, not virtualenv (and only a corner case)
@lazka, can you please reopen this issue?
@eine Can you please create a new issue? As I said above, issues with building wheels aren't related to virtualenv or tox problems.
@danyeaw the use case I'm interested in is using MSYS2 and tox on CI (GitHub Actions):
That should be unrelated to wheels.
The motivation for testing tox, as reported above, is removing third-party projects from the equation.
Hence, I can open a new issue, but I don't know what would make it different from this one.
@eine have you tested this locally? Those don't look like issues with MINGW to me, they look like issues with your GitHub Actions setup.
If you think there is still an issue running tox, can we please have a minimum reproducible example? Thanks!
@danyeaw, the output from VUnit is exactly the same I get locally:
# git clone --recursive https://github.com/VUnit/vunit
Cloning into 'vunit'...
remote: Enumerating objects: 26, done.
remote: Counting objects: 100% (26/26), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 18515 (delta 13), reused 8 (delta 3), pack-reused 18489
Receiving objects: 100% (18515/18515), 11.98 MiB | 2.77 MiB/s, done.
Resolving deltas: 100% (12985/12985), done.
Submodule 'vunit/vhdl/JSON-for-VHDL' (https://github.com/Paebbels/JSON-for-VHDL.git) registered for path 'vunit/vhdl/JSON-for-VHDL'
Submodule 'vunit/vhdl/osvvm' (https://github.com/OSVVM/OSVVM.git) registered for path 'vunit/vhdl/osvvm'
Cloning into '/tmp/vunit/vunit/vhdl/JSON-for-VHDL'...
remote: Enumerating objects: 143, done.
remote: Counting objects: 100% (143/143), done.
remote: Compressing objects: 100% (83/83), done.
remote: Total 729 (delta 59), reused 123 (delta 47), pack-reused 586
Receiving objects: 100% (729/729), 170.99 KiB | 487.00 KiB/s, done.
Resolving deltas: 100% (165/165), done.
Cloning into '/tmp/vunit/vunit/vhdl/osvvm'...
remote: Enumerating objects: 100, done.
remote: Counting objects: 100% (100/100), done.
remote: Compressing objects: 100% (70/70), done.
remote: Total 755 (delta 57), reused 72 (delta 30), pack-reused 655
Receiving objects: 100% (755/755), 18.05 MiB | 9.67 MiB/s, done.
Resolving deltas: 100% (406/406), done.
Submodule path 'vunit/vhdl/JSON-for-VHDL': checked out 'c8a6f517aabf66ce3089669cc8e98852921e268b'
Submodule path 'vunit/vhdl/osvvm': checked out '185a11d7bbf896e5fb66035cbad7fcb5ab505c79'
# cd vunit
# tox -e py38-docs
.package create: C:/msys64/tmp/vunit/.tox/.package
.package installdeps: setuptools >= 35.0.2, setuptools_scm >= 2.0.0, <3
WARNING: test command found but not installed in testenv
cmd: C:/msys64/mingw64/bin/python.EXE
env: C:/msys64/tmp/vunit/.tox/.package
Maybe you forgot to specify a dependency? See also the allowlist_externals envconfig setting.
DEPRECATION WARNING: this will be an error in tox 4 and above!
WARNING: test command found but not installed in testenv
cmd: C:/msys64/mingw64/bin/python.EXE
env: C:/msys64/tmp/vunit/.tox/.package
Maybe you forgot to specify a dependency? See also the allowlist_externals envconfig setting.
DEPRECATION WARNING: this will be an error in tox 4 and above!
ERROR: invocation failed (exit code 2), logfile: C:/msys64/tmp/vunit/.tox/.package/log/.package-2.log
====================================================== log start ======================================================
======================================================= log end =======================================================
ERROR: FAIL could not package project - v = InvocationError("C:/msys64/tmp/vunit/.tox/.package/Scripts/python C:/msys64/mingw64/lib/python3.8/site-packages/tox/helper/build_requires.py setuptools.build_meta '' ''", 2)
# pacman -Ss tox
mingw32/mingw-w64-i686-perl 5.28.0-1
A highly capable, feature-rich programming language (mingw-w64)
mingw32/mingw-w64-i686-python-tox 3.20.0-1
Python virtualenv management and testing tool (mingw-w64)
mingw64/mingw-w64-x86_64-perl 5.28.0-1
A highly capable, feature-rich programming language (mingw-w64)
mingw64/mingw-w64-x86_64-python-tox 3.20.0-1
Python virtualenv management and testing tool (mingw-w64)
# pacman -Ss virtualenv
mingw32/mingw-w64-i686-python-tox 3.20.0-1
Python virtualenv management and testing tool (mingw-w64)
mingw32/mingw-w64-i686-python-virtualenv 20.0.35-1
Virtual Python Environment builder (mingw-w64)
mingw64/mingw-w64-x86_64-python-tox 3.20.0-1
Python virtualenv management and testing tool (mingw-w64)
mingw64/mingw-w64-x86_64-python-virtualenv 20.0.35-1 [installed]
Virtual Python Environment builder (mingw-w64)
# pip3 list | grep tox
tox 3.20.1
# pip3 list | grep virtualenv
virtualenv 20.0.35
@eine I think we really need a separate issue for each issue, and then we can work on resolving each one. Your initial issue is for distlib not found, which is fixed. We also fixed multiple other issues with virtualenv and tox.
This issue looks like {envpython} doesn't work with MINGW, it is looking for python in Scripts instead of bin.
If you run tox on a project that doesn't use {envpython} in the config, it should work fine. We should try to work with the tox project to fix this upstream.