[Broken CI] Win job @ Azure Pipelines

[webknjaz]

There's been a lot of CI failures recently and most of them are addressed. But there's one left, I've tried looking into it but I currently don't understand how to fix it. Example: https://dev.azure.com/jaraco/setuptools/_build/results?buildId=1495&view=logs&j=f2aa1cb7-ddd8-5e13-2793-3e55ac100c6d&t=0158daa4-66d3-5648-b813-c154c6e360f2.

There's two jobs that currently fail under Azure DevOps Windows+Python3.8 job:

• setuptools.tests.test_virtualenv.test_test_command_install_requirements
• setuptools.tests.test_virtualenv.test_test_command_install_requirements_when_using_easy_install

Judging from the log, they both seem to invoke setup.py bdist_wheel under the hood and emit

WARNING: The wheel package is not available.

followed by an error output. Also, I've seen some virtualenv output lines suggesting that the wheel package install has been requested and succeeded before.

The most surprising to me is that the tests are perfectly fine on AppVeyor so my guess is that some of the CI environment may have changed. Tox-installed deps in both envs are the same, including virtualenv==20.0.35,wheel==0.35.1.

[webknjaz]

This line is what fails:

setuptools/setuptools/tests/test_virtualenv.py

Line 120 in 898ae04

virtualenv.run('python setup.py develop', cd=SOURCE_DIR)

.

It executes python setup.py develop via pytest-virtualenv->pytest-shutil which, under the hood, seems to explode on python setup.py test -s test:

E               subprocess.CalledProcessError: Command '['python', 'setup.py', 'test', '-s', 'test']' returned non-zero exit status 1.

And since that happens in a virtualenv that reports having wheel in it while the captured output from setuptools says there's no wheel, I think this may be a bug in virtualenv or something like that.

@jaraco any ideas?

[jaraco]

I'm able to replicate this issue locally as well. I suspect something has changed in azure or pytest-shutil. The builds were passing and then started failing 5 days ago:

I don't see any releases in pytest-shutil or pytest-virtualenv in that timeframe either.

I suspect what's happened is Azure Pipelines has removed an implicit install of wheel in the system site-packages and the tests happen to be dependent on it.

I've tried troubleshooting using my local install, but my Windows VM has grown unusably slow.

[jaraco]

I see this in the output:

subprocess.CalledProcessError: Command '['c:\\python38\\python.exe', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', 'C:\\Users\\jar
aco\\AppData\\Local\\Temp\\tmp3y1lwimc', '--quiet', '--find-links', 'C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-1\\test_test_command
_install_requ0\\foobar-2.4.tar.gz', '--find-links', 'C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-1\\test_test_command_install_requ0\\
bits-4.2.tar.gz', '--find-links', 'C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-1\\test_test_command_install_requ0\\bobs-6.0.tar.gz', 
'--find-links', 'C:\\Users\\jaraco\\AppData\\Local\\Temp\\pytest-of-unknown\\pytest-1\\test_test_command_install_requ0\\pieces-0.6.tar.gz', 'bits==4.2']' re
turned non-zero exit status 1.

So it does seem that something is invoking pip wheel and expecting wheel to be installed in the system site-packages.

[jaraco]

In my traceback, the issue happens at L171:

    virtualenv.run(
        ['python', 'setup.py', 'test', '-s', 'test'], cd=str(tmpdir))

Somehow, that python is not resolving to the Python in the virtualenv. I think I've seen this before.

[jaraco]

Right: man-group/pytest-plugins#166