python: в чем разница между pythonbrew и virtualenv?

Question

Я новичок в Python, и я планирую изучать Django. У меня был небольшой опыт работы с ruby ​​(не рельсами), и я знаком с RVM , однако я не понимаю разницу между pythonbrew и virtualenv . Я знаю, pythonbrew - это подражание RVM , но я думал, что virtualenv уже делать то, что делает RVM (или наоборот, что pythonbrew уже делает то, что делает RVM). Может кто-нибудь объяснить, и, возможно, привести конкретные примеры / использования, чтобы помочь мне понять это. Большое спасибо!

Answer 1

Pythonbrew сродни Ruby's rvm : это функция оболочки, которая позволяет:

• Создание одной или нескольких полных автономных версий Python, каждая из которых хранится локально в вашем домашнем каталоге. Вы можете построить несколько версий Python таким образом.
• Легко переключайтесь между версиями Python.

Созданные вами Pythons полностью изолированы друг от друга, и от любой версии (версий) Python, установленных для всей системы.

Virtualenv похож, но не совсем то же самое. Он создает виртуальную среду Python, которая концептуально находится поверх некоторой существующей установки Python (обычно общесистемной, но не всегда). По умолчанию на платформах Unix (и Mac) он создает символические ссылки на различные модули библиотеки Python, поэтому вы в буквальном смысле делитесь этими модулями с «реальной» базовой реализацией Python. Но у virtualenv есть свой собственный каталог "bin" и каталог "site-packages". Все, что вы устанавливаете в виртуальной среде Python, доступно только в этой среде.

Одним из преимуществ Pythonbrew является то, что создаваемые им среды Python действительно полностью автономны. Они не могут быть загрязнены чем-либо, что испортилось в базовой базовой установке Python, потому что нет базовой базовой установки. Это не относится к виртуальной среде. Если вы создаете Python virtualenv, а затем каким-то образом облажаете базовый экземпляр Python, над которым он находится (например, случайно удаляете часть каталога «site» базового Python при входе в систему как root), вы испортите любую среду virtualenv на основе на этом Питоне тоже.

Однако у virtualenv есть свои преимущества. Вероятно, самое большое преимущество в том, что он легкий. Поскольку Pythonbrew компилирует Python с нуля, для создания одной из его сред создание среды Pythonbrew Python занимает некоторое время. Для сравнения, создание среды Python virtualenv действительно быстро.

Вы можете использовать их вместе. Вот одна ситуация, когда вы можете захотеть это сделать.

• Ваша базовая система использует Python 2.6.
• Вам необходимо установить Python 2.7.
• По какой-то причине вы не можете (или не хотите) устанавливать Python 2.7 для всей системы, бок о бок с Python 2.6.

В таком случае вы можете использовать Pythonbrew для установки базового Python 2.7 в вашем домашнем каталоге , где он не конфликтует ни с чем, установленным в другом месте. Затем вы можете создать одну или несколько облегченных сред Python virtualenv, основанных на установленном Pythonbrew 2.7 Python. Например, вы можете использовать virtualenv, чтобы таким образом раскрутить недолговечные тестовые среды для Python 2.7.

Я сомневаюсь, что большинство людей на самом деле так делают. (Не знаю.) Но нет никаких причин, по которым ты не можешь.

Answer 2

За то, что стоит, я никогда не слышал о PythonBrew раньше, но я знаю (и люблю) virtualenv.

Virtualenv используется для создания отдельных сред, на основе на установке Python, установленной на вашем компьютере. То есть, если у меня есть Python 2.7, я могу создать несколько изолированных сред Python 2.7, но я не могу создать среды Python2.6.

Согласно этому (который я нашел через google) Pythonbrew, похоже, сосредоточен на установке других версий python. Поэтому я думаю, что вы бы использовали brew для установки py2.6 и 2.7, а затем virtualenv для создания сред для каждого.

Или, похоже, brew также может создавать среду, используя virtualenv.

Почему другой интерпретатор Python на самом деле не является изолированной средой.

В каждой установке python есть набор пакетов (я думаю, они помещены в «site-packages»). Если вы устанавливаете новый пакет, он добавляется к этому набору и становится доступным для всего кода Python.

Это может быть проблемой, если у вас есть один проект, созданный на Django0.96, и вы хотите начать новый проект с использованием Django1.3. Если вы просто обновите системную версию Django, это затронет и ваш старый проект.

С помощью virtualenvs вы можете создать одну среду с Django1.3, а другую - с Django0.96, обе из которых будут python2.7. Если у вас все в порядке с вашим старым проектом на python2.6 и новым на python2.7, вы тоже можете это сделать, но как насчет ваших следующих двух проектов, использующих версии diffenret из Django-Trunk?

Answer 3

Python brew предназначен для сборки и установки, может быть, как какой-то buildbot.Я не очень знакомый.Virtualenv в основном предназначен для тех случаев, когда у вас другая версия python или вы хотите попробовать какой-нибудь пакет, не нарушая версию в системе.

---

Хорошо, это что-то упитывает

Создание изолированных сред Python (использует virtualenv ):

pythonbrew venv init
pythonbrew venv create proj
pythonbrew venv list
pythonbrew venv use proj
pythonbrew venv delete proj

С http://pypi.python.org/pypi/pythonbrew/

Answer 4

Поскольку все приведенные выше ответы довольно стары, я бы хотел обобщить мои выводы здесь. Я пытался выяснить, как это работает с Python после перехода с rvm / ruby, и не смог найти четкого объяснения где-либо в Интернете.

Итак, у нас есть следующие опции на Macos:

Домашний напиток (только MacOS)

... Можно установить python и python3. Они будут храниться в погребе Доморощенного и снабжены ссылками с /usr/local/bin. По умолчанию python, установленный с использованием brew, составляет 2.7.6.

Пакеты, установленные с использованием pip, перейдут в расположение по умолчанию (у вас также есть символические ссылки pip и pip3).

Pyenv (наследник Pythonbrew)

... Является альтернативой Homebrew (на Macos) способу установки и поддержки нескольких версий Python. В Linux нет Homebrew, поэтому Pyenv является специализированной версией для Python. Он также собирает Python из исходного кода.

Pyenv сохраняет установки Python в ~/.pyenv/versions/ и позволяет быстро переключаться между ними и использовать одинаковые имена для двоичных файлов (python, pip и т. Д.). Он использует «shim» двоичные файлы, которые являются поддельными двоичными файлами, такими как python, pip и т. Д., Которые имитируют Python и вместо этого просто молча перенаправляют выполнение на текущую активную версию.

Пакеты, установленные с использованием pip, перейдут в активную установку Python.

Итак, ни один из этих методов на самом деле не достаточен для поддержки отдельных установок Python и наборов версий пакетов (как это делает rvm с наборами gemsets) для каждого проекта. Следовательно:

Virtualenv

... это самая близкая вещь к рвм. Цитировать это сообщение :

устанавливает чистую копию Python в новом каталоге, копируя или связывая файлы из вашей основной установки Python для создания новых каталогов bin и lib

Таким образом, он использует текущую активную копию Python и копирует ее в отдельный каталог. virtualenvwrapper добавляет функциональность для управления этими средами и автоматически активирует их, используя cd, как и rvm.

Это позволяет выделить версию Python и установленные библиотеки, используемые для каждого проекта. Однако он не устанавливает python версии самостоятельно.

Таким образом, звучит так, как будто большинство людей используют комбинацию pyenv + virtualenv или brew + virtualenv (варево, конечно, зависит от Macos). Первая часть используется для установки версий Python (при необходимости), а вторая - клонировать их для разных проектов и переключаться между ними.

PS: Я только начинаю понимать, пожалуйста, поправьте меня, если что-то здесь не так.

PPS: Мне кажется, что весь этот бизнес можно улучшить, объединив pyenv и virtualenv под одной крышей ...

Answer 5

"pythonbrew is a program to automate the building and installation 
 of Python in the users $HOME."

В отличие от этого, virtualenv предоставляет изолированную среду для разработки проекта - он хранит все библиотеки для этого проекта в одном месте и значительно облегчает перемещение (и, следовательно, развертывание) проекта.