Une petite question essentielle à laquelle je n'ai pas vraiment trouvé
de consensus pour la réponse : comment gérer les différentes versions
d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque
'toto', comment gérer l'installation de plusieurs versions concurrentes
en parallèle (i.e. comment structurer l'arborescence) et l'appel à la
bibliothèque dans les programmes ?
J'ai remarqué que wxPython utilise une sorte de script intermédiaire
pour réaliser cela, est-ce la méthode recommandée ?
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
R12y
On Mon, 28 Nov 2005 00:03:09 +0100, Francois wrote:
Bonjour,
Bonjour
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté un gros morceau) une nouvelle version est censée écraser|remplacer la précédente. Les (sales) habitudes de mettre des versions diffrentes en parellele sont apparues ces derniers temps parceque c'est un moment historique ou les logiciels évoluent énormément et que certains versions deviennent incompatibles avec les autres. Dans ces cas là, on installe les deux versions dans un répertoire d'installation différent et on renomme les binaires. Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous Debian...
On Mon, 28 Nov 2005 00:03:09 +0100, Francois wrote:
Bonjour,
Bonjour
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé
de consensus pour la réponse : comment gérer les différentes versions
d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté un
gros morceau) une nouvelle version est censée écraser|remplacer la
précédente.
Les (sales) habitudes de mettre des versions diffrentes en parellele sont
apparues ces derniers temps parceque c'est un moment historique ou les
logiciels évoluent énormément et que certains versions deviennent
incompatibles avec les autres.
Dans ces cas là, on installe les deux versions dans un répertoire
d'installation différent et on renomme les binaires.
Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous Debian...
On Mon, 28 Nov 2005 00:03:09 +0100, Francois wrote:
Bonjour,
Bonjour
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté un gros morceau) une nouvelle version est censée écraser|remplacer la précédente. Les (sales) habitudes de mettre des versions diffrentes en parellele sont apparues ces derniers temps parceque c'est un moment historique ou les logiciels évoluent énormément et que certains versions deviennent incompatibles avec les autres. Dans ces cas là, on installe les deux versions dans un répertoire d'installation différent et on renomme les binaires. Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous Debian...
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque 'toto', comment gérer l'installation de plusieurs versions concurrentes en parallèle (i.e. comment structurer l'arborescence) et l'appel à la bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package) et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure qu'elle n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
-- William Dodé - http://flibuste.net
On 27-11-2005, Francois wrote:
Bonjour,
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé
de consensus pour la réponse : comment gérer les différentes versions
d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque
'toto', comment gérer l'installation de plusieurs versions concurrentes
en parallèle (i.e. comment structurer l'arborescence) et l'appel à la
bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package)
et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script
sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure qu'elle
n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque 'toto', comment gérer l'installation de plusieurs versions concurrentes en parallèle (i.e. comment structurer l'arborescence) et l'appel à la bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package) et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure qu'elle n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
-- William Dodé - http://flibuste.net
Francois
On Mon, 28 Nov 2005 09:38:23 +0000 (UTC), William Dode
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque 'toto', comment gérer l'installation de plusieurs versions concurrentes en parallèle (i.e. comment structurer l'arborescence) et l'appel à la bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package) et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure qu'elle n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
Bonsoir,
Merci pour ton avis, mettre tout cela dans des répertoires différents est apparemment une des meilleures solutions, mais il manque un script pour gérer efficacement ensuite les appels de versions, j'ai choisi celui-là :
On Mon, 28 Nov 2005 09:38:23 +0000 (UTC), William Dode
Une petite question essentielle à laquelle je n'ai pas vraiment
trouvé de consensus pour la réponse : comment gérer les différentes
versions d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une
bibliothèque 'toto', comment gérer l'installation de plusieurs
versions concurrentes en parallèle (i.e. comment structurer
l'arborescence) et l'appel à la bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package)
et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script
sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure
qu'elle n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
Bonsoir,
Merci pour ton avis, mettre tout cela dans des répertoires différents
est apparemment une des meilleures solutions, mais il manque un script
pour gérer efficacement ensuite les appels de versions, j'ai choisi
celui-là :
On Mon, 28 Nov 2005 09:38:23 +0000 (UTC), William Dode
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
Supposons que je mette à disposition de la communauté une bibliothèque 'toto', comment gérer l'installation de plusieurs versions concurrentes en parallèle (i.e. comment structurer l'arborescence) et l'appel à la bibliothèque dans les programmes ?
Tu les places dans des répertoires différents (pas dans site-package) et tu joue avec sys.path pour déterminer lesquelles tu veux utiliser.
par ex en début de script sys.path.insert(0,"/.../.../malib-0.1")
oubien tu copie ta lib dans le répertoire courant et tu t'assure qu'elle n'est pas ailleur dans le path
et pour être sur assert (monmodule.__version__ == "0.1")
Bonsoir,
Merci pour ton avis, mettre tout cela dans des répertoires différents est apparemment une des meilleures solutions, mais il manque un script pour gérer efficacement ensuite les appels de versions, j'ai choisi celui-là :
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté un gros morceau) une nouvelle version est censée écraser|remplacer la précédente. Les (sales) habitudes de mettre des versions diffrentes en parellele sont apparues ces derniers temps parceque c'est un moment historique ou les logiciels évoluent énormément et que certains versions deviennent incompatibles avec les autres. Dans ces cas là, on installe les deux versions dans un répertoire d'installation différent et on renomme les binaires. Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous Debian...
Bonsoir,
Ce n'est pas forcément une mauvaise habitudes d'avoir plusieurs versions en parallèle. Ce qui coûte le plus cher dans mon entreprise n'est pas tant le développement ou la maintenance du code mais plutôt sa validation (certains vont même parler de certification). Dans ces cas-là, le code est validé avec certaines bibliothèques et sur une architecture bien précise. On ne peut pas changer de version sans refaire toute la validation ce qui est très long et pénible, c'est pourquoi l'on souhaite avoir plusieurs versions en parallèle le temps de valider proprement...
Je suis aussi sous Debian et j'aime assez leur système de gestion des versions. Cependant le système qu'a adopté wxPython me semble plus séduisant :
Une petite question essentielle à laquelle je n'ai pas vraiment
trouvé de consensus pour la réponse : comment gérer les différentes
versions d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté
un gros morceau) une nouvelle version est censée écraser|remplacer la
précédente.
Les (sales) habitudes de mettre des versions diffrentes en parellele
sont apparues ces derniers temps parceque c'est un moment historique
ou les logiciels évoluent énormément et que certains versions
deviennent incompatibles avec les autres.
Dans ces cas là, on installe les deux versions dans un répertoire
d'installation différent et on renomme les binaires.
Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous
Debian...
Bonsoir,
Ce n'est pas forcément une mauvaise habitudes d'avoir plusieurs
versions en parallèle.
Ce qui coûte le plus cher dans mon entreprise n'est pas tant le
développement ou la maintenance du code mais plutôt sa validation
(certains vont même parler de certification).
Dans ces cas-là, le code est validé avec certaines bibliothèques et sur
une architecture bien précise.
On ne peut pas changer de version sans refaire toute la validation ce
qui est très long et pénible, c'est pourquoi l'on souhaite avoir
plusieurs versions en parallèle le temps de valider proprement...
Je suis aussi sous Debian et j'aime assez leur système de gestion des
versions. Cependant le système qu'a adopté wxPython me semble plus
séduisant :
Une petite question essentielle à laquelle je n'ai pas vraiment trouvé de consensus pour la réponse : comment gérer les différentes versions d'une bibliothèque ?
D'une manière générale, en programmation (sauf si j'ai vraiment raté un gros morceau) une nouvelle version est censée écraser|remplacer la précédente. Les (sales) habitudes de mettre des versions diffrentes en parellele sont apparues ces derniers temps parceque c'est un moment historique ou les logiciels évoluent énormément et que certains versions deviennent incompatibles avec les autres. Dans ces cas là, on installe les deux versions dans un répertoire d'installation différent et on renomme les binaires. Un bon exemple est zope2.7, zope2.8, python2.3 python2.4 sous Debian...
Bonsoir,
Ce n'est pas forcément une mauvaise habitudes d'avoir plusieurs versions en parallèle. Ce qui coûte le plus cher dans mon entreprise n'est pas tant le développement ou la maintenance du code mais plutôt sa validation (certains vont même parler de certification). Dans ces cas-là, le code est validé avec certaines bibliothèques et sur une architecture bien précise. On ne peut pas changer de version sans refaire toute la validation ce qui est très long et pénible, c'est pourquoi l'on souhaite avoir plusieurs versions en parallèle le temps de valider proprement...
Je suis aussi sous Debian et j'aime assez leur système de gestion des versions. Cependant le système qu'a adopté wxPython me semble plus séduisant :
