Bonjour,

Je suis sur mac et j'ai codé un petit programme que je souhaite distribuer à d'autres personnes qui n'y connaisse rien en python. Etant sur windows avant, j'ai d'abord essayé de rendre mon programme exécutable avec cx_Freeze , seulement sur un autre post que j'ai fais j'ai appris que cx_Freeze ne marchait pas sur mac.

J'ai donc essayé avec un autre module nommé pyinstaller, seulement l'exécutable ainsi créé ne marche pas à cause de tkinter (qui est présent dans mon programme). Je me suis alors renseigné sur le net mais aucun post ne m'a aidé et grand nombre d'entre eux sont en anglais donc quand les réponses deviennent trop technique je ne comprends pas bien.

Pour ceux qui veulent, voici l'erreur que je reçois lorsque je lance le programme transformé en exécutable:

File "fenetre.py", line 3, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/PyInstaller/loader/pyimod03_importers.py", line 623, in exec_module
    exec(bytecode, module.__dict__)
  File "tkinter/__init__.py", line 36, in <module>
ImportError: dlopen(/var/folders/lb/4l183px10pzfynnnthr8fls40000gn/T/_MEIpbeTPC/_tkinter.cpython-36m-darwin.so, 2): Library not loaded: @loader_path/Tcl
  Referenced from: /var/folders/lb/4l183px10pzfynnnthr8fls40000gn/T/_MEIpbeTPC/_tkinter.cpython-36m-darwin.so
  Reason: no suitable image found.  Did find:
	/var/folders/lb/4l183px10pzfynnnthr8fls40000gn/T/_MEIpbeTPC/Tcl: not a file
	/private/var/folders/lb/4l183px10pzfynnnthr8fls40000gn/T/_MEIpbeTPC/Tcl: not a file

L'erreur semble venir du fait que pyinstaller ne trouve pas le chemin d'accès à tkinter ( je pense). Seulement je ne vois pas comment le résoudre :/

Sinon si vous avez un autre module pour que je puisse exporter mon programme je suis preneur

Merci ! 

-
Edité par Wakate-joker 17 janvier 2020 à 19:17:59

EDIT Benzouye : Vu avec l'auteur, sujet réouvert. 

Plus d'historique sur : https://openclassrooms.com/forum/sujet/probleme-dimportation-cx-freeze

-
Edité par Benzouye 17 janvier 2020 à 18:15:52

Salut,

Si j'essaye de comprendre le cheminement du message d'erreur, tu as la ligne 3 du fichier "fenetre.py" qui n'est pas correcte. Cette ligne ferait appel à la ligne 623 de "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/PyInstaller/loader/pyimod03_importers.py" qui ferait appel à la ligne 36 de tkinter.py et il y a un problème d'importation. Généralement, ça veut dire que le module n'est pas importé ou que sa version ne correspond pas à celle acceptée par d'autres modules en lien, en somme, peut-être que pyinstaller ne gère pas telle version de tkinter.

Pour en avoir le coeur net, tu cherches sur un moteur de recherche quelles sont les versions de tkinter compatibles avec pyinstaller. Après, c'est peut-être pas ça du tout.

Les lignes 7, 8 et 9 indiqueraient qu'on veut "coder" une image, or, ce qui est dans la ligne 3 de "fenetre.py" ne serait pas un fichier mais un dossier.

Le mieux serait de copier coller le code-source de "fenetre.py", mais, peut-être que tu as un dossier comme tel :

/users/pythoncode/images/:
    images.jpeg

et que tu as écrit en ligne 3 : "/users/pythoncode/images" en pensant que tu as bien demandé l'image.

Ce ne sont que des suppositions.

Quand bien même tu parviendras à freezer ton programme, il ne fonctionnera que sur Mac. PyInstaller ne permet pas de faire du cross-platform. Il me semble d'ailleurs qu'aucune bibliothèque de freezing ne le permet. C'est d'autant plus vrai quand il est question d'intégrer des bibliothèques tierces pré-compilées (tcl pour tkinter par exemple).

Malheureusement tu ne pourra pas échapper à l'anglais. Voici le guide qu'il faut lire avant de ce lancer dans la distribution de ton application : Python Packaging User Guide.

L'info que tu donnes en première phrase, il le sait, je lui ai indiqué via la doc de pyinstaller merci pour l'apport supplémentaire quand même.

Un lien vers le site officiel est généralement une bonne chose.

D'accord , cela veut dire que même si je crée un programme exécutable via cx_Freeze sur windows je ne pourrais pas l'envoyer en pièce-jointe à un mac par exemple ? 

J'ai l'impression que vouloir exporter ses programmes à d'autres utilisateurs (sans qu'ils aient besoin de télécharger python) est une vraie galère...

Je t'avouerai que j'ai jamais clairement compris le terme de portable quand on qualifie certains langages de prog. Python est portable. Oui, à condition que les modules utilisés soient compatible multi-os. Pas besoin de chercher loin, dans la liste des modules inclus, certains sont uniquement compatibles Unix.

En somme, si tout le code source, donc les modules importés également sont portables, bien évidemment que tu peux le copier vers un autre OS. Et c'est là où les environnements virtuels c'est génial, tu "englobes" tout ce code et les modules dans un environnement virtuel que tu transfères d'OS en OS. Retourne sur le sujet fermé, il y a des liens utiles de feu le site sametmax.

Ton dernier paragraphe montre le paradoxe de l'utilisateur lambda qui pourrait ne pas te faire confiance : "Python ? Un serpent dans mon ordi, qu'est-ce que c'est que cette connerie ? Jamais !!!" alors que lorsqu'il a installé un jeu vidéo, le langage, souvent C ou C++, ne s'est pas fait prier pour s'installer parce que sans compilateur C ou C++, pas possible de jouer.

À proprement parler, un programme compilé n'est jamais portable ! Le code peut l'être à condition qu'il n'exploite aucune bibliothèque ou littérale propre à un système.

Tkinter est un binding qui utilise l'interpréteur TCL (bibliothèque Tcl/Tk), disponible sur beaucoup (tous ?) de système (OS et architectures).

Si tu veux distribuer ton application sur plusieurs systèmes différent en incluant ses dépendances compilées (ici Python et Tcl), tu va devoir procéder au packaging depuis chacun de ces systèmes cibles (via machine virtuel, c'est aussi possible). Ou faire de la cross-compilation, ce qui peut être très difficile.

Le paquet Pynsist permet de produire un installeur pour Windows depuis un système Mac ; il est cross-platform mais ne produit que des installeurs pour Windows. Ce n'est pas du freezing, même s'il partage l'un des  gros défauts du freezing (redondance de l'interpréteur et de ses bibliothèques par applications). Mais au moins il ne pourri pas les dossiers temporaires avec les instances des applications à chaque fois qu'elles sont lancées.

Malheureusement, Tkinter n'est pas inclus avec le Python embarqué dans l'installeur NSIS. Il faut récupérer les fichiers binaires de Tkinter et Tcl depuis une installation de Python sur un système Windows.

-
Edité par TrustyLite 19 janvier 2020 à 1:27:28

Merci de vos réponses,

je pense que je vais renoncer à freezer mon programme. Pynsist me parait une bonne alternative, existe-t-il une version pour créer un installateur pour mac ?

Sinon , je ne comprend pas trop l'avantage des environnements virtuels. J'en ai déjà beaucoup entendu parler mais je pensais jusqu'à maintenant qu'il permettait juste une meilleure organisation des projets et une meilleure lecture du code. Mais je ne comprend pas trop ce que tu dis Le Cobriste 128 , utiliser un environnement virtuelle permet de distribuer mes projets sur n'importe quel système d'exploitation ?

PS: Désolé je ne sais pas trop comment ces environnements marche , je ne code que sur l'IDLE python :/

Non, un code source c'est du texte, d'ailleurs, on peut écrire du code source sous bloc-notes.

Ce que je veux dire, c'est que tu peux créer un environnement virtuel contenant le code source (le texte), et les modules nécessaires. Avec ce paquetage, tu peux aller d'OS en OS, mais, il faut que l'OS de destination ait les outils indispensables au fonctionnement du programme. Or, sur le pc de ton pote qui a pas python, il aura un environnement inutilisable. C'est plus pour toi, si tu codes chez toi sous Windows 10 et chez tes parents sous MacOS à condition que les 2 OS aient la même version de python 3.

Les environnements virtuels servent surtout à isoler les projets pendant leur développement. Ainsi tu peux travailler sur différente version d'un même projet ou sur plusieurs projets qui utilisent différentes versions d'une même bibliothèque sans que cela n'impacte les autres projets.

Imagine que tu a un projet A qui utilise une bibliothèque en version X et un projet B qui utilise cette même bibliothèque en version Y, Tu ne peux pas avoir ces deux versions de la bibliothèque en même temps dans l'environnement standard de ton système.

Attention à ne pas confondre avec les machines virtuelles, qui permettent d'émuler des systèmes d'exploitations.

Pour une distribution professionnelle, d'ici à ce que tu sois en mesure d'appréhender toute la difficulté et les enjeux que ça implique, la bonne vielle méthode de l'archive ZIP est très bien !

Tu commence par produire un paquet Python conventionnel. Ce sera au gestionnaire de paquets PIP de se charger de l'installation proprement. Il pourra même gérer le point d'entré du programme et créer des raccourcis si voulu, comme il faut.

Et pour la dépendance à Python, les utilisateurs se débrouillent toujours très bien tout seul. Je ne connais personne qui ce soit plein de devoir installer manuellement la JVM pour jouer à MineCraft, et Markus est toujours milliardaire. :Kappa:

D'accord merci vous m'aidez bien.

Si je comprend bien donc utiliser un environnement virtuel me permet de packager mon projet, et donc l'utilisateur n'a qu'à avoir python installé sur sa machine pour utiliser mon projet ( il n'aura pas besoin de télécharger les modules importés dedans comme par exemple ici : Tkinter ).

Et en ce qui concerne la méthode ZIP, je ne vois pas à quoi elle sert ... Peux-tu plus me détailler son "fonctionnement" et ce qu'elle permet ?