Accès au programme py2exe sur le réseau sous Windows 98 throws ImportErrors

Question

Je lance un programme python compilé py2exe à partir d'une machine serveur sur un certain nombre de machines client (mappé sur un lecteur réseau sur chaque machine, disons W :).

Pour Windows XP et les machines suivantes, jusqu'à présent, aucun problème n'a été rencontré avec Python qui a récupéré W: \ python23.dll (oui, j'utilise Python 2.3.5 pour la compatibilité W98 et tout ça). Il utilisera ensuite W: \ zlib.pyd pour décompresser W: \ library.zip contenant tous les fichiers .pyc comme os et tel, qui sont ensuite importés et le programme ne pose aucun problème. Le problème que j'obtiens est sur certaines machines Windows 98 SE (remarque: QUELQUES machines Windows 98 SE, d'autres semblent fonctionner sans problèmes apparents). Ce qui se passe, c'est que le programme s'exécute à partir de W :, le W: \ python23.dll est, je suppose, trouvé (puisque j'obtiens Python ImportErrors, nous devrions être en mesure d'exécuter une instruction d'importation Python), mais un deux choses ne fonctionnent pas:

1) Si W: \ library.zip contient la seule copie des fichiers .pyc, je reçois ZipImportError: can't decompress data; zlib not available (non-sens, considérant W: \ zlib.pyd est disponible et fonctionne très bien avec les machines XP et supérieures sur le même réseau).

2) Si les fichiers .pyc sont réellement regroupés à l'intérieur du python exe par py2exe, OU placés dans le même répertoire que le fichier .exe, OU placés dans un sous-répertoire nommé qui est alors inclus dans la variable PYTHONPATH (par ex. W: \ pylib), je reçois ImportError: no module named os (os est le premier module importé, avant sys et tout le reste). En y pensant, sys.path ne serait pas disponible pour chercher si os a été importé avant peut-être? Je vais essayer de changer l'ordre de ces importations, mais ma question est toujours la suivante: pourquoi est-ce un problème sporadique, qui touche certains réseaux, mais pas les autres? Et comment pourrais-je forcer Python à trouver les fichiers qui sont regroupés dans le très exécutable que je cours? J'ai un accès immédiat à la machine fonctionnant sous Windows 98 SE, mais je n'ai accès qu'au poste de travail (un client à moi) tous les matins avant l'ouverture de leur magasin.

Merci d'avance!

---

EDIT: Bon, grand pas en avant. Après le débogage avec PY2EXE_VERBOSE, le problème se produisant sur la machine W98SE spécifique est qu'il n'utilise pas la bonne syntaxe de chemin lors de la recherche d'importations. Premièrement, il ne semble pas lire la variable d'environnement PYTHONPATH (il peut y avoir une variable spécifique à py2exe dont je n'ai pas connaissance, comme PY2EXE_VERBOSE). En second lieu, il ne regarde que dans un endroit avant d'abandonner (si les fichiers sont regroupés dans le fichier EXE, il y ressemble, sinon il apparaît dans library.zip).

EDIT 2: En fait, selon this, il y a une différence entre la sys.path dans l'interpréteur python et que des exécutables py2exe. Plus précisément, sys.path contains only a single entry: the full pathname of the shared code archive. Blah. Pas de repli? Pas même le répertoire de travail actuel? J'essaierais d'ajouter W:\ à PATH, mais py2exe ne correspond à aucune norme de localisation des bibliothèques système, cela ne fonctionnera donc pas.

Maintenant, pour le bit intéressant. Le chemin qu'il tente de charger atexit, os, etc. de est:

W:\\library.zip\<module>.<ext>

Notez la barre oblique unique après la bibliothèque.zip, mais la double barre oblique après la lettre de lecteur (quelqu'un me corriger si cela est prévu et devrait fonctionner). Il semble que ce soit un littéral de chaîne, puisque la barre oblique n'est pas doublée, elle est lue comme une séquence d'échappement (invalide) et le caractère brut est imprimé (donnant W:\library.zipos.pyd, W:\library.zipos.dll, ... au lieu d'une barre oblique); si ce n'est pas un littéral de chaîne, la double barre oblique peut ne pas être normpath'd automatiquement (comme il se doit) et donc la barre oblique double le chargeur de module. Comme je l'ai dit, je ne peux pas simplement set PYTHONPATH=W:\\library.zip\\ parce qu'elle ignore cette variable.

Il est peut-être utile d'utiliser sys.path.append au début de mon programme, mais les chemins de modules codés en dur sont un dernier recours absolu, d'autant plus que le problème se produit dans UNE configuration d'un système obsolète.

Des idées? J'en ai un, qui est normpath le sys.path .. dommage que j'ai besoin de os pour cela. Une autre consiste à ajouter simplement os.getenv('PATH') ou os.getenv('PYTHONPATH') à sys.path ... à nouveau, nécessitant le module os. Le module site ne parvient pas à s'initialiser, donc je ne peux pas utiliser un fichier .pth.

J'ai aussi récemment essayé le code suivant au début du programme:

for pth in sys.path: 
    fErr.write(pth) 
    fErr.write(' to ') 
    pth.replace('\\\\','\\') # Fix Windows 98 pathing issues 
    fErr.write(pth) 
    fErr.write('\n') 

Mais il ne peut pas charger linecache.pyc, ou toute autre chose pour cette matière; il ne peut pas réellement exécuter ces commandes à partir de l'apparence des choses. Est-il possible d'utiliser une fonctionnalité intégrée qui n'a pas besoin de linecache pour modifier le sys.path de façon dynamique? Ou suis-je réduit à coder en dur le bon sys.path?

Answer 1

Le problème n'est plus un problème pour moi, j'ai trouvé une solution alternative (qui peut ou non avoir impliqué de quitter mon travail là-bas). Accepter cette réponse jusqu'à ce que quelqu'un d'autre puisse fournir une solution plus satisfaisante.

Answer 2

Ceci n'est pas une réponse directe, mais peut-être un peu d'aide. Connaissez-vous l'option -v en Python. Tapez python -h pour en savoir plus. Notez que l'équivalent de la variable d'environnement PYTHONVERBOSE pour les scripts py2exe'd est PY2EXE_VERBOSE, comme décrit presque nulle part sauf dans this post by its author. Apparemment, il peut prendre des valeurs de 1 ou 2, fondamentalement comme -v et -vv, bien que ce soit légèrement différent de how PYTHONVERBOSE works. Notez également votre idée de sys.path: que vous ayez déjà importé sys ou non, cela n'aurait aucun effet si vous pouviez importer os. C'est-à-dire que le chemin Python (visible dans sys.path) est toujours disponible, en ce sens qu'il reflète une caractéristique interne de l'interpréteur qui est là si vous avez importé le module sys ou non.

Comme avec un certain nombre d'autres modules, sys est intégré, donc il devrait toujours être importable même si votre application est presque totalement paralysée. Si cela peut vous aider, vous pouvez utiliser sys.builtin_module_names pour voir ce qu'ils sont pour votre version de Python. Si l'interprète est en cours d'exécution à toutes ces informations seraient disponibles, ce qui suit peut être le plus petit programme utile, vous pouvez voir ce que vous avez:

import sys 
print sys.builtin_module_names 

De plus, je vous conseille de ne pas essayer quoi que ce soit de fantaisie comme le regroupement des fichiers .pyc à l'intérieur du fichier .exe. Vous avez déjà assez de travail pour vous empêcher de supporter Win98, et si j'étais vous, j'opterais pour l'approche la plus simple qui me permettrait de faire le travail et de passer à des domaines plus intéressants. Si vous pouviez simplement installer Python normalement et courir à partir de la source, vous devriez certainement le considérer! :)

Édité pour inclure le lien vers PY2EXE_VERBOSE info par commentaire par darvids0n.