Faire un .exe pour Python 3.6 et Tkinter

erreur du fait de l'absence d'un chemin pour TCL-LIBRARY

a marqué ce sujet comme résolu.
Auteur du sujet

Je suis sous Windows 7, avec Pythpon 3.6.
J’utilise wx_freeze (5.0.2) afin de pouvoir diffuser facilement une petite application.
Au premier essai, j’ai eu une erreur concernant le chemin pour TCL_LIBRARY.
Solution pour m’en sortir (sur la console):

1
2
set TCL_LIBRARY=C:\Python36\tcl\tcl8.6
set TK_LIBRARY=C:\Python36\tcl\tk8.6

Ensuite, je fais setup build

En plus, il faut recopier les DLL tcl86t.dll et tk86t.dll depuis c:\Python36\dll

Édité par etherpin

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0

Salut,

La manière standard de distribuer ton projet Python, c’est soit de faire un package PyPI, soit simplement de distribuer les sources accompagées du setup.py qui va bien.

C’est beaucoup plus simple et propre que d’utiliser wx_freeze et autre consorts.

I don’t mind that you think slowly, but I do mind that you are publishing faster. – W. Pauli

+1 -0
Auteur du sujet

Merci, adri1.

Si j’ai bien compris, PyPI s’adresse à des utilisateurs de Python non ?

Il s’agit de pouvoir faire marcher mon projet sur une machine qui n’a pas Python installé.

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0

Salut,

À moins de travailler sur un système ultra-fermé (auquel cas il y a de fortes chances pour que tu aies des contraintes telles que tu ne peux pas coder en Python de toute façon), la façon propre de procéder est de demander à l’utilisateur final d’installer Python puis d’installer ton projet.

Les outils du genre de cx_freeze embarquent l’interpréteur Python de toute façon, donc l’intérêt de s’en servir est proche de zero.

I don’t mind that you think slowly, but I do mind that you are publishing faster. – W. Pauli

+0 -0
Auteur du sujet

Salutations,

Je ne vois pas bien pourquoi il faudrait demander à l’utilisateur d’installer Python 3.6, si il n’en a pas l’usage. Je ne sais pas justifier les avantages de cette exigence.
Quoi qu’il en soit, j’ai là une application portable que je peux exécuter ou installer depuis ma clé USB sur un PC qui n’a pas Python ou encore sur un PC qui n’aurait pas la même version de Python.

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0

Je ne vois pas bien pourquoi il faudrait demander à l’utilisateur d’installer Python 3.6

Quand tu achètes un jeu, tu installes l’environnement du jeu sur ton disque dur puis exécutes le fichier de démarrage ou tu exécutes directement le jeu à partir du fichier exe ?

Là c’est pareil, c’est à l’utilisateur de décider si il souhaite avoir python parmi ces environnements pour exécuter tels ou tels fichiers py. Exécuter un fichier exe en faisant juste confiance, ça devient de moins en moins courant.

Dans le cas où tu souhaites continuer à vouloir créer un exécutable, tu peux compiler un fichier .c créé par cython. Pour ça tu utilises un compilateur, par exemple le plus courant reste les outils de Visual Studio…

J’avais testé cette page avec succès

Avec Cython

On transforme le fichier Python en C

cython main.py -o supershape.c –embed

On compile le C avec Visual Studio et son compilateur

cl.exe /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ic:\Python27\include -Ic:\Python27\PC /supershape.c /link /OUT:"supershape.exe" /SUBSYST

Bonne continuation…

+0 -0

Je ne vois pas bien pourquoi il faudrait demander à l’utilisateur d’installer Python 3.6, si il n’en a pas l’usage. Je ne sais pas justifier les avantages de cette exigence.

Ben il en aura l’usage pour faire tourner ton programme. Python devient tellement courant que demander de l’installer n’a rien de dramatique ni d’obscur, je préfère le type qui me dit "installe Python/ruby/java/autre parce que mon script en a besoin" plutôt que celui qui me dit "t’inquiètes, ya tout dans cette archive de 300 M qui contient des trucs que t’as déjà installé et prend de la place pour rien, mais t’a plus qu’a cliquer dessus".

Quoi qu’il en soit, j’ai là une application portable que je peux exécuter ou installer depuis ma clé USB sur un PC qui n’a pas Python ou encore sur un PC qui n’aurait pas la même version de Python.

C’est pas comme si c’était compliqué d’assurer que le code est compatible e.g. avec Python 3.4, 3.5 et 3.6 plutôt qu’une seule version de Python. Après, si tu y tiens vraiment, tu peux aussi installer Python sur une clé USB et te trimballer avec, mais je suis pas sûr d’en voir l’intérêt.

I don’t mind that you think slowly, but I do mind that you are publishing faster. – W. Pauli

+1 -0
Auteur du sujet

Je vous remercie pour vos conseils avisés. J’y réfléchirai pour mon prochain projet.

Côté volume, j’ai de la chance, mon archive ne fait que 37,8 Mo, et encore, je pense qu’avec des import plus fins, on pourrait faire mieux. Mais je suis bien d’accord que, si on généralisait cette façon de faire, on aboutirait à une situation sous-optimale.

Python n’est pas si répandu que cela sur PC Windows. Si je compte les PC dans ma famille et mes proches, soit une dizaine, il n’y a que le mien qui ait Python. Aucun n’a Runby, ni Java. Y’en a bien un qui a Visual Studio Community, mais c’est pour faire du C#.

Je ne suis demandé si je ne devais pas développer directement en Python avec Visual Studio Community (en fait, je reprend un petit projet Visual Basic). Mais au final, cela donnait un exécutable assez important aussi, associé à une certaine lourdeur d’installation. C’est très bien pour un projet assez complexe, mais le mien qui est très simple n’a pas besoin d’options subtiles.

J’aurais donc pu développer en Python 3.x sur Visual Studio et générer in fine un .exe. Cela me semble plus simple que de compiler du C généré à partir de Python.

Bien sûr, j’aurais préféré faire mes GUI dans Visual Studio, mais cela ne marche qu’avec Python 2.7. Or, pas de chance, j’ai besoin de Python 3.x car mon appli est destinée à traiter des textes en UTF8. Je ne voulais pas encombrer mon code et mes quelques neurones avec des encode/decode. En effet,même un débutant comme moi sait que "Simple is better than complex."

Édité par etherpin

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0

Côté volume, j’ai de la chance, mon archive ne fait que 37,8 Mo, et encore, je pense qu’avec des import plus fins, on pourrait faire mieux.

Je suis mainteneur d’un petit code de ~10k lignes, la distribution wheel fait 50kB. C’est quasi un facteur 1000 en supposant que ton code fait à peu près cette taille là. Les imports ne changeront rien, quand tu fais from a import b, Python importe le paquet a complètement et cx_freeze l’ajoute entièrement à l’archive.

J’ai rien pigé à ton histoire de Visual Studio. L’avantage de Python, c’est qu’il est multi-plateforme et que son écosystème est riche en package pour faire beaucoup de choses "courantes" sans se prendre la tête. La solution simple pour partager ton code, c’est du coup de simplement partager ton code. Laisse les gens installer Python, et laisse pip gérer les dépendances.

Édité par adri1

I don’t mind that you think slowly, but I do mind that you are publishing faster. – W. Pauli

+0 -0
Auteur du sujet

Oh la la, on ne joue pas du tout dans la même cour ! ma petite appli fait une centaine de lignes, elle tient dans un seul module, il y a 5 fonctions …

Merci pour tes précisions concernant les imports.

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte