Je cherche un environnement 'virtuel' ou j'aurais mon propre
perl et mes propres install de packages dans mon répertoire
UNIX alors qu'il existe déjà une version perl et des
packages sous l'OS.
Le but est de tester mes développements dans une
configuration donnée et ensuite de l'appliquer au perl
général sur la machine UNIX où je développe.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Gaborit
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC), Philippe Bouige écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre perl et mes propres install de packages dans mon r.pertoire UNIX alors qu'il existe d.j. une version perl et des packages sous l'OS. Le but est de tester mes d.veloppements dans une configuration donn.e et ensuite de l'appliquer au perl g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC),
Philippe Bouige <pbouige@bigoton.sis.pasteur.fr> écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre
perl et mes propres install de packages dans mon r.pertoire
UNIX alors qu'il existe d.j. une version perl et des
packages sous l'OS.
Le but est de tester mes d.veloppements dans une
configuration donn.e et ensuite de l'appliquer au perl
g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle
on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre
version (en spécifiant des répertoires d'installation spécifiques).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC), Philippe Bouige écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre perl et mes propres install de packages dans mon r.pertoire UNIX alors qu'il existe d.j. une version perl et des packages sous l'OS. Le but est de tester mes d.veloppements dans une configuration donn.e et ensuite de l'appliquer au perl g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Franck Aniere
Paul Gaborit a écrit :
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC), Philippe Bouige écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre perl et mes propres install de packages dans mon r.pertoire UNIX alors qu'il existe d.j. une version perl et des packages sous l'OS. Le but est de tester mes d.veloppements dans une configuration donn.e et ensuite de l'appliquer au perl g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et vit dans son environnement étanche. Il suffit ensuite de lancer le bon interpréteur (variable PATH positionnée correctement ou bonne valeur dans le #!) et lui ne bossera qu'avec ses packages (en plus le gestionnaire de packages PPM est plutôt bien foutu).
-- F.A.
Paul Gaborit a écrit :
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC),
Philippe Bouige <pbouige@bigoton.sis.pasteur.fr> écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre
perl et mes propres install de packages dans mon r.pertoire
UNIX alors qu'il existe d.j. une version perl et des
packages sous l'OS.
Le but est de tester mes d.veloppements dans une
configuration donn.e et ensuite de l'appliquer au perl
g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle
on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre
version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et vit
dans son environnement étanche. Il suffit ensuite de lancer le bon
interpréteur (variable PATH positionnée correctement ou bonne valeur
dans le #!) et lui ne bossera qu'avec ses packages (en plus le
gestionnaire de packages PPM est plutôt bien foutu).
À (at) Tue, 28 Apr 2009 13:56:11 +0000 (UTC), Philippe Bouige écrivait (wrote):
Je cherche un environnement 'virtuel' ou j'aurais mon propre perl et mes propres install de packages dans mon r.pertoire UNIX alors qu'il existe d.j. une version perl et des packages sous l'OS. Le but est de tester mes d.veloppements dans une configuration donn.e et ensuite de l'appliquer au perl g.n.ral sur la machine UNIX o. je d.veloppe.
Au moins deux possibilités :
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et vit dans son environnement étanche. Il suffit ensuite de lancer le bon interpréteur (variable PATH positionnée correctement ou bonne valeur dans le #!) et lui ne bossera qu'avec ses packages (en plus le gestionnaire de packages PPM est plutôt bien foutu).
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et vit dans son environnement étanche. Il suffit ensuite de lancer le bon interpréteur (variable PATH positionnée correctement ou bonne valeur dans le #!) et lui ne bossera qu'avec ses packages (en plus le gestionnaire de packages PPM est plutôt bien foutu).
C'est effectivement une troisième possibilité mais encore faut-il trouver la bonne version de ActivePerl : celle correspondant à sa propre version de glibc. Et si on souhaite compiler des packages inexistants en PPM, il faut aussi vérifier qu'on dispose de la même version de gcc que celle utilisée pour compiler ActivePerl. J'ai toujours trouvé cela contraignant. Si c'est tolérable sous Windows puisqe généralement on ne dispose pas de compilateur installé, sous Linux, j'ai toujours trouvé que compiler perl soi-même et installer les packages nécessaires via 'cpan' était plus simple et plus sûr.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle
on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre
version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et
vit dans son environnement étanche. Il suffit ensuite de lancer le bon
interpréteur (variable PATH positionnée correctement ou bonne valeur
dans le #!) et lui ne bossera qu'avec ses packages (en plus le
gestionnaire de packages PPM est plutôt bien foutu).
C'est effectivement une troisième possibilité mais encore faut-il
trouver la bonne version de ActivePerl : celle correspondant à sa
propre version de glibc. Et si on souhaite compiler des packages
inexistants en PPM, il faut aussi vérifier qu'on dispose de la même
version de gcc que celle utilisée pour compiler ActivePerl. J'ai
toujours trouvé cela contraignant. Si c'est tolérable sous Windows
puisqe généralement on ne dispose pas de compilateur installé, sous
Linux, j'ai toujours trouvé que compiler perl soi-même et installer
les packages nécessaires via 'cpan' était plus simple et plus sûr.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
- une machine virtuelle (VMWare, VirtualBox, Xen, etc.) sur laquelle on installe le même OS et la version de perl souhaitée.
- récupérer les sources de perl et compiler/installer sa propre version (en spécifiant des répertoires d'installation spécifiques).
Une troisième : le Perl d'ActiveState, qui s'installe où on veut et vit dans son environnement étanche. Il suffit ensuite de lancer le bon interpréteur (variable PATH positionnée correctement ou bonne valeur dans le #!) et lui ne bossera qu'avec ses packages (en plus le gestionnaire de packages PPM est plutôt bien foutu).
C'est effectivement une troisième possibilité mais encore faut-il trouver la bonne version de ActivePerl : celle correspondant à sa propre version de glibc. Et si on souhaite compiler des packages inexistants en PPM, il faut aussi vérifier qu'on dispose de la même version de gcc que celle utilisée pour compiler ActivePerl. J'ai toujours trouvé cela contraignant. Si c'est tolérable sous Windows puisqe généralement on ne dispose pas de compilateur installé, sous Linux, j'ai toujours trouvé que compiler perl soi-même et installer les packages nécessaires via 'cpan' était plus simple et plus sûr.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/> Perl en français - <http://perl.mines-albi.fr/>
Franck Aniere
Paul Gaborit a écrit :
C'est effectivement une troisième possibilité mais encore faut-il trouver la bonne version de ActivePerl : celle correspondant à sa propre version de glibc. Et si on souhaite compiler des packages inexistants en PPM, il faut aussi vérifier qu'on dispose de la même version de gcc que celle utilisée pour compiler ActivePerl. J'ai toujours trouvé cela contraignant. Si c'est tolérable sous Windows puisqe généralement on ne dispose pas de compilateur installé, sous Linux, j'ai toujours trouvé que compiler perl soi-même et installer les packages nécessaires via 'cpan' était plus simple et plus sûr.
C'est tout à fait vrai, je n'avais pas pensé aux modules non disponibles en PPM.
-- F.A.
Paul Gaborit a écrit :
C'est effectivement une troisième possibilité mais encore faut-il
trouver la bonne version de ActivePerl : celle correspondant à sa
propre version de glibc. Et si on souhaite compiler des packages
inexistants en PPM, il faut aussi vérifier qu'on dispose de la même
version de gcc que celle utilisée pour compiler ActivePerl. J'ai
toujours trouvé cela contraignant. Si c'est tolérable sous Windows
puisqe généralement on ne dispose pas de compilateur installé, sous
Linux, j'ai toujours trouvé que compiler perl soi-même et installer
les packages nécessaires via 'cpan' était plus simple et plus sûr.
C'est tout à fait vrai, je n'avais pas pensé aux modules non disponibles
en PPM.
C'est effectivement une troisième possibilité mais encore faut-il trouver la bonne version de ActivePerl : celle correspondant à sa propre version de glibc. Et si on souhaite compiler des packages inexistants en PPM, il faut aussi vérifier qu'on dispose de la même version de gcc que celle utilisée pour compiler ActivePerl. J'ai toujours trouvé cela contraignant. Si c'est tolérable sous Windows puisqe généralement on ne dispose pas de compilateur installé, sous Linux, j'ai toujours trouvé que compiler perl soi-même et installer les packages nécessaires via 'cpan' était plus simple et plus sûr.
C'est tout à fait vrai, je n'avais pas pensé aux modules non disponibles en PPM.
