Virtualenv relocatable - действительно ли это работает
Я продолжал искать ответ, но не нашел его.
У меня есть виртуальный env dir, проект dir с req.txt.
Когда я запускаю pip -r req.txt, он устанавливает некоторые приложения из github (source), а некоторые из pypi.
Те, что из pypi прекрасны после перемещаемого вызова виртуального evn, однако ссылки в пакетах сайтов для приложений, которые он установил из github, все еще указывают на расположение старого каталога.
Кто-нибудь еще видел это поведение? Любой быстрый способ вокруг него?
Кроме того, relocatable не соблюдает флаг -no-site-packages, который первоначально использовался на виртуальном сервере. Как только вы переместите виртуальную машину и активируете ее, все будет видно из системных пакетов сайта. Документы показывают это поведение как факт, поэтому мне интересно, есть ли какой-нибудь быстрый способ обойти это?
Ответы
Ответ 1
Как указано в документация --relocatable
является экспериментальной опцией, поэтому неудивительно, что у вас возникают трудности с ней. Тем не менее, вы не забыли перезапустить --relocatable
после установки новых пакетов? Если вы установили пакеты из github с помощью -e
, это может быть проблемой, так как оно не устанавливается в site-packages, а содержит символические ссылки. В качестве альтернативы использованию --relocatable
вы обычно можете удалить файлы, зависящие от virtualenv, и воссоздать их на месте (что я сделал пару раз при переключении между платформами).
Ответ 2
Нет, для одного '-relocatable' не обновляется 'virtualenv/bin/activate' script. Да, вы можете исправить это, перезапустив виртуальную настройку env, как было предложено zeekay, однако эти неподвижные файлы не могут импортировать любые установки "pip -e git...", которые помещаются в "virtualenv/src", поэтому вам придется повторно -run, которые устанавливаются вручную.
Из опыта теперь дней, которые я не устанавливаю с помощью pip editable (-e) и, если необходимо, вручную клонирует репозитории в 'project/src/' в отличие от 'project/virtualenv/src' и имеет auto_prep_pythonpath.py
script загружен до запуска моего проекта (я ссылаюсь на него в django.wsgi
script).
В качестве дополнительной заметки я добавляю "адаптированный" к любым пакетам, помещенным в "project/src", которые модифицируются/взломаны, поэтому таким образом мне не нужно беспокоиться о обратной совместимости, и я отслеживаю весь источник кода под управлением кода как онлайн репозитории могут и будут тормозить на вас.
Надеюсь, что это поможет.
"""
Prepares python path to include additional project/src/<APP> in PYTHONPATH - This file gets automatically loaded by projects __init__.py
This script lives in 'project/src/django-project/auto_prep_pythonpath.py', modify
'SOURCE_ROOT' if you place it somehwere else.
"""
import logging
import os
import sys
SOURCE_ROOT = os.path.dirname(os.path.abspath(__file__)).replace('\\','/') # the replacements are when on windows
SOURCE_ROOT = os.path.join(SOURCE_ROOT, '../').replace('\\','/')
SOURCE_ROOT = os.path.normpath(SOURCE_ROOT)
logger = logging.getLogger(__name__)
logger.info("Adding packages in 'src/*' required by project to PYTHONPATCH.")
dirlist_arr = os.listdir(SOURCE_ROOT)
while dirlist_arr:
item_path = os.path.join(SOURCE_ROOT, dirlist_arr.pop()).replace('\\','/') # replace dashes is for win based file system
if os.path.isdir(item_path):
if not item_path in sys.path:
sys.path.insert(0, item_path) # we use insert to take precedence over any global paths - minimises import conflict suprises
logger.debug("Path '%s' added." % item_path)