J'ai vu ici ou l=C3=A0 mais sans les comprendre, malheureusement, des
discussions (passionn=C3=A9es) sur les pbs pos=C3=A9s par l'ajout dans Pyth=
on 3.4 du
logiciel pip et plus g=C3=A9n=C3=A9ralement par l'installation de logiciels=
en Python
par sudo pip install plut=C3=B4t que par apt-get.
Quelqu'un pourrait-il r=C3=A9sumer les enjeux et les avantages respectifs d=
es
deux m=C3=A9thodes, du point de vue d'un administrateur d'un syst=C3=A8me ?
Et du point de vue d'un d=C3=A9veloppeur de logiciels en Python, cela
change-t-il la donne ?
<div dir=3D"ltr"><div><div>Bonjour,<br><br></div>J'ai vu ici ou l=C3=A0=
mais sans les comprendre, malheureusement, des discussions (passionn=C3=A9=
es) sur les pbs pos=C3=A9s par l'ajout dans Python 3.4 du logiciel pip =
et plus g=C3=A9n=C3=A9ralement par l'installation de logiciels en Pytho=
n par sudo pip install plut=C3=B4t que par apt-get.<br>
<br></div><div>Quelqu'un pourrait-il r=C3=A9sumer les enjeux et les ava=
ntages respectifs des deux m=C3=A9thodes, du point de vue d'un administ=
rateur d'un syst=C3=A8me ?<br><br></div><div>Et du point de vue d'u=
n d=C3=A9veloppeur de logiciels en Python, cela change-t-il la donne ?<br>
<br></div><div>Par avance, merci pour vos lumi=C3=A8res.<br><br></div><div>=
Slts<br></div></div>
--047d7bf0d902e2fc4604fd4c6f85--
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/CAPeT9jgApOVrkY8DhSdzLzhHBcfgWHSWObbLUJp97B3Fm6JNaA@mail.gmail.com
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
Jean-Michel OLTRA
Bonjour,
Le jeudi 03 juillet 2014, Olivier a écrit...
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs des deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela change-t-il la donne ?
Résumer, je ne peux pas.
Mais un avantage sérieux, pour l'utilisateur et le développeur, c'est l'utilisation des environnements virtuels, virtualenv, qui permettent de ne pas "polluer" le système, et de tester différentes versions éventuellement.
-- jm
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Bonjour,
Le jeudi 03 juillet 2014, Olivier a écrit...
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs des
deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela
change-t-il la donne ?
Résumer, je ne peux pas.
Mais un avantage sérieux, pour l'utilisateur et le développeur, c'est
l'utilisation des environnements virtuels, virtualenv, qui permettent de
ne pas "polluer" le système, et de tester différentes versions
éventuellement.
--
jm
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140703164311.GC6274@espinasse
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs des deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela change-t-il la donne ?
Résumer, je ne peux pas.
Mais un avantage sérieux, pour l'utilisateur et le développeur, c'est l'utilisation des environnements virtuels, virtualenv, qui permettent de ne pas "polluer" le système, et de tester différentes versions éventuellement.
-- jm
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Haricophile
Le jeudi 03 juillet 2014 à 18:24 +0200, Olivier a écrit :
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs des deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela change-t-il la donne ?
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version récente, et probablement les modules pas (encore?) intégré à Debian, mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses préférences.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Le jeudi 03 juillet 2014 à 18:24 +0200, Olivier a écrit :
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs
des
deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela
change-t-il la donne ?
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version
récente, et probablement les modules pas (encore?) intégré à Debian,
mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de
sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses
préférences.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/1404406252.27651.12.camel@azuki.jisui
Le jeudi 03 juillet 2014 à 18:24 +0200, Olivier a écrit :
Quelqu'un pourrait-il résumer les enjeux et les avantages respectifs des deux méthodes, du point de vue d'un administrateur d'un système ?
Et du point de vue d'un développeur de logiciels en Python, cela change-t-il la donne ?
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version récente, et probablement les modules pas (encore?) intégré à Debian, mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses préférences.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Sébastien NOBILI
Bonjour,
Le jeudi 03 juillet 2014 à 18:50, Haricophile a écrit :
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version récente, et probablement les modules pas (encore?) intégré à Debian, mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses préférences.
Entièrement d'accord avec ce qui est écrit plus haut. C'est une question de choix : - un ou plusieurs gestionnaires de paquets; - des versions peut-être anciennes ou bien les toutes dernières.
Pour ma part, je refuse d'intégrer au niveau système (au sens géré par root) ce genre de gestionnaire de paquets. Dans mon environnement utilisateur, pourquoi pas, mais se pose après la question de la portabilité du code sur une autre machine qui aurait un environnement utilisateur différent (qui n'aurait pas les modules installés par pip ou équivalent).
La stratégie que j'ai mise en place est la suivante : - utilisation des paquets officiels pris dans les dépôts de la branche stable; - si besoin d'une version plus récente, rétroportage de la version de Sid; - si pas de paquet, alors je cherche un outil qui permet d'empaqueter ces modules (par exemple dans le cas de Perl, la commande dh-make-perl génère un fichier .deb à partir d'un module pris sur le CPAN).
Le troisième point le plus délicat car les passerelles de l'un à l'autre n'existent pas toujours et leur niveau n'est pas constant (dh-make-perl a atteint un bon niveau, par contre, pour empaqueter des modules Node-JS, pas encore trouvé d'outils qui me convienne).
Seb
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
Bonjour,
Le jeudi 03 juillet 2014 à 18:50, Haricophile a écrit :
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version
récente, et probablement les modules pas (encore?) intégré à Debian,
mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de
sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses
préférences.
Entièrement d'accord avec ce qui est écrit plus haut. C'est une question de
choix :
- un ou plusieurs gestionnaires de paquets;
- des versions peut-être anciennes ou bien les toutes dernières.
Pour ma part, je refuse d'intégrer au niveau système (au sens géré par root) ce
genre de gestionnaire de paquets. Dans mon environnement utilisateur, pourquoi
pas, mais se pose après la question de la portabilité du code sur une autre
machine qui aurait un environnement utilisateur différent (qui n'aurait pas les
modules installés par pip ou équivalent).
La stratégie que j'ai mise en place est la suivante :
- utilisation des paquets officiels pris dans les dépôts de la branche
stable;
- si besoin d'une version plus récente, rétroportage de la version de Sid;
- si pas de paquet, alors je cherche un outil qui permet d'empaqueter ces
modules (par exemple dans le cas de Perl, la commande dh-make-perl génère
un fichier .deb à partir d'un module pris sur le CPAN).
Le troisième point le plus délicat car les passerelles de l'un à l'autre
n'existent pas toujours et leur niveau n'est pas constant (dh-make-perl a
atteint un bon niveau, par contre, pour empaqueter des modules Node-JS, pas
encore trouvé d'outils qui me convienne).
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/20140704082602.GB13817@sebian.nob900.homeip.net
Le jeudi 03 juillet 2014 à 18:50, Haricophile a écrit :
A mon sens, et c'est vrai de ce type de système pour plusieurs softs :
pip ou équivalent = garantie d'avoir le module standard dans une version récente, et probablement les modules pas (encore?) intégré à Debian, mais il faut faire les mises à jour indépendamment du système.
apt = garantie d'avoir le module stable maintenu par les équipes de sécurité Debian et mis à jour avec le reste du système.
Après je suppose qu'on peut dire : À chacun ses besoins et ses préférences.
Entièrement d'accord avec ce qui est écrit plus haut. C'est une question de choix : - un ou plusieurs gestionnaires de paquets; - des versions peut-être anciennes ou bien les toutes dernières.
Pour ma part, je refuse d'intégrer au niveau système (au sens géré par root) ce genre de gestionnaire de paquets. Dans mon environnement utilisateur, pourquoi pas, mais se pose après la question de la portabilité du code sur une autre machine qui aurait un environnement utilisateur différent (qui n'aurait pas les modules installés par pip ou équivalent).
La stratégie que j'ai mise en place est la suivante : - utilisation des paquets officiels pris dans les dépôts de la branche stable; - si besoin d'une version plus récente, rétroportage de la version de Sid; - si pas de paquet, alors je cherche un outil qui permet d'empaqueter ces modules (par exemple dans le cas de Perl, la commande dh-make-perl génère un fichier .deb à partir d'un module pris sur le CPAN).
Le troisième point le plus délicat car les passerelles de l'un à l'autre n'existent pas toujours et leur niveau n'est pas constant (dh-make-perl a atteint un bon niveau, par contre, pour empaqueter des modules Node-JS, pas encore trouvé d'outils qui me convienne).
Seb
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: https://lists.debian.org/
