title: Why does subprocess.popen, when run in virtual environment, find the global python executable?
body: <p>Consider the following script run in a Python 3.x virtual environment on Windows 10:</p>
  <pre class="lang-py prettyprint-override"><code>#!/usr/bin/env python
  import sys, os, subprocess
   
  print(sys.executable)
  args = [&quot;python&quot;, &quot;-c&quot;, &quot;import sys; print(sys.executable)&quot;]
  p = subprocess.Popen(args, stdout=None, env=os.environ)
  p.wait()
  </code></pre>
  <p>On most systems, the two calls to <code>print(sys.executable)</code> return a string showing the location of python.exe within the virtual environment, e.g.</p>
  <pre><code>C:&gt; python test.py
  C:\venv\Scripts\python.exe
  C:\venv\Scripts\python.exe
  </code></pre>
  <p>But occasionally, we'll encounter a machine where the first call finds python.exe from the virtual environment, but the second call finds python.exe from the machine's global installation, e.g.</p>
  <pre><code>C:&gt; python test.py
  C:\venv\Scripts\python.exe
  C:\Users\me\AppData\Local\Programs\Python\Python38\python.exe
  </code></pre>
  <p>The program above is simplified to make it easy to read. The real program uses subprocess.popen to call another python script whose imports fail because the global install doesn't have the same packages as the virtual install.</p>
  <p>I suspected the PATH environment variable, but it appears to be the same when printed before and during the subprocess.popen call. In both cases, the venv/Scripts folder exists ahead of the global Python install folder.</p>
  <p>I've also tried deleting the virtual environment and recreating it. No luck.</p>