Подтвердить что ты не робот

Python: какая разница между pythonbrew и virtualenv?

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

4b9b3361

Ответ 1

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Согласно this (который я нашел через 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?

Ответ 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/

Ответ 4

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

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

Homebrew (только для MacOS)

... Можно установить python и python3. Они будут храниться в Homebrew Cellar и символически связаны с /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 делает с gemset) для каждого проекта. Следовательно:

Virtualenv

... Самое близкое к rvm. Чтобы процитировать этот пост:

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

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

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

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

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

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

Ответ 5

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

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