J'ai une application Web orientée objet qui est installée dans plusieurs emplacements sur mon serveur. Une fois pour "Live", une fois pour "bêta", etc. Être orienté objet, il se compose de nombreux modules PERL. Dans le module principal, je dois "utiliser lib" le répertoire approprié pour tous les modules Perl personnalisés pour cette instance de l'application.
Ce n'est pas grave, j'ai un point de départ que Vérifie l'emplacement du programme principal et définit correctement le répertoire de la bibliothèque. Cependant, j'ai aussi beaucoup d'utilité, des programmes de ligne de commande qui doivent faire la même chose. Je ne veux pas couper et coller ce code partout.
Quel est le meilleur moyen de partager ce code de code parmi les différents programmes qui en ont besoin?
Je ne peux pas "utiliser", car le chemin de Libary n'est pas encore installé. Peut-être que "faire" ou "exiger" serait la bonne réponse, mais ceux-ci rechercheront-ils @Inc, ce qui est inapproprié.
peut-être quelque chose comme Voici le bloc de départ que J'utilise actuellement: merci! eval `chat getlib.pl`; serait approprié mais il semble genre de clunky et fragile.
5 Réponses :
Si vous exécutez un programme de la ligne de commande, ne définissez pas la liberme de manière programmatique: laissez-la simplement en tant qu'argument, par exemple: Pour votre application Web, pourquoi ne faites-vous pas votre bibliothèque par rapport à l'emplacement du script lui-même? Ensuite, installez-le sur chaque machine où vivent les bibliothèques. P> Perl -i / Emplacement / de / My / MyProg.plog. code>. use FindBin;
use File::Spec::Functions;
use Cwd qw(abs_path getcwd);
BEGIN {
my $curdir = getcwd;
my $selfdir = $FindBin::Bin;
my $libdir = abs_path(catdir($selfdir, 'lib'));
chdir $libdir or die "can't chdir to $libdir: $@";
use lib $libdir;
}
Votre première suggestion est trop peu fiable, je préférerais beaucoup être automatisée. La deuxième suggestion est plutôt bonne pour la webApp, mais je ne veux pas avoir à vous fier aux endroits codés durs de mes scripts de ligne de commande, qui vivent dans divers sous-répertoires sous * / Lib.
La raison pour laquelle je dois utiliser différents répertoires libérés est parce que le code exécuté sur le site est différent du code exécuté sur le site bêta ... c'est le point d'avoir un site bêta.
Si votre site "beta" est différent de votre site de production, vous devez la résoudre en premier. :)
Brian: Qu'est-ce que tu veux dire? Le site bêta est destiné à tester de nouvelles fonctionnalités, qui sont ensuite publiées sur le site en direct lorsque nous en sommes satisfaits.
@NXT: Votre site bêta n'est pas une grande partie de la bêta s'il a un comportement différent de ce qui sera poussé à la production.
Je suis désolé mais comment pouvez-vous ne pas obtenir cela? Le site bêta est nouveau code, testé. Lorsque nous avons fini de tester, il est copié (par Subversion) dans le répertoire du site en direct. Qu'est-ce qui pourrait éventuellement avoir tort avec ça?
Le code que vous avez montré semble raisonnable. Vous pouvez installer une copie de ce code dans un emplacement à l'échelle du système, puis le code pour l'appelerait à ébullition jusqu'à la forme de Au fur et à mesure que vous vouliez modifier beaucoup de choses autour de vous pourriez déployer l'application dans l'application Une manière qui serait plus amicale de local :: lib utilisation. nécessite qui prend Un nom de fichier ne recherche pas recherche @inc .
Votre réponse semble très logique. Je préfère garder le fichier sous contrôle source avec le reste du site, mais maintenant que j'y pense, il est parfaitement logique que celui-ci soit commun à tous les sites. Mon seul problème est que je devrai être très prudent lors de la modification de ce fichier, car il pourrait casser le site en direct. Mais je pense que c'est probablement la meilleure solution.
Les différents environnements pourraient avoir des paramètres différents pour la variable d'environnement $ perl5lib .
Merci, mais il s'agit d'ajouter le chemin pour les bibliothèques du programme, pas pour l'ensemble des bibliothèques Perl 5.
Vous pouvez définir Perl5Lib par processus. Cela n'a pas besoin d'être global.
Brian je sais que cela peut être défini par processus ... mais Perl5Lib est pour trouver les bibliothèques système, pas les bibliothèques personnalisées que vous avez écrites pour votre programme.
Perl remplit déjà @inc avec des chemins vers les bibliothèques système (à moins que quelque chose soit brisé). L'une des meilleures utilisations pour $ perl5lib est de spécifier des emplacements pour les bibliothèques non système.
Mobrule, merci d'avoir clarifié cela, j'ai manqué lors de mon premier regard sur Perl5Lib.
J'utilise ce qui suit dans beaucoup de mes scripts: cette dernière ligne pourrait être modifié comme tel:
Merci. Si vous regardez à nouveau mon code, vous remarquerez que je teste pour $ bin qui commence par un certain chemin, n'est pas un chemin certain. De cette façon, cela fonctionne, peu importe où le programme est sous cette voie.
Que diriez-vous de symboliser un répertoire relative lib à chaque répertoire libernel de niveau supérieur, alors?
Findbin :: Libs est excellent pour cela. Je l'ai utilisé pendant un certain temps dans un grand système sans aucun problème.
L'invocation par défaut semble fonctionner pour vous, simplement: p>
/home/w/myapp_live/scripts/lib /home/w/myapp_live/lib /home/w/lib /home/lib /lib # (presumably!)
C'est la meilleure réponse encore, je pense.
Comme je l'ai impliqué dans ma réponse, je pense que vous posez la mauvaise question ici, car vous rendez la vie plus difficile pour vous que cela ne devrait l'être. Votre code devrait résider dans le même chemin à tout moment - c'est dans votre système de contrôle de révision où vous différenciez le code «Live» et «Beta».
Ether: Comment le code LIVE et BETA peut-il résident dans le même chemin quand ils fonctionnent tous les deux sur le même serveur?
Search.cpan.org/perldoc/... ?