2016-08-08 3 views
1

Поэтому я использовал virtualenv, чтобы определить среду для ряда проектов, над которыми я работаю. Я определил python virtualenv как версию 3.4. В итоге мой глобальный питон был повышен с 3.4.0 до 3.4.3. Это оказалось проблемой, потому что virtualenv зависел от глобальных двоичных файлов (содержимое /lib/python3.4 в моем virtualenv фактически является просто ссылками на глобальные двоичные файлы), и они не определены до их младших версий. Другими словами, когда обновление было выполнено, содержимое двоичной папки /usr/lib/python3.4 было заменено. Это связано с тем, что python не устанавливает вещи отдельно в 3.4.0 и 3.4.3, а только в одну папку с именем /usr/lib/python3.4. Так как исполняемый файл python в моем virtualenv был 3.4.0, были очевидные проблемы с совместимостью с 3.4.3 двоичными файлами (он не смог бы загрузить ctypes, который предотвращал бы почти что-нибудь зависящее от запуска python). Единственное исправление, которое я нашел, - это понизить мою глобальную установку python, но это кажется «грязным». Что делать, если у меня был один проект под управлением 3.4.0 и еще один запуск 3.4.3? Нет ли способа заставить их работать параллельно на одном компьютере, учитывая, что для любой установки 3.4.x может существовать только одна двоичная папка?Я использую virtualenv неправильно или это ограничение?

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

В будущем, существует ли в любом случае сообщение virtualenvwrapper, чтобы скопировать двоичные файлы, а не ссылку на них?

+0

ли проблема с Python 3.4.3 несовместим с вашим кодом, или это просто virtualenv неудачи (воссоздающим virtualenv и переустанавливать все внутри исправляет его)? –

+0

Проблема не в моем коде. Даже просто загружать интерпретатор python внутри виртуального env не удастся всякий раз, когда я пытаюсь загрузить базовые библиотеки. Так что все идет не так хорошо, прежде чем детали моего кода войдут в картину. Это действительно о запуске исполняемого файла с неправильными двоичными файлами, связанными с ним. – ticster

+0

Что делать, если вы создаете новый virtualenv и запускаете Python 3.4.3? –

ответ

2

Virtualenvs не предназначались для переноски, как на машинах, так и на разных версиях Python.

Это означает, что обновление версий Python иногда прерывает virtualenvs. Вам необходимо обновить их и переустановить все внутри него (запустить это в корне virtualenv):

# Save a list of what you had installed 
pip freeze > freeze.txt 

# Trash the entire virtualenv 
deactivate 
rm -rf lib/ bin/ share/ man/ include/ .Python pip-selfcheck.json 

# Create it anew 
virtualenv . 

# Install all libraries you had before 
pip install -r freeze.txt 
+0

«Обновление версий Python иногда ломает virtualenvs». Это отвечает на мой вопрос. Я знаю, что я могу воссоздать каждый virtualenv индивидуально с обновленным python, но мне кажется, что это делает так, что в первую очередь поражает всю цель использования virtualenv ... Но если действительно обновление python прерывает virutalenv, тогда это похоже на что это серьезное ограничение. – ticster

+1

Virtualenvs не собирались быть портативными, как на машинах, так и на разных версиях Python. Это известный недостаток, но не побеждает его цель. –

+0

Gotcha. Я, тем не менее, так как это позволило вам указать, какую версию python использовать, что означало, что он должен был обрабатывать глобальное изменение в версиях python, сохраняя локально статический. Полагаю, что нет, и речь идет только об обработке версий внешнего модуля. Спасибо за помощь. Не могли бы вы добавить этот комментарий в ответ? Потому что это действительно зависит от того, что я прошу. Я могу принять ответ. – ticster

Смежные вопросы