unittest: `sys.path` is different when running from terminal vs test UI

[karthiknadig]

CWD looks the same. syspath is very different.

From vscode:

['helios', '/home/juledwar/.vscode/extensions/ms-python.python-2024.0.1/pythonFiles/lib/python', '/home/juledwar/.vscode/extensions/ms-python.python-2024.0.1/pythonFiles/unittestadapter', '/home/juledwar/src/helios/.hatch/lib/python3.12/site-packages/_pdbpp_path_hack', '/home/juledwar/src/helios', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/home/juledwar/src/helios/.hatch/lib/python3.12/site-packages', '/home/juledwar/.vscode/extensions/ms-python.python-2024.0.1/pythonFiles', '/home/juledwar/.vscode/extensions/ms-python.python-2024.0.1/pythonFiles', '/home/juledwar/.vscode/extensions/ms-python.python-2024.0.1/pythonFiles/lib/python']
/home/juledwar/src/helios

From the CLI

['/home/juledwar/src/helios', '/home/juledwar/src/helios/.hatch/lib/python3.12/site-packages/_pdbpp_path_hack', '/usr/lib/python312.zip', '/usr/lib/python3.12', '/usr/lib/python3.12/lib-dynload', '/home/juledwar/src/helios/.hatch/lib/python3.12/site-packages', '/home/juledwar/src/helios']
/home/juledwar/src/helios

Originally posted by @bigjools in https://github.com/microsoft/vscode-python/issues/17641#issuecomment-1955672088

[eleanorjboyd]

saw your comment- is it worth trying to figure this out now or wait until we remove the experiment which is currently 1 issue away?

[karthiknadig]

I think we can ship the plugin. This can be addressed after, I think this might actually turnout to be activated run bug.

[bigjools]

Incredibly, this is now fixed on the latest pre-release I installed just now. Did you change something?

[inoa-dmpassy]

A test fails due to this:

output = subprocess.run("pyrsa-sign", capture_output=True, text=True, encoding="utf-8", shell=True)
# pyrsa-sign' is not recognized as an internal or external command

pyrsa-sign sits at env/Scripts/pyrsa-sign.exe (windows machine), however, due to the test runner not appending env (both sites packages and Scripts) to the PATH, it fails to identify this executable.

Currently using extensions "Python v2024.6.0"

well, I'll just mock this for now, but I can see this being a problem

[eleanorjboyd]

Hi @inoa-dmpassy! Could you include your full test? Are you running the subprocess inside your given test?

Secondly, what do you mean by not appending env? Are you saying env from you computer or from your specific environment? We should be finding the environment, appending so if you are not seeing a variable you expect then that is a different problem.

Thanks

[eleanorjboyd]

Incredibly, this is now fixed on the latest pre-release I installed just now. Did you change something?

We have changed some stuff but nothing which I thought changed path- I will look to see if I can also repro the fix

[inoa-dmpassy]

@eleanorjboyd , yes, I'm running subprocess inside the test, these are the important lines:

command = [
    "pyrsa-sign",
    os.path.join(PROJ_DIR, "build_private.key"),
    "SHA-512",
    "--input=" + str(self.inner_zip),
    "--output=" + str(self.work_dir / "alphatools_update_package.sig"),
]
output = subprocess.run(cmd, capture_output=True, text=True, encoding="utf-8", shell=True)        

here's the tree comand of my currenct active command:

danielpass@DESKTOP-HLLM1EK:/mnt/c/Users/DMpassy/Projects/alphatools-main$ tree -L 2 env/
env/
├── CACHEDIR.TAG
├── CMakeLists.txt
├── COPYING
├── HISTORY.md
├── Lib
│   └── site-packages
├── README.md
├── Scripts
│   ├── activate
│   ├──# (a bunch of stuff)
│   ├── pyrsa-decrypt.exe
│   ├── pyrsa-encrypt.exe
│   ├── pyrsa-keygen.exe
│   ├── pyrsa-priv2pub.exe
│   ├── pyrsa-sign.exe
│   ├── pyrsa-verify.exe
│   ├── pystache-test.exe
│   ├── pystache.exe
│   ├── pytest.exe
│   ├── python.exe
│   ├──# (even more stuff)
├── extern
│   └── rapidfuzz-cpp
├── include
│   ├── Hamming.hpp
│   ├──# (a bunch of stuff)
├── man
│   └── man1
├── pyproject.toml
├── pyvenv.cfg
├── setup.py
├── share
│   └── man
└── src
    └── cython

if I run it in debug mode using vscode test runner, it works. If I run in normal mode, it priunts an error "pyrsa-sign is not a valid command" On the first case, (...)/env/Scripts is in the Path variable; not in the second one;

[eleanorjboyd]

great info thank you! Sounds like you found the item in the path that is not being added correctly. How do you expect the Scripts path to be added to the python path?What is the setup of yourproject? Just like the tree? Just want to clarify since I am unsure where you are running things from and how that would then impact the python path and why we are missing that specific path for you.

[inoa-dmpassy]

I'm running on windows

This is my project setup

project_dir
- main/
-- tests/
---test_example.py
- env/
- manage.py (django project)
- (...)

Using ctrl + P -> Python: Select interpreter, it indicates that the env/ python is selected. This, in my understanding, would be a global option, every interaction is vscode would appropriately activate this env.

What I mean by activating the env is calling source env/bin/activate (linux), env/Script/activate (windows). This scripts does many things.

Python docs relate to it,

A virtual environment may be “activated” using a script in its binary directory (bin on POSIX; Scripts on Windows). This will prepend that directory to your PATH, so that running python will invoke the environment’s Python interpreter and you can run installed scripts without having to use their full path.

I'd expect that the test runner would conform to the Python: Select interpreter settings and activate the env before running.

[eleanorjboyd]

@karthiknadig, thoughts here on why testing many not be waiting for environment activation?

[github-actions[bot]]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!