Accediendo programa py2exe través de la red en Windows 98 lanza ImportErrors

Question

Estoy corriendo un programa Python py2exe-compilados de una máquina servidor en un número de máquinas cliente (asignada a una unidad de red en cada máquina, digo W :).

Para Windows XP y máquinas posteriores, han tenido hasta el momento cero problemas con Python recogiendo W: \ python23.dll (sí, estoy usando Python 2.3.5 para la compatibilidad W98 y todo eso). A continuación, utilice W: \ zlib.pyd para descomprimir W:. \ Library.zip que contiene todos los archivos .pyc como sistema operativo y tal, que luego son importados y el programa se ejecuta sin problemas

El problema es que estoy recibiendo en algunas máquinas Windows 98 SE (Nota: Algunas de Windows 98 SE máquinas, otros parecen funcionar sin problemas aparentes). Lo que sucede es, el programa se ejecuta desde el W :, W: \ python23.dll es, supongo, que se encuentra (ya que me estoy haciendo Python ImportErrors, tendríamos que ser capaces de ejecutar una sentencia de importación de Python), sino una par de cosas no funcionan:

1) Si W: \ library.zip contiene la única copia de los archivos .pyc, consigo ZipImportError: can't decompress data; zlib not available (sin sentido, teniendo en cuenta W: \ zlib.pyd está disponible y funciona bien con el XP y máquinas más altos en la misma red).

2) Si los archivos .pyc en realidad están agrupados DENTRO del exe pitón por py2exe, o poner en el mismo directorio que el archivo .exe, o puestos en un subdirectorio con el nombre que se establece a continuación, como parte de la variable PYTHONPATH (por ejemplo, W :. \ pylib), consigo ImportError: no module named os (OS es el primer módulo importado, antes sys y cualquier otra cosa)

Ahora que lo pienso de ella, sys.path no estaría disponible para buscar si os fue importado antes de que tal vez? Voy a tratar de cambiar el orden de esas importaciones, pero mi pregunta sigue en pie: ¿Por qué es esto un problema esporádico, trabajando en algunas redes, pero no en otros? Y ¿cómo podría forzar Python para encontrar los archivos que están empaquetados dentro del ejecutable muy corro? Tengo acceso inmediato a la máquina de trabajo de Windows 98 SE, pero solo me dan acceso a la que no funciona uno (un cliente mío) todas las mañanas antes de la apertura de su tienda.

Gracias de antemano!

---

EDIT: Bueno, gran paso adelante. Después de la depuración con PY2EXE_VERBOSE, el problema que ocurre en la máquina W98SE específico es que no está utilizando la sintaxis camino correcto en la búsqueda de las importaciones. En primer lugar, no parece leer la variable de entorno PYTHONPATH (puede haber una sola py2exe específica No estoy al tanto de, como PY2EXE_VERBOSE).

En segundo lugar, sólo se ve en un solo lugar antes de renunciar (si los archivos se encuentran agrupados dentro del EXE, se ve allí. Si no es así, se ve en library.zip).

EDIT 2 : De hecho, de acuerdo con este , hay una diferencia entre el sys.path en el intérprete de Python y la de los ejecutables py2exe. Específicamente, sys.path contains only a single entry: the full pathname of the shared code archive. bla. No hay retrocesos? Ni siquiera el directorio de trabajo actual? Me gustaría probar añadiendo W:\ a PATH, pero py2exe no se ajusta a cualquier tipo de normas para la localización de las bibliotecas del sistema, por lo que no va a funcionar.

Ahora para la parte interesante. La ruta de acceso intenta cargar atexit, OS, etc. a partir de es:

  

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

Tenga en cuenta la sola barra después de library.zip, pero el doble barra después de la letra de la unidad (que alguien me corrija si este está destinado y debería funcionar). Parece que si esto es una cadena literal, a continuación, ya que la barra no se duplica, se lee como una (no válido) secuencia de escape y se imprimen los caracteres en bruto (dando W:\library.zipos.pyd, W:\library.zipos.dll, ... en lugar de una barra); Si no es una cadena literal, la doble barra podría no ser normpath'd automáticamente (como debe ser) y por lo que la doble barra confunde el cargador de módulos. Como dije, no puedo set PYTHONPATH=W:\\library.zip\\ porque ignora esa variable.

Puede ser digno de usar sys.path.append al comienzo de mi programa, pero difícil de codificación de rutas de módulo es un absoluto de último recurso, sobre todo porque el problema se produce en una configuración de un sistema operativo actualizado.

UnIdeas Y? Tengo uno, que es a la Normpath sys.path .. lástima que necesito os para eso. Otra es la de simplemente añadir os.getenv('PATH') o os.getenv('PYTHONPATH') a sys.path ... otra vez, necesitando el módulo os. El módulo site también falla al inicializar, por lo que no puede utilizar un archivo .pth.

Asimismo, recientemente trató el siguiente código al principio del programa:

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

Pero no puede cargar linecache.pyc, o cualquier otra cosa para esa materia; que en realidad no puede ejecutar esos comandos desde el aspecto de las cosas. ¿Hay alguna manera de utilizar la funcionalidad integrada que no necesita linecache modificar el sys.path dinámicamente? O estoy reducido a la codificación dura sys.path correcta?

Answer 1

El problema ya no es un problema para mí, he encontrado una solución alternativa (que puede o no haber participado dejar mi trabajo allí). La aceptación de esta respuesta hasta que otra persona puede proporcionar una solución más satisfactoria.

Answer 2

Esto no es una respuesta directa, pero posiblemente un poco de ayuda. ¿Está familiarizado con la opción -v en Python. python -h escribir para aprender más. Tenga en cuenta el equivalente a la variable de entorno para scripts PYTHONVERBOSE py2exe'd es PY2EXE_VERBOSE, tal como se describe casi en ninguna parte excepto en este post por su autor . Al parecer, puede tomar valores de 1 o 2, básicamente como -v y -vv, aunque eso es un poco diferente de cómo funciona PYTHONVERBOSE.

Tenga en cuenta también acerca de su idea sys.path: si ha importado sys ya o no tendría ningún efecto sobre si se podía importar os. Es decir, la ruta de Python (visible en sys.path) está siempre disponible, en el sentido de que refleja una característica interna del intérprete que está ahí si ha importado el módulo sys o no.

Al igual que con un número de otros módulos, sys está incorporado, por lo que siempre debe haber importables incluso si su aplicación está casi totalmente paralizado. Si ayudará, es posible que pueda utilizar sys.builtin_module_names para ver lo que son para su versión de Python. Si el intérprete está funcionando a toda esa información estaría disponible, por lo que lo siguiente puede ser útil el programa más pequeño que puede hacer para ver lo que tienes:

import sys
print sys.builtin_module_names

Además, te aconsejo que no traten algo de fantasía, como la agrupación de los archivos .pyc dentro del .exe. Ya tienes suficiente trabajo en contra de usted está atascado apoyo Win98, y si yo fuera tú, iría a por el enfoque más simple que me permitiera hacer el trabajo y pasar a las zonas más interesantes. Si se pudiera instalar Python normalmente y ejecutar desde la fuente, usted debe considerar definitivamente él! :)

Editado para incluir un enlace a PY2EXE_VERBOSE información por comentario de darvids0n.