Bon, installer python sur windows c'est pas une sinécure ni
userfriendly.
J'essaye de tester les EDI/RAD :
http://python.developpez.com/comparatifs/editeurs/
1) ça été la misere pour utiliser ulipad a cause d'un msvcp71.dll pas
detecté alors que j'ai utilisé regserv. J'ai installé le VC 2005 free
pour que ça marche !!!
2) l'installation de boaconstructor est tres mal documenté. Plantage
lors d'acces à certain repertoire sur le reseau (à cause de repertoire
telque "lost+found"). La solution : boa.exe -O .boa-constructor-mine
-U iso8859-1
** make sure the development packages of libxml2 and libxslt are
installed **
Using build configuration of libxslt
warning: no files found matching 'lxml.etree.c' under directory
'src\lxml'
warning: no files found matching 'lxml.objectify.c' under directory
'src\lxml'
warning: no files found matching 'lxml.etree.h' under directory
'src\lxml'
warning: no files found matching 'lxml.etree_api.h' under directory
'src\lxml'
warning: no files found matching 'etree_defs.h' under directory
'src\lxml'
warning: no files found matching 'pubkey.asc' under directory 'doc'
warning: no files found matching 'tagpython*.png' under directory
'doc'
error: Setup script exited with error: Unable to find vcvarsall.bat
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
Michel Claveau - MVP
Salut !
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui travaillent essentiellement sous linux, et ne testent que brièvement certains modules sous Windows (et sans doute uniquement sur leur machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs, qui connaissent très bien Python, écrivent des choses fabuleuses, sous linux. Quand on leur pose la question de Windows, on s'entend répondre : "il ne doit pas y avoir de problème, grâce à la portabilité de Python". Malheureusement, ces constructions logicielles dépendent de modules, qui dépendent de librairies, qui dépendent d'autres choses, qui ont marché un jour, mais dont personne ne sait vraiment si ça fonctionne encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy, plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +. Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie a une dépendance à un module PyXML, qui ne fonctionne plus sous Windows. Sauf s'il avait été installé avant, et que l'on a fait des mises à jour de Windows. Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner sur la même machine. Mais ça ne marche pas avec des machines neuves (ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à faire une croix sur wxPython. Je veux parler de BOA. L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait. Quelques mois plus tard, pour installer un autre logiciel, j'avais du faire une mise à jour de wxWindows (dont dépend wxPython). Patatras ! BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples, il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances, et je souhaite bien du plaisir à ceux qui construisent des assemblages logiciels toujours plus complexes ...à maintenir.
@-salutations -- Michel Claveau
Salut !
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui
travaillent essentiellement sous linux, et ne testent que brièvement
certains modules sous Windows (et sans doute uniquement sur leur
machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs,
qui connaissent très bien Python, écrivent des choses fabuleuses,
sous linux. Quand on leur pose la question de Windows, on s'entend
répondre : "il ne doit pas y avoir de problème, grâce à la portabilité
de Python".
Malheureusement, ces constructions logicielles dépendent de modules,
qui dépendent de librairies, qui dépendent d'autres choses, qui ont
marché un jour, mais dont personne ne sait vraiment si ça fonctionne
encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs
XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client
SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy,
plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +.
Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie
a une dépendance à un module PyXML, qui ne fonctionne plus sous
Windows. Sauf s'il avait été installé avant, et que l'on a fait des
mises à jour de Windows.
Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner
sur la même machine. Mais ça ne marche pas avec des machines neuves
(ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à
faire une croix sur wxPython. Je veux parler de BOA.
L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait.
Quelques mois plus tard, pour installer un autre logiciel, j'avais du
faire une mise à jour de wxWindows (dont dépend wxPython). Patatras !
BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples,
il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances,
et je souhaite bien du plaisir à ceux qui construisent des assemblages
logiciels toujours plus complexes ...à maintenir.
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui travaillent essentiellement sous linux, et ne testent que brièvement certains modules sous Windows (et sans doute uniquement sur leur machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs, qui connaissent très bien Python, écrivent des choses fabuleuses, sous linux. Quand on leur pose la question de Windows, on s'entend répondre : "il ne doit pas y avoir de problème, grâce à la portabilité de Python". Malheureusement, ces constructions logicielles dépendent de modules, qui dépendent de librairies, qui dépendent d'autres choses, qui ont marché un jour, mais dont personne ne sait vraiment si ça fonctionne encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy, plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +. Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie a une dépendance à un module PyXML, qui ne fonctionne plus sous Windows. Sauf s'il avait été installé avant, et que l'on a fait des mises à jour de Windows. Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner sur la même machine. Mais ça ne marche pas avec des machines neuves (ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à faire une croix sur wxPython. Je veux parler de BOA. L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait. Quelques mois plus tard, pour installer un autre logiciel, j'avais du faire une mise à jour de wxWindows (dont dépend wxPython). Patatras ! BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples, il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances, et je souhaite bien du plaisir à ceux qui construisent des assemblages logiciels toujours plus complexes ...à maintenir.
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui travaillent essentiellement sous linux, et ne testent que brièvement certains modules sous Windows (et sans doute uniquement sur leur machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs, qui connaissent très bien Python, écrivent des choses fabuleuses, sous linux. Quand on leur pose la question de Windows, on s'entend répondre : "il ne doit pas y avoir de problème, grâce à la portabilité de Python". Malheureusement, ces constructions logicielles dépendent de modules, qui dépendent de librairies, qui dépendent d'autres choses, qui ont marché un jour, mais dont personne ne sait vraiment si ça fonctionne encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy, plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +. Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie a une dépendance à un module PyXML, qui ne fonctionne plus sous Windows. Sauf s'il avait été installé avant, et que l'on a fait des mises à jour de Windows. Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner sur la même machine. Mais ça ne marche pas avec des machines neuves (ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à faire une croix sur wxPython. Je veux parler de BOA. L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait. Quelques mois plus tard, pour installer un autre logiciel, j'avais du faire une mise à jour de wxWindows (dont dépend wxPython). Patatras ! BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples, il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances, et je souhaite bien du plaisir à ceux qui construisent des assemblages logiciels toujours plus complexes ...à maintenir.
@-salutations
MDR, ok. pour le problème de : Unable to find vcvarsall.bat C'est un truc de visualC, donc à installer.
Pour faire du python je vais laisser tomber sous windows et retourner sous linux.
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui
travaillent essentiellement sous linux, et ne testent que brièvement
certains modules sous Windows (et sans doute uniquement sur leur
machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs,
qui connaissent très bien Python, écrivent des choses fabuleuses,
sous linux. Quand on leur pose la question de Windows, on s'entend
répondre : "il ne doit pas y avoir de problème, grâce à la portabilité
de Python".
Malheureusement, ces constructions logicielles dépendent de modules,
qui dépendent de librairies, qui dépendent d'autres choses, qui ont
marché un jour, mais dont personne ne sait vraiment si ça fonctionne
encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs
XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client
SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy,
plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +.
Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie
a une dépendance à un module PyXML, qui ne fonctionne plus sous
Windows. Sauf s'il avait été installé avant, et que l'on a fait des
mises à jour de Windows.
Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner
sur la même machine. Mais ça ne marche pas avec des machines neuves
(ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à
faire une croix sur wxPython. Je veux parler de BOA.
L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait.
Quelques mois plus tard, pour installer un autre logiciel, j'avais du
faire une mise à jour de wxWindows (dont dépend wxPython). Patatras !
BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples,
il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances,
et je souhaite bien du plaisir à ceux qui construisent des assemblages
logiciels toujours plus complexes ...à maintenir.
@-salutations
MDR, ok.
pour le problème de :
Unable to find vcvarsall.bat
C'est un truc de visualC, donc à installer.
Pour faire du python je vais laisser tomber sous windows et retourner
sous linux.
Bienvenu dans l'enfer des dépendances, entretenu par des gens qui travaillent essentiellement sous linux, et ne testent que brièvement certains modules sous Windows (et sans doute uniquement sur leur machine de test) (et sans doute même cas avec Mac OS ou Symbian).
J'ai vu la même chose au PYCON_FR, cette année. Des développeurs, qui connaissent très bien Python, écrivent des choses fabuleuses, sous linux. Quand on leur pose la question de Windows, on s'entend répondre : "il ne doit pas y avoir de problème, grâce à la portabilité de Python". Malheureusement, ces constructions logicielles dépendent de modules, qui dépendent de librairies, qui dépendent d'autres choses, qui ont marché un jour, mais dont personne ne sait vraiment si ça fonctionne encore aujourd'hui.
Un exemple : quelqu'un expliquait comment écrire des composant serveurs XML-RPC et SOAP. Et a montré, entre autres, un petit exemple de client SOAP. J'ai vérifié pour Windows, il fallait installer le module SOAPy, plus maintenu depuis 2004, et qui ne fonctionne pas sur Py 2.5 et +. Cette librairie est remplacée par ZSI. Mais, cette nouvelle librairie a une dépendance à un module PyXML, qui ne fonctionne plus sous Windows. Sauf s'il avait été installé avant, et que l'on a fait des mises à jour de Windows. Autrement dit, ça a fonctionné un jour, et ça doit toujours fonctionner sur la même machine. Mais ça ne marche pas avec des machines neuves (ou récentes).
Autre cas, que je détecte dans ton message, et qui m'avait poussé à faire une croix sur wxPython. Je veux parler de BOA. L'idée m'avait semblé intéressante. Je l'avais installé. Et ça marchait. Quelques mois plus tard, pour installer un autre logiciel, j'avais du faire une mise à jour de wxWindows (dont dépend wxPython). Patatras ! BOA ne marchait plus ! Car, avec wx, en plus des dépendances simples, il y a des dépendances de versions.
Conclusion : maintenant, je limite le plus possible mes dépendances, et je souhaite bien du plaisir à ceux qui construisent des assemblages logiciels toujours plus complexes ...à maintenir.
@-salutations
MDR, ok. pour le problème de : Unable to find vcvarsall.bat C'est un truc de visualC, donc à installer.
Pour faire du python je vais laisser tomber sous windows et retourner sous linux.
jean-marc pouchoulon
Le 05/09/2010 08:31, Franck a écrit :
Bonjour
Bon, installer python sur windows c'est pas une sinécure ni userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows , "C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Cdt jmp
Le 05/09/2010 08:31, Franck a écrit :
Bonjour
Bon, installer python sur windows c'est pas une sinécure ni
userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows ,
"C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Bon, installer python sur windows c'est pas une sinécure ni userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows , "C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Cdt jmp
Franck
On Sun, 05 Sep 2010 17:52:37 +0200, jean-marc pouchoulon wrote:
Le 05/09/2010 08:31, Franck a écrit :
Bonjour
Bon, installer python sur windows c'est pas une sinécure ni userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows , "C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Cdt jmp
J'ai le même problème.
Bon ben je crois que je vais abandonner python. S'il y a trop de problème de compatibilité entre les OS, je prefere me retourner sur delphi + wine pour linux.
Bon, installer python sur windows c'est pas une sinécure ni
userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows ,
"C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Cdt
jmp
J'ai le même problème.
Bon ben je crois que je vais abandonner python.
S'il y a trop de problème de compatibilité entre les OS, je prefere me
retourner sur delphi + wine pour linux.
On Sun, 05 Sep 2010 17:52:37 +0200, jean-marc pouchoulon wrote:
Le 05/09/2010 08:31, Franck a écrit :
Bonjour
Bon, installer python sur windows c'est pas une sinécure ni userfriendly.
Bon ben j'ai pas terminé, j'y retourne.
Faut le vouloir !!!
Bonjour pour lxml
J'ai installé la 2.2.2 sous windows , "C:Python26Scriptseasy_install.exe" -U lxml==2.2.2
Cdt jmp
J'ai le même problème.
Bon ben je crois que je vais abandonner python. S'il y a trop de problème de compatibilité entre les OS, je prefere me retourner sur delphi + wine pour linux.
