Ubuntu-fr

Sorbus

Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Bonjour,
Je teste sous Linux (Ubuntu) une petite application de lecture de dictionnaires, réalisée en Python : dico.py
Elle fonctionne sous Windows (j'ai testé sous XP via VirtualBox).
Sous Linux, je l'ai placée dans /usr/share/appli/ et je lui ai donné le droit de s'exécuter comme un programme. Mais lorsque je la lance via un terminal, j'ai ce message :

$ /usr/share/appli/dico.py
from: can't read /var/mail/Tkinter
from: can't read /var/mail/ScrolledText

Une petite recherche sur le forum... Je n'ai trouvé qu'un fil de discussion parlant du message 'can't read /var/mail/Tkinter'... et rien sur '/var/mail/ScrolledText'

la paquet python-tk est bien installé sur mon ordinateur. Que me manque-t-il ? Comment remédier à ce problème ?

PMdomine

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Bonjour,

Pourrait-on jetter un coup d'œil à ton script, s'il n'est pas trop long ? (surtout les premières lignes, en fait)
Pourquoi places-tu ton script dans /usr/share/appli ? Ne serait-il pas plus pratique de le placer dans ton répertoire personnel ? (mais je ne pense pas que ce soit la cause du problème)

Pour savoir si python-tk est bien installé, il suffit d'exécuter :

sudo aptitude install python-tk

... et de lire la réponse.

---

« Mais à quoi te sert Python ?
--- À tout ! »

Sorbus

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Excuse PMdomine, je n'avais pas vu ta réponse.
Tu as raison, le problème venait des premières lignes du script, et même de la première ligne qui manquait :
#!/usr/bin/env python
(ou #!/usr/bin/python)
indispensable sous Linux pour que la commande 'from' de python soit interprétée comme une commande python, et non comme la commande Unix 'from'.

Le problème est donc réglé.

J'ai placé le script dans /usr/share/appli car c'est une petite application développée par un ami sous Windows, et que je teste sous Linux. Mais le bon emplacement de ce type d'appli devrait être je pense /usr/lib/appli avec un lien dans /usr/bin...
Ceci dit, pour l'instant, pour les tests, je l'ai finalement placé dans mon répertoire personnel.

aleph

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

> sorbus
> J'ai placé le script dans /usr/share/appli car c'est une petite application développée par un ami sous Windows, et que je teste sous Linux. Mais le bon emplacement de ce type d'appli devrait être je pense /usr/lib/appli avec un lien dans /usr/bin...

http://forum.ubuntu-fr.org/viewtopic.php?id=246486 mdg No 4

Sorbus

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Le sys.path peut être (et est bien souvent) différent pour chaque utilisateur d'un environnement Python quelle que soit la plateforme et ceci aussi pour les utilisateurs d'un même OS (OS X, Solaris, un Linux, ...).

(Il me semble que c'est un concept que beaucoup ont de la peine à saisir et qui explique accessoirement aussi pourquoi distribuer un/des script(s) Python sous forme de paquet deb n'est pas une bonne idée.)

Merci pour ces précisions aleph. Je ne sais pas trop bien ce qu'il faut en conclure... c'est à dire que je suis sans doute de ceux qui ont de la peine à saisir le concept : est-ce que cela signifie que ce n'est pas une bonne idée de développer une appli en python ? Ou bien est-ce qu'il y a des précautions particulières à prendre permettant de remédier au problème ?

aleph

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

> Sorbus

> Merci pour ces précisions aleph. Je ne sais pas trop bien ce qu'il faut en conclure... c'est à dire que je suis sans doute de ceux qui ont de la peine à saisir le concept wink : est-ce que cela signifie que ce n'est pas une bonne idée de développer une appli en python ? Ou bien est-ce qu'il y a des précautions particulières à prendre permettant de remédier au problème ?

---

Ecrire des applications en Python ne pose *aucun* problème (je ne parle pas du code Python proprement dit) et Python est très bien adapté pour être multiplaforme et a été conçu pour travailler ainsi.

Ce qu'il faut bien garder à l'esprit est que Python (un environnement Python) est transcendant des systèmes d'exploitation. Une application Python (script ou ensemble de scripts), ne repose sur aucune variable d'environnement, c'est le sys.path qui définit les chemins de recherche des modules et celui-ci peut être différent pour chaque utilisateur d'un environnement Python quelle que soit la plateforme. Dix utilisateurs d'Ubuntu peuvent avoir dix sys.path différents. De même pour Windows ou Solaris.

C'est à l'utilisateur de Python que revient le soin de gérer le sys.path, soit en le faisant dans le script qu'il écrit ou en définissant "certains paramètres", pour faire court, de l'environnement Python. Ce dernier cas est plutôt réservé aux développeurs de l'environnement Python (en gros et pour faire simple ceux qui développent pygtk, wxPython ou PIL).

Autrement dit, tu peux mettre tes applications et/ou tes modules n'importe où dans la hiérarchie des fichiers de n'importe quel système d'exploitation.

Une conséquence de ce concept est que cela permet à n'importe quel développeur sous n'importe quel OS de mettre à disposition ses modules/scripts à tous les utilisateurs qui veulent bien utiliser ces scripts et ceci toujours quelle que soit la plateforme du destinataire. Et bien souvent, on ne peut même pas savoir sous quel os a été développé un script Python. Il est fort probable que tu utilises sur ton ubuntu (je suppose) du code Python que j'ai développé sous Windows 2000. (La même machine qui me permet d'écrire ce message).

Cette façon de faire a aussi d'autres conséquences très pratiques. Par ex, un utilisateur n'ayant pas les droits d'administateur peut très bien travailler avec des scripts uniquement stockés uniquement dans son \home ou bien il peut maintenir et utiliser de multiples versions d'un script ou d'une bibliothèque de scripts en jouant avec le sys.path.

Exemple concret et pratique. Je mets à disposition sur la toile le script abc.py (celui créé pour l'autre fil de discussion). Tu récupères le code, le mets dans un fichier .py, le sauvegarde n'importe où dans sur ton disque dur (ou même sur une clef usb ou une disquette) et ce script/module sera accessible pour tes scripts pour autant que tu aies pris soin d'adapter ton sys.path.

Pigé ? En espérant ne pas avoir été trop brouillon.

Le code tout bête de abc.py que j'avais omis de donner.

"""Ce module contient les deux fonctions fa() et fb()"""

def fa():
    """fa() -> 999 (in all cases)"""
    
    return 999
    
def fb():
    """fb() -> "abcdef" (in all cases)"""
    
    return "abcdef"

Sorbus

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Grand merci aleph, d'avoir pris le temps de ces explications. Non, ce n'est pas trop brouillon. C'est même très clair !

aleph

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

> Sorbus

De rien et ... jette un oeil à ce que sont les fichiers .pth .

Sorbus

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

Des fichiers .pth, j'ai vu qu'il y en avait 21 dans mon système de fichiers (sous Ubuntu, oui). Par contre, l'outil de recherche de windows XP (virtualisé) ne trouve aucun fichier .pth sur C:\ (normal ?). Et pour le sys. path, j'ai ceci :

>>> import sys
>>> sys.path
['', '/usr/lib/python25.zip', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/usr/lib/python2.5/site-packages/gtk-2.0', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
>>>

Et en effet, j'ai regardé le sys.path sur mon xp virtualisé. Il est différent.

Mais je ne développe personnellement aucun script ou application... Je teste seulement une application. Je pense donc que je n'ai pas à jouer avec le sys.path... Mais par contre, si je comprends bien, il faut que celui qui développe l'application fasse ce qu'il faut en ce qui concerne le sys.path...

Voilà ce que je comprends... Et de mon côté , je place les fichiers de l'application où je veux (selon les indications du développeur de l'appli je pense quand même, pour ce qui concerne la hiérarchie interne entre les différents fichiers composant l'appli).

Un lien intéressant.

Dernière modification par Sorbus (Le 25/08/2008, à 23:35)

aleph

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

> Sorbus

> Mais je ne développe personnellement aucun script ou application...

Evidemment, cela modifie le cours de la discussion.

> il faut que celui qui développe l'application fasse ce qu'il faut en ce qui concerne le sys.path...

Oui, mais malheureusement, bien des développeurs n'en sont pas conscients, ne le font pas ou le font incorrectement (*)

> Et de mon côté , je place les fichiers de l'application où je veux (selon les indications du développeur...

Si l'application, les scripts, les modules sont faits correctement, tu peux les placer où tu veux et , comme déjà dit même sur périphérique externe (clef usb, cd, ...), sans devoir suivre les indications du développeur et ceci quelle que soit la plateforme.

...Et si le développeur te donnes des instructions, c'est que les applications sont mal programmées, voir (*).

Je parle naturellement des scripts qui utilisent l'environnement Python et non pas des logiciels qui étendent l'environnement Python (numpy, pygame, ...).

Un script Python fonctionne face à un environnement Python *exactement* de la même manière qu'un document html pour un navigateur ou un document od* pour OpenOffice.org. C'est la raison pour laquelle on trouve sur la toile un nombre incalculable de scripts.

aleph

Re : Application python "from: can't read /var/mail/Tkinte" et ScrolledText

> Sorbus

> Mais je ne développe personnellement aucun script ou application...

Evidemment, cela modifie le cours de la discussion.

> il faut que celui qui développe l'application fasse ce qu'il faut en ce qui concerne le sys.path...

Oui, mais malheureusement, bien des développeurs n'en sont pas conscients, ne le font pas ou le font incorrectement (*)

> Et de mon côté , je place les fichiers de l'application où je veux (selon les indications du développeur...

Si l'application, les scripts, les modules sont faits correctement, tu peux les placer où tu veux et , comme déjà dit même sur périphérique externe (clef usb, cd, ...), sans devoir suivre les indications du développeur et ceci quelle que soit la plateforme.

...Et si le développeur te donnes des instructions, c'est que les applications sont mal programmées, voir (*).

Je parle naturellement des scripts qui utilisent l'environnement Python et non pas des logiciels qui étendent l'environnement Python (numpy, pygame, ...).

Un script Python fonctionne face à un environnement Python *exactement* de la même manière qu'un document html pour un navigateur ou un document od* pour OpenOffice.org. C'est la raison pour laquelle on trouve sur la toile un nombre incalculable de scripts.