classification
Title: Python 3.7.4 venv command does not install pip
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.7
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: paul.moore, steve.dower
Priority: normal Keywords:

Created on 2019-10-04 09:18 by paul.moore, last changed 2019-10-04 10:02 by paul.moore. This issue is now closed.

Messages (4)
msg353911 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2019-10-04 09:18
The venv module with Python 3.4 on Windows doesn't install pip - even though the --without-pip flag is not specified. This appears to be a regression since pip is installed when using 3.7:

>C:\Utils\PythonVersions\Python-3.7.3\python.exe -m venv ve-373
>dir .\ve-373\Scripts\pip.exe


    Directory: C:\Work\Scratch\vv\ve-373\Scripts


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       04/10/2019     10:08         102765 pip.exe


>py -m venv ve-374
>dir .\ve-374\Scripts\pip.exe
dir : Cannot find path 'C:\Work\Scratch\vv\ve-374\Scripts\pip.exe' because it does not exist.
At line:1 char:1
+ dir .\ve-374\Scripts\pip.exe
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\Work\Scratch...Scripts\pip.exe:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
>py -V
Python 3.7.4
msg353912 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2019-10-04 09:37
This appears to be somehow caused by running Python 3.7.4 from an active virtualenv (which I'd forgotten I had active when I did the test).

Regardless, I'd have expected that the command would either correctly create a venv containing pip, or fail to create the venv at all. Creating an incomplete venv is extremely confusing for the user, if nothing else.

It looks like this is *not* a regression - it's been like this since 3.6.8 at least.

Actually, the created venv looks pretty broken to me - it has the *parent* environment in `sys.path`, but does not have its *own* environment there:

>.\ve-368a\Scripts\python.exe
Python 3.6.8 (tags/v3.6.8:3c6b436a57, Dec 24 2018, 00:16:47) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\Work\\Scratch\\vv\\ve-368a\\Scripts\\python36.zip', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\DLLs', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\lib', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\Scripts', 'C:\\Utils\\PythonVersions\\Python-3.6.8\\Lib', 'C:\\Utils\\PythonVersions\\Python-3.6.8\\DLLs', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4', 'C:\\Users\\UK03306\\.virtualenvs\\f1980c81dac32d4\\lib\\site-packages']

Note the lack of ve-368a directories, and the presence of a lot of directories from .virtualenvs (the parent environment).
msg353913 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2019-10-04 09:48
Further update - this appears to also happen on Ubuntu (at least the version available through the Windows Linux subsystem), so it's not a Windows-specific issue.
msg353915 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2019-10-04 10:02
Sigh. Never mind, this appears to be because virtualenv uses its own hacked copy of site.py which is missing a lot of the venv support code.

I'll report this over on virtualenv.
History
Date User Action Args
2019-10-04 10:02:24paul.mooresetstatus: open -> closed
resolution: third party
messages: + msg353915

stage: resolved
2019-10-04 09:48:36paul.mooresetassignee: steve.dower ->
messages: + msg353913
2019-10-04 09:37:27paul.mooresetmessages: + msg353912
2019-10-04 09:18:54paul.moorecreate