Discussion :

[ohtoulouse]

Un petit bonjour à vous tous. Je suis un modeste petit programmeur de
bas niveau et j'aimerai vous poser une petite question toute simple.
J'ai déjà fait quelques programmes en python. Je sais créer un
executable sous windows avec py2exe et depuis peu avec pyinstaller.

Pas du tout expert de linux, j'ai installé avec VirtualBox plusieurs
distributions: Fedora, ubuntu et opensuse.
Après m'être quelque peu cassé les dents dessus. J'ai réussi avec
Python2.6 a faire un executable avec pyinstaller et ce pour un
programme de base utilisant Tkinter et Pmw.
Ce programme fonctionne très bien sur la distribution Fedora. Si je
désinstaller Tkinter, l'executable de mon programme pseudo compilé
continue à parfaitement fonctionner. J'en déduis donc que mon
executable sous Fedora ne dépend pas de mon installation.
OU EST LE PROBLEME me direz-vous?
Le problème c'est que si je place cet executable sous un autre linux
(Ubuntu, Opensuse) il ne se lance pas.
Et moi qui découvre linux, je me pose donc de nombreuses questions...
Un executable fait avec pyinstaller est il limité à la version linux
ou il a été créé?
Bref je nage en plein cirage.
En espérant vos lumières , o Dieux du python!!

P.s
bien sur si il y a un moyen de contourner le pb, je suis preneur.
Après tout, mes scripts python fait avec py2exe sous windows sont compatibles windows xp et vista (au moins).
Pourquoi n'en serait-il pas de même avec les différentes distributions linux ?

[kango]

bonsoir,

python est portable. le même code peut fonctionner sur Unix, Linux, Mac, Windows.

en voulant utiliser py2exe et autres on rend le code dépend de la plateforme mais on veut quand même que ce soit portable ?

il y a pas une petite contradiction dans ce genre d'approche ?

à la rigueur, je peux comprendre que l'on veuille déployer un exe sur les plateformes windows, mais sur linux pourquoi ne pas directement déployer le script python lui même ?

[wiztricks]

python est portable. le même code peut fonctionner sur Unix, Linux, Mac, Windows.

Python est un langage interprété ou dynamique. Les scripts écrits en Python peut être exécutés partout ou il y a un interpreteur Python "compatible".
C'est le write once run everywhere de Java, sans avoir à compiler.

en voulant utiliser py2exe et autres on rend le code dépend de la plateforme mais on veut quand même que ce soit portable ?

il y a pas une petite contradiction dans ce genre d'approche ?

C'est juste un emballage des scripts portables précédents dans un exécutable pour des raisons diverses. La seule chose que cela empêche pour sûr c'est la possibilité d'éditer - modifier - le source...

à la rigueur, je peux comprendre que l'on veuille déployer un exe sur les plateformes windows, mais sur linux pourquoi ne pas directement déployer le script python lui même ?

Ben si c'est pour un script tout bête... certes ca fait drole.
Maintenant l'application Python peut dépendre de bibliothèques, d'une version de Python particulière...
Encapsuler tout ca dans un .EXE permet bien souvent de se blinder par rapport à l'existant, à ses évolutions...

Et comme écrit plus haut çà empêche aux utilisateurs de bricoler leur code.
Note: Si le code est livré dans le cadre d'une prestation forfaitaire, lorsque le client/utilisateur remonte un "bug"... autant savoir qu'il n'a rien bricolé dans son coin.

- W

[ohtoulouse]

Pourquoi faire un executable sous linux?
Je vais répondre à ta question. Par défaut sur les stations de travail utilisées dans mon entreprise, nous n'avons que python2.4 , sans aucune autre librairie. C'est l'installation standard et avec on va pas très loin!
Chacune de ses stations sert en opérationnel 24h/24h, et tout travail sur elle pour installer un quelconque logiciel demande à mettre en place une procédure (estimer l'intervention, bloquer le poste ...)
Le linux utilisé, "Redhat" est administré selon des règles très précises:
1 seul administrateur et une seule personne est titulaire des droits root.
Et les demandes faites pour installer telle ou telle librairie sont proches du parcourt du combattant...
Pour fonctionner un programme python utilise en général une bibliothèque graphique qui peut être complétée par d'autres librairies; exemple Pil pour pouvoir traiter des images jpeg et ne pas être limité au gif.
Si on veut pouvoir aussi faire un contrôle de saisie efficace on peut implémenter Pmw comme dans mon dernier programme.
Déjà sans demander rien d'extraordinaire pour un simple programme qui imprime des graphiques, j'ai du utiliser 3 bibliothèques qui ne sont pas implémentées sur les différentes versions de linux (Redhat, ubuntu, fedora, opensuse...) à savoir Pil, Tkinter et Pmw.
Je ne suis pas administrateur des différents postes. La politique de sécurité est telle! qu'il est impensable de demander à ce que chacune des stations de travail se voient modifier pour accueillir les différents packages nécessaire au programme, et ce d'autant plus qu'il faut parfois comme pour "Pmw" détarer le dossier au bon endroit. Ce que les administrateurs refusent de faire bien souvent. <<Hors package pas possible ...>>
L'avantage d'un executable, c'est qu'il peut directement être implanté sans demande d'autorisation auprès des différentes stations.
On évite ainsi les différentes procédures fastidieuses et demandes d'autorisations et justificatifs qui suivent le parcourt complexe de l'administration.
Et je ne parle pas de l'administrateur du parc de stations toujours overbooké et qui n'a pas le temps de se pencher sur ton problème.

Voila pourquoi o misère! je suis obligé ,... et je m'en passerais, crois moi!
de faire cet executable!

[ohtoulouse]

Après m'être justifié de ma demande "saugrenue"
personne n'a trouvé la solution?

Y a pas un génie, un chef, un roi , un dieu du python et de pyinstaller en particulier?

Le "solutionneur" aura droit à ma reconnaissance éternelle!

[wiztricks]

Salut,

Le problème c'est que si je place cet executable sous un autre linux (Ubuntu, Opensuse) il ne se lance pas.
Et moi qui découvre linux, je me pose donc de nombreuses questions...
Un executable fait avec pyinstaller est il limité à la version linux
ou il a été créé?

Je ne suis pas certain qu'en faisant subir le même traitement à n'importe quel autre exécutable vous n'obteniez pas des résultats "semblables".
Il y a plusieurs raisons à çà points d'entrées système, loader et DLL.
Le loader est le composant qui va lire l'exécutable en mémoire, trouver les DLL dont il dépend et résoudre les références diverses pour que l'exécution se passe pas trop mal.

Les points d'entrées systèmes sont différents puisque ce n'est pas un appel de routine mais un trap numéro d'entrée qui fait l'interface.
Si vous ne prenez pas la précaution d'avoir tout cela homogène et cohérent d'une version de Linux à l'autre, ben çà ne marchera pas et... vous avez des sortes de signatures qui empêcheront même d'essayer.

Problème.
Sous Linux, la compatibilité n'est que pour les "sources" i.e. "compile & run..." et non "binaire".
De plus Linux est le noyau... Voir comment ils font pour FreeBSD

Il faudrait plutôt parler de GNU/Linux, i.e. un noyau et des utilitaires à des versions x, y, z correspondant à Fedora, Debian,... Ce qu'on trouve dans la boîte n'est pas nécessairement identique.

Linux Standard Base essaie de régenter un peu tout çà.

bien sur si il y a un moyen de contourner le pb, je suis preneur

Techniquement, il faudrait construire au dessus du LSB et apporter le reste. Ce qui demanderait d'avoir au moins le loader de pyinstaller (wrappé dans l'.EXE) "LSB compliant".
Planned in a future release

Après tout, mes scripts python fait avec py2exe sous windows sont compatibles windows xp et vista (au moins).
Pourquoi n'en serait-il pas de même avec les différentes distributions linux

Parce que LSB n'est pas encore tout à fait cuit, utilisable, utilisé...
Et que a priori, c'est surtout un besoin pour les développeurs de logiciels propriétaires: les autres distribuent les sources.

- W

[wiztricks]

Humm...

La politique de sécurité est telle! qu'il est impensable de demander à ce que chacune des stations de travail se voient modifier pour accueillir les différents packages nécessaire au programme, et ce d'autant plus qu'il faut parfois comme pour "Pmw" détarer le dossier au bon endroit.
Ce que les administrateurs refusent de faire bien souvent. <<Hors package pas possible ...>>
L'avantage d'un executable, c'est qu'il peut directement être implanté sans demande d'autorisation auprès des différentes stations.

easy_install devrait vous permettre de livrer des .eggs ou les exe des différents modules et de masquer leur installation.
Je ne sais pas ce que vous avez dans vos code, mais je ne suis pas certain que vous ne puissiez par livrer un virtualenv qui isole un peu.
Après il faut voir comment vous livrez vos mises à jour...
Mais j'entends que des règles kafkaiennes n'aident pas à être inventif.
- W

[kango]

bonsoir,

je crois que je comprends bien la problématique lié à l'administration des stations.

avant de venir au "freeze" des scripts pythons, as-tu envisagé l'une ou l'autre de ces solutions:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
python setup.py install --prefix=ton_chemin

cette solution permet de ne pas installer les librairies tierces dans le répertoire même de python:

- tu n'as pas besoin d'un accès root et donc, tu n'as pas besoin de solliciter un admin
- tu ne compromets pas l'intégrité de l'installation faite par ce même admin

cette solution s'accompagne d'un script qui permet de sourcer l'environnement à lancer avant d'utiliser un script python:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PYTHONPATH=$PYTHONPATH:ton_chemin/lib/python2.4/site-packages
PYTHONPATH=$PYTHONPATH:ton_chemin/lib64/python2.4/site-packages
export PYTHONPATH

le tout étant d'installer 'ton_chemin' sur un montage disque accessible aux utilisateurs que tu vises, tout en leur donnant le script ci-dessus pour qu'ils l'intègrent à leur .bashrc.

enfin, tu gères les droits de manière à ce qu'ils puissent exécuter tes scripts ainsi que les lire et tu es assuré qu'ils ne viendront pas modifier le code.

Cette solution est propre et prévue par python.

L'autre solution consiste à utiliser virtualenv, une librairie tierce que tu peux trouver sur PyPi qui crée un environnement python "virtuel" à l'endroit de ton choix.

L'avantage, c'est que tu peux gérer facilement 2 environnements virtuels, par exemple un de développement et un de production, et ceci, toujours sans embêter ton admin.

Il existe une autre solution, bien plus lourde qui consiste à compiler toi même la version que tu veux de python à partir des sources et à l'"administrer" toi même. Mais cela peut être plus complexe .

Je te conseille de n'envisager le freeze qu'après avoir testé l'une ou l'autre de ces solutions. Mais si c'est vraiment du freeze que tu veux faire, as tu essayé cxFreeze ?

http://cx-freeze.sourceforge.net/

Tu disposes de paquets pour windows et centos (proche de redhat) en plus de la traditionnelle tarball.

[ohtoulouse]

Je vous remercie à tous pour votre aide.
Même si je n'ai pas tout saisi, je vais lire et relire vos remarques à tête reposée avec une boîte d'aspirine à coté; car ça vole un peu trop haut pour moi sur certaines de vos explications.

Mais j'apprécie votre aide et je me rends compte que mon pb est plus ardu que je ne le pensais.
De quoi s'occuper pour les longues soirées d'hiver.

Je vais tester mon executable fait sur Fedora sur une station à base de Redhat
(je n'y crois pas trop, mais bon...)
Ca n'a pas marché sur opensuse ni sur ubuntu.
Mais on m'a dit que Fedora était plus proche de Redhat, on peut toujours espérer ...

j def