Я пишу скрипт bash для установки только что установленной Ubuntu VM в качестве машины для разработки и тестирования с Django и gUnicorn в виртуальной среде. Он успешно устанавливает пакеты с apt-get, но затем, когда я запускаю pip рекурсивно против файла requirements.txt, он не может найти ни один из пакетов. Я попытался вручную активировать виртуальную среду и запустить pip install == Это сработало нормально, и пип начал говорить, что Django уже установлен, но затем не удалось с другими. Я пробовал –pre и –no-index безрезультатно. Однако -no-index избавляет от невероятно огромной (3000+ строки) Traceback, который он печатал.
Вот сценарий:
# VARIABLES
# none for now
# COLORED OUTPUT
function echo_green {
tput setaf 2
echo $1
tput sgr0
}
function echo_yellow {
tput setaf 3
echo $1
tput sgr0
}
function echo_red {
tput setaf 1
echo "Important Note: $1"
tput sgr0
}
function echo_blue {
tput setaf 4
echo $1
tput sgr0
}
# TODO: Create output like script <filename> ran on <date>
# TODO: Have output go to file as well as stdout
# GLOBAL PACKAGES
echo_green 'Doing System level installs'
echo_green 'Using sudo'
# ubuntu and debian have apt-get
echo_green 'vim'
sudo apt-get install vim
echo_green 'tmux'
sudo apt-get install tmux
echo_green 'pip'
sudo apt-get install python-pip
echo_green 'virtualenv'
sudo easy_install virtualenv
echo_green 'git'
sudo apt-get install git
# CLONE REPO
echo_yellow "Working as user: 'whoami'"
echo_yellow "working in 'pwd'"
echo_yellow "cloning Services repo"
git clone <our repo>
# CREATE VIRTUAL ENVIRONMENT
# hard coding file names to simplify discussion between devs referring to certain directories and files
mkdir Environment
echo 'Environment/' >> .gitignore
virtualenv Environment
echo_blue "Activating virtual environment"
source ./Environment/bin/activate
echo_green 'Installing distribute in virtual env'
sudo easy_install 'distribute==0.6.28'
echo_yellow "If pip tries to install a specific version of something, this can be a mess if it already installed. Use pip uninstall first. Do not install with anything but pip if possible. Use pip in virtual env. Anything else has potential for mess making and bug hiding."
# TODO: make sure python is v 2.7.5
# Note the lack of sudo. This is related to virtualenv. We're not doing this globally.
# pip install --upgrade pip
easy_install --upgrade pip
pip install -r ./Services/requirements.txt --pre # --no-index might solve some errors
# mysqlclient-dev
# mysql server?
# then put the dump into it
Ошибка:
Использование /home/bret/Work/Environment/lib/python2.7/site-packages/pip-1.5.2-py2.7.egg Обработка зависимостей для pip Завершенные зависимости обработки для pip Игнорирование индексов: https://pypi.python.org/simple/ Требование уже выполнено (используйте –upgrade для обновления): Django == 1.5.1 in./Environment/lib/python2.7/site-packages (из -r./Services/requirements.txt( строка 1)) Загрузка/распаковка Fabric == 1.7.0 (из -r./Services/requirements.txt (строка 2)) Не удалось найти загрузки, удовлетворяющие требованию Fabric == 1.7.0 (из -r./Services/requirements.txt (строка 2)) Очистка… Никаких распределений вообще не найдено для Fabric == 1.7.0 (из -r./Services/requirements.txt (строка 2)) Сохранение журнала отладки для сбой в /home/bret/.pip/pip.log
Пара подсказок:
pip install "Django==1.5.1"
pip install "distribute==0.6.28"
cat Services/requirements.txt | sed '/distribute/d' | sed '/distribute/d' > .requirements_tmp.txt
pip install -r .requirements_tmp.txt --use-mirrors --pre --no-index #might solve some errors
rm .requirements_tmp.txt
Это работает для пакетов, явно заданных собственной линией. Он использует sed, чтобы удалить их из временной копии требований, которые затем выполняются. По какой-то причине использование -r приводит к тому, что пип не находит ничего
Я уже пробовал флаги: –pre –no-index –use-mirror
Я также пробовал обновлять и обновлять Ubuntu
Убедись, что
-
Пакет фактически существует и не удаляется (первое правило PyPi – это то, что никогда не удаляйте пакеты). См. Простой индекс https://pypi.python.org/simple/
-
Нет системного пакета, версия которого конфликтует с virtualenv без
--no-site-packages
. -
Проблемы с чувствительностью к регистру с именем пакета