Virtualenv: - перемещаемые альтернативы

Флаг возможности перемещения всегда был экспериментальным и никогда не работал; мы больше не поддерживаем его, и эта функция полностью исключена (отсюда и основной выпуск). Объясните свой вариант использования, и мы сможем предложить альтернативный подход.

CMD export branch && cd /build_dir && \
 apt-get update -y && apt-get upgrade -y && \
 pip3 install virtualenv && \
 virtualenv --always-copy --python=python3 env && \
 git clone http://user:pass@gitlab/dev/repo.git && \
 cd /build_dir/veil-repo/code/veil-common && \
 git checkout $branch && \
 python3 install.py -p /build_dir/veil-repo/code/cli-app/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/controller/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/node/ -v /build_dir/env && \
 cd /build_dir/ && \
 ./env/bin/pip3 install -r requirements.txt && \
 virtualenv --relocatable env

Это отрывок из Dockerfile. Будет ли код работать правильно, если я удалю флаг --relocatable? То есть мне нужно создать свою изолированную среду, которую я могу копировать любым способом.

Внутри докера я бы сказал 90%. Но чтобы убедиться, что вам нужно связаться с тем, кто поддерживает этот код докера, действительно могут быть тонкие различия в том, как мы обрабатываем перемещаемое.

Мы использовали эту функцию иногда, потому что наша система CI создавала виртуальные каталоги в каталогах с длинными именами. Имя было бы достаточно длинным, чтобы #! было бы слишком длинным, и мы не могли бы выполнять сценарии в env.

@ Nitori- для этих случаев рекомендуется использовать формат python -m для вызова инструментов в целом 🤔

Это честно. Хотя многие пакеты Python плохо себя ведут и не позволяют себя таким образом вызывать.

@ Nitori- даже если это так, вы всегда можете принудительно вызвать вызов, вызывая исполняемые файлы через интерпретатор python в двоичной папке; например

{venv}/bin/python {venv}/bin/bad-bad-tool

где {venv} может быть сколь угодно длинным 👍

В моей компании мы используем флаг --relocatable в наших конвейерах, чтобы помочь нам повторно использовать virtualenv и сэкономить время - мы используем GitLab, создаем virtualenv на раннем этапе, сохраняем его как артефакт, а затем повторно используем его для запуска куча параллельных тестов.

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

С новым средством заполнения данных приложения, создание virtualenv занимает чуть менее 100 мс, этот подход предпочтительнее в вашем случае использования.

Мы используем --relocatable для связывания venv в rpm. virtualenv создается в $ DESTDIR и, наконец, перемещается в /opt/company .

Это мой случай.

Так поможет ли возможность заранее передать конечную цель для созданных путей?

@gaborbernat да!

@gaborbernat тем не менее, virtualenv должен быть доступен на этапе сборки перед развертыванием в конечном месте.

Не уверен, какое здесь хорошее решение 🤔 Я открыт для предложений.

@gaborbernat для такого случая стандартным поведением является различение builddir и prefix.

virtualenv имеет аргумент DEST_DIR который в этом случае может вводить в заблуждение. DEST_DIR - это фактическое местоположение venv, которое фактически является префиксом (как / usr, / usr / local и т. Д.). Так что, возможно, документирование virtualenv LOCATION должно прояснить это.

Затем вы можете добавить параметр --destdir или --root который по умолчанию равен / . Таким образом, virtualenv может работать изолированно в destdir (что-то вроде chroot). Я не знаю, как python, pip и другие скрипты с этим справятся.

AFAIK проблема в том, что все сгенерированные скрипты консоли жестко кодируют путь во время создания для shebang. Не существует стандартного способа заставить эти сгенерированные скрипты консоли с шебангами в них работать как во время сборки, так и во время запуска после развертывания. То есть, если после сборки кто-то не исправит шебанги. Но сейчас это выходит за рамки возможностей создания виртуальной среды, поэтому вне нашего контроля.

@gaborbernat, вы имеете в виду, что мы должны реализовать это в setuptools? Какой shebang можно использовать как изолированно во время сборки, так и в целевом местоположении во время выполнения?

Я подумываю написать сценарий virtualenv-relocate который редактирует shebangs на существующем virtualenv, делая его пригодным для использования в новом месте. Что-то вроде :

$ virtualenv-relocate /build/dir/venv /opt/company/app/venv
Rewriting shebang of bin/pip.
Rewriting shebang of bin/pip3.5.
...
$

Я тоже не думаю, что setuptools - хорошее место для этого. Это функция, которая должна быть частью системы сборки, которая строится в местоположении A, но затем развертывается в местоположении B.

Ну, проект C позволяет создавать изолированные, просто редактируя PATH и LD_LIBRARY_PATH. Независимо от того, какую систему сборки вы используете.

Я не знаком с тем, как C достигает этого, может кто-нибудь объяснит, ссылку на это? То, что происходило раньше, находится здесь https://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880 -L1894; мы в основном пытались сделать некоторые пути относительными: а именно скрипты и файлы pth / egg.

В моем репозитории также используется --relocatable, и я использую сценарий (после создания перемещаемого виртуального окружения) для копирования дополнительных библиотек в virtualenv. Благодаря этому стало возможным создать virtualenv, который можно полностью перемещать. Например, мы используем это в Windows и добавляем virtualenv в наш установщик. После установки программы python3 нормально работают с упакованным файлом virtualenv.

Тот же сценарий использования также работает для нас на Mac и Linux ....

@ Gagi2k то, что вы там делаете, уже показало хрупкость текущей перемещаемой реализации; вам нужно было выполнить несколько дополнительных сценариев после создания env, чтобы сделать его полностью перемещаемым. Проблема в том, как сделать пакет полностью перемещаемым, сильно зависит от вашей целевой среды. Итак, идея здесь в том, что virtualenv сам отказывается от попыток сделать свои среды полностью перемещаемыми (так как во многих случаях это не может быть успешным) ... и вместо этого полностью делегирует работу людям, пишущим эти настраиваемые сценарии, которые достигают этого; скрипты, которые знают целевую среду, поэтому точно знают, что и сколько изменений необходимо, чтобы сделать что-то перемещаемым.

Верно, справедливо.

Моя проблема более или менее в том, что теперь мне нужно воссоздать функциональность, которую вы предоставляли ранее, и протестировать ее на всех платформах + нескольких дистрибутивах, чтобы сделать то же самое, что и старая функция.

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

@ Gagi2k см. Мой комментарий выше об идее проекта virtualenv-relocate . Я буду рад сотрудничать в этом с другими. https://github.com/spotify/dh-virtualenv/ может быть хорошей отправной точкой.

@bersace thx, я уже скопировал старый код и создал из него автономный скрипт Python. Думаю, что сейчас я воспользуюсь этим в качестве дополнительного решения, но я счастлив переключиться на что-то еще в будущем или внести свой вклад в имеющиеся у меня сценарии.

@ Gagi2k Не могли бы вы поделиться им?

@bersace Работа еще продолжается: https://codereview.qt-project.org/c/qt/qtivi/+/290859

Все обновление virtualenv 20 вызывает гораздо больше проблем, чем ожидалось. Повторное использование старых функций, позволяющих перемещать скрипты, не представляет большого труда, но поскольку теперь он основан на venv, а с этим pyvenv.cfg, он становится намного сложнее. Например, в Windows старый virtualenv скопировал много базовых файлов py в/ lib / питон(или связал его символической ссылкой). Теперь они вообще не копируются, а pyvenv просто указывает на исходное местоположение. После обновления исходного местоположения ваш virtualenv должен его обработать, и вам нужно надеяться, что все необходимое по-прежнему на месте. Еще более серьезная проблема - https://bugs.python.org/issue39469 , что затрудняет передачу ему относительного местоположения, в котором вы настраиваете все, чтобы сделать virtualenv перемещаемым ...

На данный момент я не думаю, что это можно сделать (без поддержки pyvenv.cfg).

@gaborbernat Я мог бы неправильно использовать virtualenv для того, что он изначально предполагал, но каков официальный способ предоставить вашу собственную копию python3 с вашим приложением, если вы хотите разрешить людям расширять ее с помощью pip?

@ Gagi2k Я уверен, что что-то упустил; но не могли бы вы просто изменить pyenv.cfg hone как часть фазы установки на данной машине?

@gaborbernat Я мог бы неправильно использовать virtualenv для того, что он изначально предполагал, но каков официальный способ предоставить вашу собственную копию python3 с вашим приложением, если вы хотите разрешить людям расширять ее с помощью pip?

виртуальные среды были разработаны, чтобы всегда быть ссылкой на некоторый интерпретатор python на машине. Базовое предположение состоит в том, что у вас есть полностью рабочая среда Python на машине, и вы просто хотите иметь для нее несколько отдельных site-packages . Я вижу некоторую ценность в том, чтобы сделать ссылку не полностью явной (как сейчас с полностью явным путем), но если вы идете по этому пути, почему бы просто не пройти весь путь и использовать либо PyInstaller, либо pex для упаковки вашего кода с исполняемый файл python заранее, без каких-либо простых ссылок?

@gaborbernat Конечно, это сработает, самая большая проблема в том, что большинство пользователей привыкли иметь возможность просто переименовать папку после установки, и она продолжает работать ...
Но я только что узнал, что настройка PYTHONHOME тоже помогает, по крайней мере, в Windows я заработал без ссылки на исходную установку.

pex выглядит интересно, и я посмотрю на него более внимательно, спасибо за подсказку.

@gaborbernat еще, как создать virtualenv в builddir и отправить его в .deb или .rpm?

@gaborbernat Конечно, это сработает, самая большая проблема в том, что большинство пользователей привыкли иметь возможность просто переименовать папку после установки, и она продолжает работать ...

Не знаю, почему они этого ждут. Такого не было; даже с флагом перемещения, это было верно в подмножестве возможных случаев. Следовательно, почему он был отключен с v20.

@gaborbernat еще, как создать virtualenv в builddir и отправить его в .deb или .rpm?

@bersace это зависит от вашего

@gaborbernat в зависимости от системного python достаточно, чтобы гарантировать, что python находится в определенном месте.

Модификация установленных файлов на postinst - очень плохая идея. Для этого нужно исключить все скрипты из области dpkg, поэтому dpkg не будет их трогать при обновлении. Это неприемлемо.

AFIAK, лучшим решением будет virtualenv-change-prefix который отредактирует все шебанги, чтобы удалить destdir , который будет выполняться перед архивированием окончательного пакета.

@bersace, а на что бы вы поставили шебанг?

@gaborbernat - абсолютное целевое местоположение. например, #!/opt/company/app/venv/bin/python .

Теперь это будет означать, что развертывание этого пакета в новом обновлении, отличном от / , теперь не поддерживается, не так ли?

@gaborbernat да, по замыслу. Файлы, управляемые dpkg / rpm, не должны перемещаться пользователями.

Это несколько отличается от relocatable . Цель не в том, чтобы сделать venv относительным , а в том, чтобы различать builddir (debian / build / ... или% builddir) и rundir (/).

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

Фактически, альтернатива - это несколько зависимостей от поставщика без управления версиями.

В моем случае мне нужно заархивировать пакет python с необходимыми зависимостями и передать его в качестве «архива» в Spark on Yarn для поддержки работы моей программы в распределенном кластере Spark. Хотя эта операция может быть завершена Anaconda, корпоративное программное обеспечение не может использоваться в моей компании. relocatable может решить эту проблему раньше, но теперь она исчезла.

В моем случае мне нужно заархивировать пакет python с необходимыми зависимостями и передать его в качестве «архива» в Spark on Yarn для поддержки работы моей программы в распределенном кластере Spark. Хотя эта операция может быть завершена Anaconda, корпоративное программное обеспечение не может использоваться в моей компании. relocatable может решить эту проблему раньше, но теперь она исчезла.

Привет @jackhhh , вы нашли обходной путь для существующего
Мы сталкиваемся с той же проблемой.