J'utilise Python 2.3.4 sur un serveur RedHat ainsi que les modules
Cherrypy 2.0. J'ai une bonne dizaine d'applications d=E9velopp=E9es avec
cette version. Mais la version 2.1 est sortie et comprend pas mal de
changements profonds.
Ma question est donc de savoir s'il est possible de faire cohabiter de
mani=E8re propre et pythonesque deux versions de cherrypy sur le m=EAme
serveur avec le m=EAme interpr=E9teur python ? Ceci afin d'=E9viter de
faire des modifications et revoir le code de la dizaine d'applications.
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
Olivier
Hello,
Ma question est donc de savoir s'il est possible de faire cohabiter de manière propre et pythonesque deux versions de cherrypy sur le même serveur avec le même interpréteur python ? Ceci afin d'éviter de faire des modifications et revoir le code de la dizaine d'applications.
Cherrypy s'importe baucoup lui-même, il n'est donc pas possible de renommer ta version 2.0 en cherrypy_temp, installer la 2.1 avec python setup.py install, renommer la 2.1 dans site-package en cherrypy2_1 et renommer cherrypy_temp en cherrypy.
Tu peux peut-être jouer avec les options de distutils. Peut-être...
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et vérification de la version).
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement.
Olivier
Hello,
Ma question est donc de savoir s'il est possible de faire cohabiter de
manière propre et pythonesque deux versions de cherrypy sur le même
serveur avec le même interpréteur python ? Ceci afin d'éviter de
faire des modifications et revoir le code de la dizaine d'applications.
Cherrypy s'importe baucoup lui-même, il n'est donc pas possible de
renommer ta version 2.0 en cherrypy_temp, installer la 2.1 avec python
setup.py install, renommer la 2.1 dans site-package en cherrypy2_1 et
renommer cherrypy_temp en cherrypy.
Tu peux peut-être jouer avec les options de distutils. Peut-être...
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans
lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit
avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et
vérification de la version).
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire
myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas
vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça
facilite le déploiement.
Ma question est donc de savoir s'il est possible de faire cohabiter de manière propre et pythonesque deux versions de cherrypy sur le même serveur avec le même interpréteur python ? Ceci afin d'éviter de faire des modifications et revoir le code de la dizaine d'applications.
Cherrypy s'importe baucoup lui-même, il n'est donc pas possible de renommer ta version 2.0 en cherrypy_temp, installer la 2.1 avec python setup.py install, renommer la 2.1 dans site-package en cherrypy2_1 et renommer cherrypy_temp en cherrypy.
Tu peux peut-être jouer avec les options de distutils. Peut-être...
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et vérification de la version).
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement.
Olivier
François
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement. Question d'ignare : qu'est-ce un "python stock" ?
François
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire
myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas
vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça
facilite le déploiement.
Question d'ignare : qu'est-ce un "python stock" ?
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement. Question d'ignare : qu'est-ce un "python stock" ?
François
Olivier
Hello,
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement.
Question d'ignare : qu'est-ce un "python stock" ?
Un horrible anglicisme :-) Je voulais dire un python de base, sans modules tiers installés dans site-package. Je fais une exception pour les modules qui contiennent des dll.
Olivier
Hello,
Pour mes applis web, j'ai tendance à mettre cherrypy dans un
répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API
n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python
stock, ça facilite le déploiement.
Question d'ignare : qu'est-ce un "python stock" ?
Un horrible anglicisme :-)
Je voulais dire un python de base, sans modules tiers installés dans
site-package. Je fais une exception pour les modules qui contiennent des
dll.
Pour mes applis web, j'ai tendance à mettre cherrypy dans un répertoire myapp/lib/vendor, avec les autres modules tiers dont l'API n'est pas vraiment stabilisée. Je peux ainsi tourner sur un python stock, ça facilite le déploiement.
Question d'ignare : qu'est-ce un "python stock" ?
Un horrible anglicisme :-) Je voulais dire un python de base, sans modules tiers installés dans site-package. Je fais une exception pour les modules qui contiennent des dll.
Olivier
Olivier
Sinon, je viens de m'apercevoir que ma réponse à la question de sir_highleaf fait presque doublon avec la réponse de William à la tienne (sujet : Gestion de version des bibliothèques)...
Olivier
Sinon, je viens de m'apercevoir que ma réponse à la question de
sir_highleaf fait presque doublon avec la réponse de William à la tienne
(sujet : Gestion de version des bibliothèques)...
Sinon, je viens de m'apercevoir que ma réponse à la question de sir_highleaf fait presque doublon avec la réponse de William à la tienne (sujet : Gestion de version des bibliothèques)...
Olivier
sir_highleaf
Bonjour,
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et vérification de la version).
Je crois que c'est la solution qui me convient le mieux.
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy print cherrypy.__version__ 2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le répertoire cherrypy (2.1), je fais ensuite :
import cherrypy print cherrypy.__version__ 2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que mon script utilise bien la version 2.1.0 et ne mélange pas avec la version 2.0.0 ?
Merci pour vos éclaircissements, j'ai lu le thread sur la gestion de versions de modules qui m'a apporté des informations complémentaires.
Cordialement,
Julien
Bonjour,
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans
lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit
avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et
vérification de la version).
Je crois que c'est la solution qui me convient le mieux.
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy
print cherrypy.__version__
2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le
répertoire cherrypy (2.1), je fais ensuite :
import cherrypy
print cherrypy.__version__
2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée
désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que
mon script utilise bien la version 2.1.0 et ne mélange pas avec la
version 2.0.0 ?
Merci pour vos éclaircissements, j'ai lu le thread sur la gestion de
versions de modules qui m'a apporté des informations complémentaires.
Sinon, copie juste le répertoire cherrypy du tar.gz quelque part (sans lancer setup.py, donc) et importe-le pour tes nouvelles applis, soit avec PYTHONPATH, soit avec des sys.path.insert(0, /yourpath) (et vérification de la version).
Je crois que c'est la solution qui me convient le mieux.
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy print cherrypy.__version__ 2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le répertoire cherrypy (2.1), je fais ensuite :
import cherrypy print cherrypy.__version__ 2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que mon script utilise bien la version 2.1.0 et ne mélange pas avec la version 2.0.0 ?
Merci pour vos éclaircissements, j'ai lu le thread sur la gestion de versions de modules qui m'a apporté des informations complémentaires.
Cordialement,
Julien
Olivier
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy print cherrypy.__version__ 2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le répertoire cherrypy (2.1), je fais ensuite :
import cherrypy print cherrypy.__version__ 2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que mon script utilise bien la version 2.1.0 et ne mélange pas avec la version 2.0.0 ?
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire courant précéde site-package dans sys.path. C'est pour ça que - dans le cas où ta librairie n'est pas déjà dans sys.path -, il faut préférer sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être sûr d'être prioritaire par rapport aux librairies homonymes déjà installées.
Concernant le mélange, je crois que le seul risque est si tu appelles un module (un filtre, par exemple) qui était défini dans la version 2.0 et pas dans la version 2.1. Dans ce cas, python ira le chercher là où il peut le trouver, c'est à dire dans ton site-package. Je n'ai pas vérifié si le cas est possible avec cherrypy.
Si tu as besoin de précisions, il y a :
http://groups.google.fr/group/cherrypy-users
Olivier
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy
print cherrypy.__version__
2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le
répertoire cherrypy (2.1), je fais ensuite :
import cherrypy
print cherrypy.__version__
2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée
désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que
mon script utilise bien la version 2.1.0 et ne mélange pas avec la
version 2.0.0 ?
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire courant
précéde site-package dans sys.path. C'est pour ça que - dans le cas où
ta librairie n'est pas déjà dans sys.path -, il faut préférer
sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être sûr
d'être prioritaire par rapport aux librairies homonymes déjà installées.
Concernant le mélange, je crois que le seul risque est si tu appelles un
module (un filtre, par exemple) qui était défini dans la version 2.0 et
pas dans la version 2.1. Dans ce cas, python ira le chercher là où il
peut le trouver, c'est à dire dans ton site-package. Je n'ai pas vérifié
si le cas est possible avec cherrypy.
J'ai sur le serveur la version 2.0 installée dans site-packages.
Dans mon nouveau répertoire d'application je fais :
import cherrypy print cherrypy.__version__ 2.0.0
Ok, c'est normal me direz-vous !
Dans mon nouveau répertoire de l'application j'ai donc mis le répertoire cherrypy (2.1), je fais ensuite :
import cherrypy print cherrypy.__version__ 2.1.0
Je considère à priori que c'est la version 2.1.0 qui est utilisée désormais avant la version 2.0.0. Ai-je raison ? Suis-je certain que mon script utilise bien la version 2.1.0 et ne mélange pas avec la version 2.0.0 ?
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire courant précéde site-package dans sys.path. C'est pour ça que - dans le cas où ta librairie n'est pas déjà dans sys.path -, il faut préférer sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être sûr d'être prioritaire par rapport aux librairies homonymes déjà installées.
Concernant le mélange, je crois que le seul risque est si tu appelles un module (un filtre, par exemple) qui était défini dans la version 2.0 et pas dans la version 2.1. Dans ce cas, python ira le chercher là où il peut le trouver, c'est à dire dans ton site-package. Je n'ai pas vérifié si le cas est possible avec cherrypy.
Si tu as besoin de précisions, il y a :
http://groups.google.fr/group/cherrypy-users
Olivier
sir_highleaf
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire coura nt précéde site-package dans sys.path. C'est pour ça que - dans le cas où ta librairie n'est pas déjà dans sys.path -, il faut préférer sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être s ûr d'être prioritaire par rapport aux librairies homonymes déjà instal lées.
C'est désormais clair pour moi, merci. J'avais déjà soumis ce genre de question sur cherrypy-users concernant la cohabitation de plusieurs versions de cherrypy mais elle n'a pas eu le succès attendu ;) J'ai fait quelques tests rapidement, je n'ai pas eu de soucis particuliers en testant les filtres (baseUrlFilter et decodingFilter).
Julien
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire coura nt
précéde site-package dans sys.path. C'est pour ça que - dans le cas où
ta librairie n'est pas déjà dans sys.path -, il faut préférer
sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être s ûr
d'être prioritaire par rapport aux librairies homonymes déjà instal lées.
C'est désormais clair pour moi, merci. J'avais déjà soumis ce genre
de question sur cherrypy-users concernant la cohabitation de plusieurs
versions de cherrypy mais elle n'a pas eu le succès attendu ;) J'ai
fait quelques tests rapidement, je n'ai pas eu de soucis particuliers
en testant les filtres (baseUrlFilter et decodingFilter).
Dans ton cas, 2.1 a la priorité sur 2.0 parce que le répertoire coura nt précéde site-package dans sys.path. C'est pour ça que - dans le cas où ta librairie n'est pas déjà dans sys.path -, il faut préférer sys.path.insert(0, /mypath) à sys.path.append(/mypath), pour être s ûr d'être prioritaire par rapport aux librairies homonymes déjà instal lées.
C'est désormais clair pour moi, merci. J'avais déjà soumis ce genre de question sur cherrypy-users concernant la cohabitation de plusieurs versions de cherrypy mais elle n'a pas eu le succès attendu ;) J'ai fait quelques tests rapidement, je n'ai pas eu de soucis particuliers en testant les filtres (baseUrlFilter et decodingFilter).
