pyvenv устарело в 3,6, в пользу использования python3 -m venv.
Вас может удивить, как это связано с вашим Python 3.5.2, начиная с 3.5 <3.6. Что ж, если вы запустите установщик Python 3.5 или даже 3.6 из python.org или <code>make install из исходного кода, вы получите команду pyvenv (и, возможно, также pyvenv3, pyvenv3.5 и / или *). 1011 *). Но ты этого не делал; Вы использовали Python вашего дистрибутива 3.5.
В дистрибутивах давняя традиция разбивать большие пакеты, такие как Python, на основной пакет и различные «дополнительные» пакеты, такие как python3-pip или python3-curses. И не только Red Hat; 1 Debian и Ubuntu также разделяют venv в python3-venv пакет. То, как они решают, что является «основным», а что «необязательным», является сложным процессом, в котором много унаследованных проблем, поэтому я не знаю точно, каковы причины, но могу предположить.
Во-первых, большинство пользователей Linux предпочитают использовать pipenv и / или virtualenv. У них больше возможностей, они не застряли в ледниковом цикле выпуска Python, и вы можете использовать ту же версию с Python 3.4, 3.6 и даже 2.7. В 2011 году добавление venv выглядело как TOOWTDI для устранения несовместимых конкурирующих решений виртуальной среды, но вместо этого они стали совместимыми друг с другом, в то время как venv находился в состоянии стагнации. На самом деле, официальный Python Packaging Authority 2 рекомендует virtualenv для установки пакетов и pipenv для разработки приложений , а PyPA отклонил предложение изменить это в 2017 году .
Кроме того, как объясняется в документах 3.6, причина pyvenv устарела в основном из-за путаницы, которую это вызывает в дистрибутивах Linux, которые поставляют несколько версий Python.
И, наконец: venv зависит от pip. Который не встроен. Как это работает? Что ж, если вы получите бинарный установщик python.org, он будет включать pip. И если вы создаете его из исходного кода, Python (3.4+) использует ensurepip для начальной загрузки pip и setuptools. Но это в первую очередь для удобства пользователей Mac и Windows, а также людей, которые создают собственные версии Python; несколько дистрибутивов Linux используют ensurepip. В конце концов, причина, по которой вы используете корпоративный стабильный дистрибутив, заключается в том, что вам нужны конкретные, протестированные версии всего, что вы делаете, устанавливая их пакет python3-pip, а не получая kludgy pip из ensurepip и затем делать pip install --upgrade pip, чтобы получить будущую версию, которую они не тестировали. Поэтому, если дистрибутив не собирается объединять свои pip в свои пакеты python, нет смысла включать venv.
1. Конечно, CentOS 7.2 просто копирует RHEL 7.2, потому что в этом суть CentOS, поэтому вопрос в том, почему RHEL 7.2 сделал venv необязательным пакетом.
2. Насколько официальным является PyPA? Это не совсем понятно - он находится под PSF и использует SIG python.org, но поддерживает отдельное присутствие. Но если вы посмотрите на названия, это в основном одни и те же люди, которые являются и разработчиками ядра Python, и разработчиками для основных дистрибутивов Linux. Поэтому неудивительно, что эти дистрибутивы обращают внимание на PyPA - в обоих местах решения принимают одни и те же люди.