Comment puis-je installer des environnements spécialisés pour différentes applications Perl?

Question

Existe-t-il des fonctionnalités équivalentes ou proches de la virtualenv de Python , mais pour Perl?

J'ai réalisé quelques développements en Python et la possibilité de disposer de versions de modules non-système installées dans un environnement séparé sans créer de désordre est un énorme avantage. Maintenant, je dois travailler sur un nouveau projet à Perl, et je cherche quelque chose comme virtualenv, mais pour Perl. Pouvez-vous suggérer un équivalent Perl ou un remplacement pour virtualenv de python?

J'essaie de configurer X ensembles différents de packages Perl non système pour Y applications différentes à déployer. Pire encore, ces applications peuvent nécessiter différentes versions du même package et chacune d'entre elles peut donc nécessiter d'être installée dans un environnement module / bibliothèque séparé. Vous voudrez peut-être le faire manuellement pour X & Lt; Y & Lt; 3. Mais vous ne devriez pas le faire manuellement pendant 10 & Gt; Y & Gt; X.

Idéalement, ce que je recherche devrait fonctionner comme ceci:

perl virtualenv.pl my_environment
. my_environment/bin/activate
wget http://.../foo-0.1.tar.gz
tar -xzf foo-0.1.tar.gz ; cd foo-0.1
perl Makefile.pl
make install # <-- package foo-0.1 gets installed inside my_environment
perl -MCPAN -e 'install Bar' # <-- now package Bar with all its deps gets installed inside my_environment

Answer 1

Un outil appelé local::lib permet de terminer tout le travail effectué pour vous, un peu comme virtualenv. Cela va:

• Configurez @INC dans le processus où il est utilisé.
• Définissez PERL5LIB et d'autres éléments similaires pour les processus enfants.
• Définissez les bonnes variables pour convaincre CPAN, MakeMaker , Module::Build , etc. pour installer des bibliothèques et stocker la configuration dans un répertoire local.
• Définissez PATH afin que les fichiers binaires installés puissent être trouvés.
• Affiche les variables d’environnement sur stdout lorsqu’elles sont utilisées depuis la ligne de commande afin de pouvoir insérer eval $(perl -Mlocal::lib) dans votre .profile et puis surtout oublier à ce sujet.

Answer 2

Pendant mes recherches, j'ai découvert cette page et d'autres pages ( celle-ci est trop vieux et ignore les nouvelles technologies, ce post reddit est un légère erreur de direction ).

Le problème avec perlbrew et plenv est qu’ils semblent être des remplaçants de pyenv, pas de virtualenv. Comme indiqué ici , la gestion des versions de python est virtuelle pour gérer les versions de module par projet. Donc, oui, à certains égards, semblable à local :: lib , mais avec une meilleure convivialité.

Je n'ai pas encore trouvé de réponse satisfaisante à cette question, mais d'après ce que j'ai lu, il semble que la meilleure solution consiste à:

• Gestion des versions de Perl: plenv / perlbrew (avec la plupart des gens en privilégiant le plenv bash plus contemporain sur le perl perlbrew de ce que je peux voir)
• Gestion de la version du module: Carton
• Installation du module: cpan ( cpanminus de toute façon, ymmv)

Pour être honnête, ce n’est pas un idéal , même si je suis encore en train d’apprendre, c’est peut-être supérieur. Ça ne me semble pas juste. Ce n'est certainement pas un remplacement similaire pour virtualenv .

J'ai trouvé quelques articles disant & "; it est possible " mais ni l'un ni l'autre n'est allé plus loin.

Answer 3

Je ne suis pas sûr qu'il s'agisse de la même chose que virtualenv ce dont vous parlez, mais jetez un coup d'œil à la @INC variable spéciale de la perlvar page de manuel.

Answer 4

J'ai utilisé schroot à cette fin. Il est un peu plus lourd que virtualenv mais vous pouvez être sûr que rien ne coulera dans ce qui ne devrait pas.

Schroot gère un environnement chroot pour vous, mais monte votre répertoire personnel dans le chroot afin qu'il ressemble à une session shell normale, en utilisant simplement les fichiers binaires et les bibliothèques du chroot.

Je pense que cela peut être debian / ubuntu seulement si.

Après avoir configuré le <=>, votre script ci-dessus ressemblerait à

schroot -c my_perl_dev
wget ...

Voir http://www.debian-administration.org/articles/566 pour un article intéressant à ce sujet

Answer 5

Les programmes peuvent modifier les répertoires qu’ils vérifient pour les bibliothèques uwith use lib . Ce répertoire lib peut être relatif au répertoire en cours. Les bibliothèques de ces répertoires seront utilisées avant les bibliothèques système, car elles sont placées au début du tableau @INC.

Je pense que cpan peut également installer des bibliothèques dans des répertoires spécifiques. Certes, cpan tire du site CPAN afin d’installer des éléments, ce qui n’est peut-être pas la meilleure option.

Answer 6

Vérifiez également la perl-virtualenv , ce qui semble être un encapsulage local :: lib comme suggéré Hobbs, mais crée un bin / activate et un bin / deactivate afin que vous puissiez l'utiliser exactement comme l'outil python.

Je l'utilise assez bien depuis environ un mois sans me rendre compte que ce n'était pas aussi standard que cela devrait être.

Il est beaucoup plus facile de configurer un virtualenv fonctionnel pour perl, alors que local: lib vous indiquera les variables à définir, etc. perl-virtualenv crée un script d'activation qui le fait à votre place.

Answer 7

Ce que je fais est de démarrer le shell CPAN (cpan) et d’installer mon propre Perl 5.10 à partir de celui-ci. (Je crois que la commande est installer perl-5.10). Cela demandera différentes configurations réglages; Je m'assure de faire pointer les chemins sous / usr / local (ou un autre emplacement d'installation que celui par défaut).

Ensuite, je mets l'emplacement qui en résulte dans l'exécutable $ PATH avant le perl standard et j'utilise son shell CPAN pour installer les modules dont j'ai besoin (généralement beaucoup). Mes scripts Perl commencent tous par la ligne

#!/usr/bin/env perl

Jamais eu de problème avec cette approche.

Answer 8

Il semble que vous ayez juste besoin d'utiliser la configuration INSTALL_BASE pour Makefile.PL (ou l'option --install_base pour Build.PL)? Qu'avez-vous besoin de la solution pour vous? Il semble que vous ayez juste besoin de placer le module installé au bon endroit. Vous avez présenté votre problème en tant que problème XY en précisant ce que vous pensez être la solution est plutôt que de nous laisser vous aider dans votre tâche.

Voir Comment conserver mon propre répertoire de modules / bibliothèques? dans perlfaq8, par exemple.

Si vous téléchargez des modules depuis CPAN, la dernière cpan commande (dans App :: Cpan ) comporte un commutateur -j vous permettant de choisir d’autres fichiers de configuration CPAN.pm. Dans ces fichiers de configuration, vous pouvez définir les options de CPAN.pm à installer où bon vous semble.

Sur la base de votre clarification, il semble que local :: lib puisse fonctionner pour vous dans des cas simples et simples, mais je le fais pour les déploiements de niveau industriel où je configure des CPAN privés personnalisés par application et les installe directement à partir de ceux personnalisés. CPAN. Voir mon module MyCPAN :: App :: DPAN , par exemple. À partir de cela, j’utilise des configurations personnalisées CPAN.pm qui analysent leur environnement et définissent les valeurs appropriées pour chaque application. Elles peuvent tout installer dans un répertoire réservé à cette application.

Vous pouvez également envisager de distribuer votre application en tant que tâche ::. Vous l'installez comme n'importe quel autre module Perl, mais les dépendances partagent la même configuration (c'est-à-dire INSTALL_BASE).