Virtualenv: - alternatives relocalisables

Le drapeau relocalisable a toujours été expérimental et n'a jamais vraiment fonctionné; nous ne le supportons plus et la fonctionnalité a été entièrement abandonnée (d'où la version majeure). Expliquez votre cas d'utilisation et nous pourrons peut-être suggérer une approche alternative.

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

Ceci est un extrait de Dockerfile. Le code fonctionnera-t-il correctement si je supprime l'indicateur --relocatable? Autrement dit, je dois créer mon propre environnement isolé, que je peux copier de quelque manière que ce soit.

À l'intérieur d'un docker, je dirais que ce serait à 90%. Mais pour vous assurer que vous deviez contacter qui gère ce code docker, cela pourrait vraiment être dû à des différences subtiles dans la façon dont nous avons géré le transfert.

Nous avons parfois utilisé cette fonctionnalité parce que notre système CI créait des virtualenvs dans des répertoires avec des noms longs. Le nom serait suffisamment long pour que #! soit trop long et nous ne pouvons pas exécuter les scripts dans l'environnement.

@ Nitori- pour ces cas, il est recommandé d'utiliser le format python -m pour appeler les outils en général 🤔

C'est juste. Bien que de nombreux packages Python se comportent mal et ne se permettent pas d'être invoqués comme ça.

@ Nitori- même si c'est le cas, vous pouvez toujours forcer l'invocation en invoquant les exécutables via l'interpréteur python dans le dossier binaire; par exemple

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

où {venv} peut être arbitrairement long 👍

Dans mon entreprise, nous utilisons l'indicateur --relocatable dans nos pipelines pour nous aider à réutiliser un virtualenv et à gagner du temps - nous utilisons GitLab, construisons le virtualenv à un stade précoce, l'enregistrons comme un artefact, puis le réutilisons pour exécuter un tas de tests parallèles.

Nous avions l'intention d'épingler la version de virtualenv, mais à cause d'un bug, nous avons fini par extraire la dernière et nos pipelines se sont cassés ce matin. Nous avons corrigé ce bogue afin qu'il soit épinglé et que tout fonctionne maintenant, et nous trouverons un moyen de contourner le drapeau en cours de suppression. Mais je pensais que je noterais ici pour transmettre mon expérience même si le problème est clos et que je ne m'attends pas à ce que le drapeau soit soutenu à l'avenir.

Avec le nouveau semoir de données d'application, la création d'un virtualenv prend un peu moins de 100 ms, cette approche est préférée dans votre cas d'utilisation.

Nous utilisons --relocatable pour regrouper un venv dans un rpm. virtualenv est créé dans $ DESTDIR et finalement déplacé dans /opt/company .

C'est mon cas.

Cela aiderait-il donc à être en mesure de passer à l'avance la cible finale pour les chemins générés?

@gaborbernat oui!

@gaborbernat toujours, le virtualenv doit être utilisable pendant la phase de construction, avant le déploiement sur l'emplacement final.

Je ne sais pas quelle est la bonne solution ici 🤔 Je suis ouvert aux propositions.

@gaborbernat dans ce cas, le comportement standard est de distinguer builddir et prefix.

virtualenv a un argument DEST_DIR qui peut être trompeur dans ce cas. DEST_DIR est l'emplacement actuel de venv, qui est en fait un préfixe (tout comme / usr, / usr / local, etc.). Alors peut-être que documenter virtualenv LOCATION devrait rendre cela plus clair.

Ensuite, vous pouvez ajouter une option --destdir ou --root qui vaut par défaut / . De cette façon, virtualenv peut fonctionner isolé dans destdir (un peu comme un chroot). Je ne sais pas comment python, pip et d'autres scripts devront faire face à cela.

AFAIK le problème est que tous les scripts de console générés codent en dur le chemin lors de la création du shebang. Il n'y a pas de moyen standard de faire fonctionner ces scripts de console générés avec des shebangs à la fois pendant la construction et pendant l'exécution après le déploiement. C'est à moins qu'après la construction, quelqu'un répare les shebangs. Mais c'est désormais hors de portée de la création d'environnement virtuel, donc hors de notre contrôle.

@gaborbernat vous voulez dire que nous devrions implémenter cela dans setuptools? Quel shebang peut être utilisé à la fois isolé au moment de la construction et dans l'emplacement cible au moment de l'exécution?

Je pense à écrire un script virtualenv-relocate qui édite des shebangs sur un virtualenv existant, le rendant utilisable dans son nouvel emplacement. Quelque chose comme :

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

Je ne pense pas non plus que setuptools soit un bon endroit pour cela. C'est une fonctionnalité qui devrait faire partie du système de construction qui se construit à l'emplacement A, mais qui se déploie ensuite à l'emplacement B.

Eh bien, le projet C permet de construire isolé en éditant simplement PATH et LD_LIBRARY_PATH. Peu importe le système de construction que vous utilisez.

Je ne sais pas comment C y parvient, peut-être que quelqu'un peut expliquer, établir un lien vers cela? Ce qui s'est passé auparavant est ici https://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880 -L1894; nous avons essentiellement essayé de rendre certains chemins relatifs: à savoir les scripts et les fichiers pth / egg.

Mon référentiel utilise également --relocatable et j'utilise un script (après la création de l'environnement virtuel déplaçable) pour copier des bibliothèques supplémentaires sur le virtualenv. Avec cela, il était possible de créer virtualenv qui est entièrement relocalisable. Par exemple, nous l'utilisons sur Windows et ajoutons le virtualenv à notre programme d'installation. Après l'installation, les programmes python3 fonctionnent correctement avec le package virtualenv.

Le même cas d'utilisation fonctionne également sur mac et linux pour nous ...

@ Gagi2k ce que vous faites là-bas a déjà montré la fragilité de l'implémentation relocalisable actuelle; vous deviez faire des scripts supplémentaires après la création de l'environnement pour le rendre entièrement déplaçable. Le problème est de savoir comment rendre un package entièrement déplaçable dépend fortement de votre environnement cible. Donc, l'idée ici est que virtualenv lui-même renonce à essayer de rendre ses environnements entièrement déplaçables (car il ne peut pas réussir dans de nombreux cas) ... et délègue à la place le travail entièrement aux personnes qui écrivent ces scripts personnalisés, qui y parviennent; des scripts qui ont la connaissance de l'environnement cible, donc sachez exactement quoi et combien de changements sont nécessaires pour rendre quelque chose déplaçable.

C'est vrai, bon point.

Mon problème est plus ou moins que je dois maintenant recréer la fonctionnalité que vous avez fournie auparavant et la tester sur toutes les plates-formes + plusieurs distributions pour faire exactement la même chose que l'ancienne fonction.

Je pense que je vais essayer de m'en tenir à une ancienne version de virtualenv pour le moment jusqu'à ce que moi ou quelqu'un d'autre ait le temps de l'implémenter.

@ Gagi2k voir mon commentaire ci-dessus sur une idée de projet virtualenv-relocate . Je serai heureux de coopérer à ce sujet avec d'autres. https://github.com/spotify/dh-virtualenv/ peut être un bon point de départ.

@bersace thx, j'ai déjà copié l'ancien code maintenant et en ai créé un script python autonome. Je pense que je vais utiliser cela pour le moment comme une solution instantanée, mais je suis heureux de passer à autre chose à l'avenir ou de contribuer aux scripts que j'ai.

@ Gagi2k voudriez-vous le partager?

@bersace Le travail est toujours en cours: https://codereview.qt-project.org/c/qt/qtivi/+/290859

L'ensemble de la mise à jour de virtualenv 20 pose bien plus de problèmes que prévu. Réutiliser l'ancienne fonctionnalité pour rendre les scripts déplaçables n'est pas un gros problème, mais comme elle est maintenant basée sur venv et avec ce pyvenv.cfg, cela devient beaucoup plus compliqué. Par exemple, sous Windows, l'ancien virtualenv copiait de nombreux fichiers py de base sur/ lib / python(ou lié symboliquement). Maintenant, ils ne sont pas copiés du tout mais le pyvenv pointe simplement vers l'emplacement d'origine. Une fois l'emplacement d'origine mis à jour, votre virtualenv doit le gérer et vous devez espérer que tout ce dont vous avez besoin est toujours en place. Le problème encore plus grave est https://bugs.python.org/issue39469 , ce qui rend difficile de lui passer un emplacement relatif où vous configurez tout pour rendre le virtualenv déplaçable ...

Pour l'instant, je ne pense pas que cela puisse être fait (sans pyvenv.cfg le supportant).

@gaborbernat J'utilise peut-être virtualenv à mauvais escient pour ce qu'il est initialement prévu, mais quel est le moyen officiel de fournir votre propre copie python3 avec votre application, car vous souhaitez permettre aux gens de l'étendre à l'aide de pip?

@ Gagi2k Je suis sûr qu'il me manque quelque chose; mais ne pourriez-vous pas simplement modifier le pyenv.cfg hone dans le cadre de la phase d'installation sur une machine donnée?

@gaborbernat J'utilise peut-être virtualenv à mauvais escient pour ce qu'il est initialement prévu, mais quel est le moyen officiel de fournir votre propre copie python3 avec votre application, car vous souhaitez permettre aux gens de l'étendre à l'aide de pip?

Les environnements virtuels ont été conçus pour être toujours une référence à un interpréteur python sur une machine. L'hypothèse de base est que vous avez un environnement python entièrement fonctionnel sur la machine et que vous voulez juste avoir plusieurs site-packages séparés pour cela. Je peux voir qu'il est utile de rendre le lien pas entièrement explicite (comme c'est maintenant le cas avec le chemin entièrement explicite), mais si vous empruntez PyInstaller ou pex pour emballer votre code avec l'exécutable python d'avance, sans références faciles à casser?

@gaborbernat Bien sûr, cela fonctionnerait, le plus gros problème est que la plupart des utilisateurs ont l'habitude de pouvoir simplement renommer le dossier après l'installation et cela continue de fonctionner ...
Mais je viens de découvrir que le réglage de PYTHONHOME fait également l'affaire, au moins sur Windows, je l'ai fait fonctionner sans référence à l'installation d'origine.

pex semble intéressant et je vais regarder cela de plus près, merci pour l'indice.

@gaborbernat encore, comment construire un virtualenv dans un builddir et l'envoyer dans un .deb ou .rpm?

@gaborbernat Bien sûr, cela fonctionnerait, le plus gros problème est que la plupart des utilisateurs ont l'habitude de pouvoir simplement renommer le dossier après l'installation et cela continue de fonctionner ...

Je ne sais pas pourquoi ils s'attendent à cela. Cela n'a jamais été le cas; même avec le drapeau déplaçable, c'était vrai dans un sous-ensemble des cas possibles. D'où pourquoi il a été supprimé avec la v20.

@gaborbernat encore, comment construire un virtualenv dans un builddir et l'envoyer dans un .deb ou .rpm?

@bersace cela dépend de votre cas d'utilisation. Le deb / rpm garantit-il que python sera disponible au même emplacement sur la machine cible? Si c'est le cas, réparez simplement les chemins Shebang lors de l'installation 👍

@gaborbernat en fonction du système python est suffisant pour garantir que python se trouve à un emplacement spécifique.

Modifier les fichiers installés sur postinst est une très mauvaise idée. Cela nécessite d'exclure tous les scripts du domaine dpkg, donc dpkg ne les touchera pas lors de la mise à niveau. Ce n'est pas acceptable.

AFIAK, la meilleure solution serait un virtualenv-change-prefix qui édite tous les shebangs pour supprimer destdir , à exécuter avant d'archiver le paquet final.

@bersace et sur quoi

@gaborbernat l'emplacement cible absolu. par exemple #!/opt/company/app/venv/bin/python .

Cela impliquerait désormais que le déploiement de ce package sur un nouveau refroot autre que / n'est plus pris en charge, non?

@gaborbernat oui, par conception. Les fichiers gérés par dpkg / rpm ne doivent pas être déplacés par les utilisateurs.

C'est quelque peu différent de relocatable . Le but n'est pas de rendre venv relatif , mais de distinguer builddir (debian / build / ... ou% builddir) et rundir (/).

Clôture car il n'y a pas d'élément exploitable de notre côté. Je recommanderais de poursuivre la discussion ici, ou sur des projets potentiels qui tentent de résoudre ce problème en plus de virtualenv.

En fait, une alternative est quelque peu les dépendances de fournisseurs, sans les versionnage.

Dans mon cas, je dois compresser un package python avec les dépendances nécessaires et le transmettre comme `` archive '' à Spark on Yarn pour prendre en charge l'exécution de mon programme sur un cluster Spark distribué. Bien que cette opération puisse être terminée par Anaconda, le logiciel d'entreprise ne peut pas être utilisé dans mon entreprise. relocatable peut résoudre ce problème dans le passé, mais il a maintenant disparu.

Dans mon cas, je dois compresser un package python avec les dépendances nécessaires et le transmettre comme `` archive '' à Spark on Yarn pour prendre en charge l'exécution de mon programme sur un cluster Spark distribué. Bien que cette opération puisse être terminée par Anaconda, le logiciel d'entreprise ne peut pas être utilisé dans mon entreprise. relocatable peut résoudre ce problème dans le passé, mais il a maintenant disparu.

Salut @jackhhh , avez-vous trouvé une solution de contournement pour le cas d'utilisation existant?
Nous rencontrons le même problème.