В моем CentOS7.2 у меня есть команда `python3`, но почему я не могу использовать pyvenv?
В моем CentOS7.2 у меня есть python3 команда, но почему я не могу использовать pyvenv?
[root@www myProject]# pyvenv --version
-bash: pyvenv: there is no command
[root@www myProject]# python3 --version
Python 3.5.2
[root@www myProject]# which python3
/usr/bin/python3
1 ответ
pyvenv устарел в 3.6, в пользу использования python3 -m venv,
Вы можете задаться вопросом, как это связано с вашим Python 3.5.2, начиная с 3.5 < 3.6. Хорошо, если вы запускаете установщик Python 3.5 или даже 3.6 с python.org, или make install из источника вы получите pyvenv команда (и, возможно, также pyvenv3, pyvenv3.5 и / или pyvenv-3.5). Но ты этого не делал; Вы использовали 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 пакет, не получая грязный 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 - в обоих местах решения принимают одни и те же люди.