Accès aux programmes py2exe sur le réseau dans Windows 98 lance ImportErrors

Question

Je suis en cours d'exécution d'un programme python compilé py2exe-d'une machine serveur sur un certain nombre de machines clientes (mis en correspondance avec un lecteur réseau sur chaque machine, dis W :).

Pour Windows XP et les machines plus tard, ont jusqu'à présent eu zéro problème avec Python ramasser W: \ python23.dll (oui, j'utilise Python 2.3.5 pour la compatibilité W98 et tout cela). Il utilisera alors W: \ zlib.pyd à décomprimer W:. \ Library.zip contenant tous les fichiers .pyc comme os et tels, qui sont ensuite importés et le programme fonctionne sans problème

La question que je reçois est sur certaines machines Windows 98 SE (Remarque: certaines machines Windows 98 SE, d'autres semblent fonctionner sans problème apparent). Ce qui se passe est, le programme va de W :, le W: \ python23.dll est, je suppose, a trouvé (depuis que je suis en train de Python ImportErrors, nous avions besoin d'être en mesure d'exécuter une instruction import Python), mais 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 le XP et des machines plus élevées sur le même réseau).

2) Si les fichiers .pyc sont effectivement inclus sur l'exe python par py2exe, ou mis dans le même répertoire que le fichier .exe, OU mis dans un sous-répertoire nommé qui est ensuite fixé dans le cadre de la variable PYTHONPATH (par exemple W :. \ pylib), je reçois ImportError: no module named os (os est le premier module importé, avant sys et rien d'autre)

Venez y penser, sys.path ne serait pas disponible pour rechercher si os a été importé avant qu'elle ne peut-être? Je vais essayer de passer l'ordre de ces importations, mais ma question demeure: Pourquoi est-ce un problème sporadique, en travaillant sur certains réseaux, mais pas sur d'autres? Et comment pourrais-je forcer Python à trouver les fichiers qui sont regroupés dans le même exécutable je cours? J'ai immédiatement accès à la machine Windows 98 SE de travail, mais je ne reçois que l'accès au travail non un (un de mes clients) tous les matins avant leur ouverture du magasin.

Merci d'avance!

---

EDIT: D'accord, grand pas en avant. Après le débogage avec PY2EXE_VERBOSE, le problème se produit sur la machine W98SE spécifique est qu'il est de ne pas utiliser la syntaxe droit chemin lors de la recherche pour les importations. Tout d'abord, il ne semble pas lire la variable d'environnement PYTHONPATH (il peut y avoir un spécifique à py2exe Je ne suis pas au courant, comme PY2EXE_VERBOSE).

En second lieu, il semble que dans un seul endroit avant d'abandonner (si les fichiers sont regroupés à l'intérieur de l'EXE, il semble là. Dans le cas contraire, il semble en 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? Solutions de repli Pas même le répertoire de travail actuel? Je vais essayer d'ajouter W:\ à PATH, mais py2exe ne se conforme pas à une sorte de normes pour localiser les bibliothèques du système, il ne fonctionnera pas.

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 library.zip, mais la double barre oblique après la lettre de lecteur (quelqu'un me corriger si cela est prévu et devrait fonctionner). On dirait que si cela est une chaîne littérale, alors, puisque la barre oblique n'est pas doublé, il est lu comme une (invalide) séquence d'échappement et le caractère brut est imprimé (donnant W:\library.zipos.pyd, W:\library.zipos.dll, ... au lieu de par une barre oblique); si elle n'est pas une chaîne littérale, la double barre oblique pourrait ne pas être normpath'd automatiquement (comme il devrait l'être) et donc la double barre oblique embrouille le chargeur de module. Comme je l'ai dit, je ne peux pas set PYTHONPATH=W:\\library.zip\\ parce qu'elle ne tient pas compte de cette variable.

Il peut être intéressant d'utiliser sys.path.append au début de mon programme, mais les chemins du module coder en dur est un dernier recours, d'autant plus que le problème se produit dans une configuration d'un système d'exploitation obsolète.

Anidées y? J'ai une, ce qui est de la Normpath sys.path .. dommage que je dois os pour cela. Une autre consiste à ajouter simplement os.getenv('PATH') ou os.getenv('PYTHONPATH') à sys.path ... à nouveau, besoin du module os. Le module site échoue également à 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 de l'apparence des choses. Est-il possible d'utiliser la fonctionnalité intégrée qui n'a pas besoin de modifier le linecache sys.path dynamiquement? Ou suis-je réduit à coder en dur l'sys.path correct?

Answer 1

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

Answer 2

Ce n'est pas une réponse directe, mais peut-être un peu d'aide. Êtes-vous familier avec l'option -v en Python. Tapez python -h pour en savoir plus. Notez l'équivalent à la variable d'environnement PYTHONVERBOSE pour les scripts py2exe'd est PY2EXE_VERBOSE, comme décrit presque nulle part, sauf dans ce poste par son auteur . Apparemment, il peut prendre des valeurs de 1 ou 2, essentiellement comme -v et -vv, bien que ce soit un peu différent de comment fonctionne PYTHONVERBOSE .

Notez également votre sys.path idée: si vous avez importé sys aurait déjà ou non n'a pas d'effet si vous pouvez importer os. Autrement dit, le chemin Python (visible dans sys.path) est toujours disponible, dans le sens où elle reflète une caractéristique interne de l'interprète qui est là si vous avez importé le module sys ou non.

Comme un certain nombre d'autres modules, sys est intégré, il devrait donc toujours être importable même si votre application est presque totalement paralysé. Si elle vous aidera, vous pourrez peut-être 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

En outre, je vous conseille de ne pas essayer quelque chose de fantaisie comme les fichiers regrouper .pyc dans le .exe. Vous avez déjà assez de travail contre vous être coincé soutenir Win98, et si je vous j'iriez pour l'approche la plus simple qui me permettrait de faire le travail et passer à des zones plus intéressantes. Si vous pouviez installer Python normalement et exécuter à partir des sources, vous devriez certainement considérer! :)

Edité pour inclure lien vers PY2EXE_VERBOSE informations par commentaire par darvids0n.