WIndows 3.7 redirector script issue

Issue

Version 20.0.34 with Python 3.7 on Windows seems to have messed up how tox runs. It appears to be caused by PR #1976

Environment

Provide at least:

• OS: Microsoft Windows Server 2019 - GitHub actions

• pip list of the host python where virtualenv is installed:

  appdirs-1.4.4 colorama-0.4.4 distlib-0.3.1 filelock-3.0.12 importlib-metadata-2.0.0 packaging-20.4 pluggy-0.13.1 py-1.9.0 pyparsing-2.4.7 six-1.15.0 toml-0.10.1 tox-3.20.1 tox-external-wheels-0.1.7 virtualenv-20.0.34 zipp-3.3.0
  

Output of the virtual environment creation

The tox output is available here: https://github.com/snowflakedb/snowflake-connector-python/runs/1250254992?check_suite_focus=true

It appears as calling the virtualenv is just like calling the system wide Python without having its dependencies injected to the system wide Python.

Here’s the important part of the output:

py37-extras-ci installed: <snip>,requests==2.23.0,<snip>
py37-extras-ci run-test-pre: PYTHONHASHSEED='436'
py37-extras-ci run-test: commands[0] | python test/extras/run.py --debug
Traceback (most recent call last):
  File "test\extras\no_use_pycon.py", line 8, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'
Full path: ['D:\\a\\snowflake-connector-python\\snowflake-connector-python\\test\\extras', 'C:\\hostedtoolcache\\windows\\Python\\3.7.9\\x64\\python37.zip', 'C:\\hostedtoolcache\\windows\\Python\\3.7.9\\x64\\DLLs', 'C:\\hostedtoolcache\\windows\\Python\\3.7.9\\x64\\lib', 'C:\\hostedtoolcache\\windows\\Python\\3.7.9\\x64', 'D:\\a\\snowflake-connector-python\\snowflake-connector-python\\.tox\\py37-extras-ci', 'D:\\a\\snowflake-connector-python\\snowflake-connector-python\\.tox\\py37-extras-ci\\lib\\site-packages']
Current process information
PID: 4328
Name: python.exe
Cmdline: C:\hostedtoolcache\windows\Python\3.7.9\x64\python.exe test/extras/run.py --debug

I have checked the changelog and I think there might be an issue in the redirector script, but I haven’t actually looked at the code myself.

I have verified that pinning virtualenv==20.0.33 outside of tox solves the issue.

Thank you!

[sfc-gh-mkeller]

Yup, you are right. I get the same error with venv 😓 . I’ll get on reporting this to Python and post a link here once I have done so

[gaborbernat]

In the above if you swap virtualenv calls with python -m venv can you reproduce the same issue? If yes you’ll need to report the bug to https://bugs.python.org/ for fix. If not then it’s related to virtualenv, and is our bug. Though here I suspect is venv issue. (Based on the findings we might be able to patch it here, while upstream fixes the issue, but first we must identify exactly the underlying cause).