Has the process of creating Python.exe changed?

[Matjoman]

I have a problem that I originally posted with pipenv as that is the package I am using. Someone there however suggested that it might have something to do with virtualenv. That is why I am posting it here also. If this is not the place, please excuse me.

Hi,
I have an issues that I have been trying to resolve for quite some time.

I have a automated test for an API where I start the server with the following command.

  def setup_method(self):
        # start server
        port = str(get_free_port())
        child_env = os.environ.copy()
        child_env['PORT'] = port

        proc = subprocess.Popen(
            ['python', 'src/server.py'],
            env=child_env,
            stdout=subprocess.PIPE,
            stderr=subprocess.STDOUT
        )

and then I run a bunch of different tests against it.

The tests has been working for some years both on a messy Windows environment and in a clean docker image.

What now has begun to happen is that the server fails to start due to the fact that it cannot find the package Waitress which is installed and accessible within the environment.

I have managed to find out a remedy but I have no clue why this works and why pipenv is behaving in this way.
When I install my environment pipenv does not copy Python.exe as is from where I have told it to get it. Instead there is a much larger Python.exe (Hybrid) located in the environment/Scripts. If I replace this file with Python.exe, Python3.dll and Python310.dll in the created environment it manages to run the test within the activated shell.

When I have debugged I and looked at the child_env I get from the above code have found that the hybrid version has different paths in a key called 'LIBRARY_ROOTS'. The hybrid version has /path/Scripts but the older version has /path/Lib/site-packages also.

If I look at older environments I can see that they have the Python + 2 dll file setup but when I make a copy of a project with an old environment and install directly from the Pipfile.lock I now get a larger hybrid Python.exe version and the test fails.

I have tried to install 6 different versions of Pipenv but nothing helps.

Summary:
I am at a loss with this weird behavior. My code runs well but it is the test that is spawned by subprocess that has begun failing. This seems to be caused by a hybrid Python.exe instead of Python.exe + 2*dll files in the created environment.

Best regards,
Mattias

[pfmoore]

Yes, the way virtual environments works changes - it's an implementation detail, so this is to be expected. Nowadays (i.e., I don't know which version this started in) the python.exe file in a venv is a redirector that runs the "base" Python.

If pipenv isn't handling the new redirector correctly, that's probably an issue with pipenv, not with virtualenv (or how virtual environments work).