Python easy_install в virtualenv дает ошибку setuptools

Ответ 1

Я не могу сказать, почему именно вы получаете ошибки, но я уверен, что существует систематический подход, который позволяет вам полностью установить ваш пользовательский Python, включая рабочий пип и virtualenv. Ниже я описываю процедуру, которую я буду использовать.

Прежде всего, оставьте свою систему Python нетронутой по ряду причин. Один из них состоит в том, что части вашего дистрибутива Linux могут зависеть от особенностей его Python по умолчанию. Вы не хотите нарушать эти части. Другая причина заключается в том, что vanilla Python, установленный для местоположений по умолчанию, может запутаться из-за остатков исходного Python (у дистрибутивов может быть определен макет каталога Python/dist-packages/site-packages, который отличается от ванильного). Это может быть или не быть реальной проблемой на практике - вы можете концептуально предотвратить эти проблемы, не перезаписывая систему Python. Другим аргументом является то, что нет необходимости устанавливать Python 2.7.6 под root. Установите его как непривилегированный пользователь (называемый здесь "joe" ) и поместите его в /opt или что-то еще. Это было бы чистое начало.

После настройки вашего пользовательского Python создайте себе небольшую оболочку script, например. setup.sh, который устанавливает среду для использования вашей пользовательской версии Python. Обязательно настройте и очистите окружающую среду. Очевидно, что это особенно влияет на PATH и PYTHONPATH. Я бы удостоверился, что PYTHONPATH не установлен и что PATH правильно указывает на пользовательскую установку. Посмотрите env и попробуйте определить, есть ли что-нибудь, что могло бы настроить python неожиданными способами. В конце концов, убедитесь, что

$ command -v python
$ python -v

выполненный как joe, выглядите правильно.

Все еще будучи joe и в надлежащей среде, установите pip для настраиваемого Python. Согласно http://pip.readthedocs.org/en/latest/installing.html, загрузите https://raw.github.com/pypa/pip/master/contrib/get-pip.py и выполните it: python get-pip.py. Убедитесь, что он установлен правильно и что ваша среда по-прежнему права:

$ command -v pip
/CUSTOM/PYTHON/bin/pip

$ pip --version
pip 1.x.x from /CUSTOM/PYTHON/lib/python2.7/site-packages

На этом этапе вы должны убедиться, что ваша среда не содержит никаких переменных VIRTUALENV_* (которые могли быть установлены вашим дистрибутивом или каким-либо другим компонентом (маловероятно, но стоит проверить)). Если задана какая-либо переменная VIRTUALENV_*, она скорее всего настроит virtualenv неожиданным образом. Избавьтесь от этого (unset или change). Затем перейдите и установите virtualenv в новый Python с помощью нового pip, через pip install virtualenv. Возможно, стоит попробовать установить последнюю версию virtualenv с помощью pip install https://github.com/pypa/virtualenv/tarball/develop.

Создайте и активируйте новую виртуальную среду. Используя command -v pip, убедитесь, что pip происходит из виртуальной среды. Затем установите свой собственный пакет (ы).

Примечание. Я бы определенно использовал pip для установки вещей в новую виртуальную среду, а не easy_install, если это возможно. pip скоро станет официальным инструментом установки (он будет включен в Python 3.4). Если по какой-то причине вы действительно зависите от easy_install, это должно быть возможно (команда easy_install предоставляется виртуальной средой), но просто убедитесь, что вы также должны проверить это через command -v easy_install.

Ответ 2

Ваш подход правильный и другие ответы (Jan-Philip and Piotr's) также, но ваша проблема проста:

Вы используете часть старой установки setuptools на Python sys.path вместе с новой установкой. Очевидно, что номера строк в pkg_resources.py должны быть примерно на 100 строк больше для текущей версии setuptools, чем в вашей трассировке:

  ...
  File "/usr/local/bin/scripts/pkg_resources.py", line 669, in require  ## 584 is too old
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/bin/scripts/pkg_resources.py", line 572, in resolve  ## 482 is too old
    raise DistributionNotFound(req)

Номера строк первых трех файлов setuptools в трассировке верны: "virtpy/bin/easy_install", "virtpy/.../site-packages/setuptools/command/easy_install.py", "virtpy/.../site-packages/setuptools/package_index.py". Использование разных версий одного и того же пакета - это большая проблема.

Изучите свой Python sys.path на python -c "import sys; print sys.path" и подумайте, почему "/home/gperrow/virtpy/lib/python2.7/site-packages" не раньше "/usr/local/bin/scripts" или поиск всюду для строки "/usr/local/bin/scripts". Почини это. Одним из возможных решений может быть установка setuptools снова локально в ваш активный virtualenv: python ez_setup.py. (Быстрый метод изучения причины состоит в том, чтобы определить сначала, если это вызвано пользовательскими настройками. Создайте новую учетную запись пользователя, запустите последние три команды (virtualenv virtpy; ...) из этой учетной записи, посмотрите на результат и удалите этого пользователя. работает, проверьте, какой файл конфигурации в вашем профиле создает проблему.)

Убедитесь, наконец, что используются новые pkg_resources:

(virtpy)$ python -c "import pkg_resources; print pkg_resources"
<module 'pkg_resources' from '/home/you/virtpy/lib/python2.7/site-packages/pkg_resources.pyc'>
# not the obsoleted /usr/local/bin/scripts/...

Ответ 3

У меня есть несколько предложений, а также то, что я считаю вашей проблемой. Сначала отпустите проблему.

Я заметил, что вы сказали в своем третьем пункте

• Подтверждено, что python -V дает мне 2.7.6 и sudo python -V также дает мне 2.7.6

Но вы не отображали версию python, видимую после 2-го до последнего пункта маркера, когда вы активируете свой virtualenv. Поскольку этот шаг играет с вашим путем, он, возможно, не вызывает питон, который вы думаете.

Что делает python -V после активации вашего виртуального? Я сильно подозреваю, что после шага активации вы перенаправляетесь и вызываете системный python (который на RHEL обычно равен = 2.5). Для RHEL важно, чтобы вы не обновляли версию python, установленную системой, и люди из RedHat проходят несколько обручей, чтобы обеспечить это.

Мое первое предложение - вернуться к шагу, на котором вы установили python, и указать альтернативную установку. Что-то вроде:

• ./configure --enable-shared - prefix =/opt/python2.7 && & && & make && sudo make install

(примечание: --enable-shared специально не требуется... просто хорошая идея)

Второе предложение, которое я имею, связано с управлением пакетами python. Обычно мы будем использовать easy_install для установки pip. Как только у нас есть пипс, мы переходим к использованию pip для всего. Было бы интересно узнать, что произойдет на вашем последнем шаге. После активации вашего виртуального канала вы затем

• pip install elementtree

Еще одно предложение. После того, как вы установили python2.7, а затем установили virtualenv, pip и easy_install, вы должны иметь доступную версию этих сценариев. Возможно, лучше попробовать вызвать их и указать версию. Это устраняет любую двусмысленность в отношении запрашиваемой вами версии. например:

• virtualenv-2.7 virtpy
• pip-2.7 install elementtree
• easy_install-2.7 elementtree

Ответ 4

Вы пытались использовать коллекцию программного обеспечения? Это стандартный подход к RHEL для получения более современных пакетов, таких как python27:

http://developerblog.redhat.com/2013/08/08/software-collections-quickstart/

Затем, чтобы использовать python27, вы должны префикс всех своих команд python с помощью

scl enable python 

например. иметь bash с python27:

scl enable python27 bash

Эта настройка, возможно, будет иметь более совместимую среду.