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

Существует ряд других вопросов StackOverflow, похожих на этот, но в каждом случае платформа была другой или сообщение об ошибке было другим или решение не имело эффекта или устарело. Я пытаюсь настроить Python 2.7.6 virtualenv и установить в него модули, но easy_install дает мне ошибки, указывающие на то, что setuptools недоступен. Но AFAIK easy_install является частью setuptools, поэтому это не имеет смысла.

Проблема возникает только в virtualenv. Вот что я сделал:

Создана новая виртуальная машина Red Hat 5.
Помог ли yum -y update получить последний материал, перезагрузился
Загруженный Python-2.7.6.tar.gz, unzipped, ./configure; make; sudo make install
Подтверждено, что python -V дает мне 2.7.6, а sudo python -V также дает мне 2.7.6
wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py
Изменено ez_setup.py, чтобы добавить флаг --no-check-certificate в wget, чтобы обойти проблемы с прокси-сервером в нашей сети.
sudo python ez_setup.py
sudo easy_install pip
sudo pip install virtualenv
virtualenv virtpy
. virtpy/bin/activate
easy_install elementtree

Все эти шаги успешны, за исключением последнего, который не выполняется:

Traceback (most recent call last):
  File "/home/gperrow/virtpy/bin/easy_install", line 7, in <module>
    from setuptools.command.easy_install import main
  File "/home/gperrow/virtpy/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 44, in <module>
    from setuptools.package_index import PackageIndex
  File "/home/gperrow/virtpy/lib/python2.7/site-packages/setuptools/package_index.py", line 203, in <module>
    sys.version[:3], require('setuptools')[0].version
  File "/usr/local/bin/scripts/pkg_resources.py", line 584, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/local/bin/scripts/pkg_resources.py", line 482, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: setuptools

Я начинаю с чистой виртуальной машины, и я не делал ничего необычного, но я нашел "easy_install" ничего, кроме. Я что-то делаю неправильно, или я пропустил один или несколько шагов?

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

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