Accesso programma py2exe sulla rete in Windows 98 tiri ImportErrors

Question

Sono in esecuzione di un programma python py2exe-compilato da una macchina server su un certo numero di macchine client (mappata a un'unità di rete su ogni macchina, dico W :).

Per Windows XP e macchine successive, hanno finora avuto zero problemi con Python raccogliendo W: \ python23.dll (sì, sto usando Python 2.3.5 per la compatibilità W98 e tutto il resto). Sarà quindi utilizzare W: \ zlib.pyd per decomprimere W:. \ Library.zip contenente tutti i file .pyc come OS e tali, che vengono quindi importati e il programma viene eseguito senza problemi

Il problema che sto ricevendo è su alcune macchine Windows 98 SE (Nota: alcuni di Windows 98 SE macchine, altri sembrano funzionare senza problemi apparenti). Quello che succede è, il programma viene eseguito dalla W :, il W: \ python23.dll è, suppongo, che si trova (dal momento che sto ricevendo Python ImportErrors, avremmo bisogno di essere in grado di eseguire un'istruzione Python importazione), ma un paio di cose non funzionano:

1) Se W: \ library.zip contiene l'unica copia dei file .pyc, ottengo ZipImportError: can't decompress data; zlib not available (nonsense, considerando W: \ zlib.pyd è disponibile e funziona bene con il XP e macchine più elevati sulla stessa rete).

2) Se i file .pyc vengono effettivamente impacchettati dentro l'exe pitone da py2exe, o mettere nella stessa directory come l'exe, o messi in una sottodirectory denominata che viene quindi impostato come parte della variabile PYTHONPATH (es W :. \ pylib), ottengo ImportError: no module named os (OS è il primo modulo importato, prima di SYS e quant'altro)

Vieni a pensarci bene, sys.path non sarebbe disponibile per la ricerca Se il sistema operativo è stato importato prima che forse? Cercherò di commutazione l'ordine di queste importazioni, ma la mia domanda si ferma: Perché questo è un problema sporadico, lavorando su alcune reti, ma non su altri? E come dovrei forzare Python per trovare i file che sono in bundle all'interno del molto eseguibile corro? Ho accesso immediato al lavoro della macchina di Windows 98 SE, ma ho solo l'accesso al non-lavoro uno (un cliente di miniera) ogni mattina prima di loro negozio si apre.

Grazie in anticipo!

---

EDIT: Okay, grande passo avanti. Dopo il debug con PY2EXE_VERBOSE, il problema che si verificano sulla macchina W98SE specifica è che non sta usando la sintassi strada giusta quando si cerca per le importazioni. In primo luogo, non sembra di leggere la variabile d'ambiente PYTHONPATH (ci può essere un uno-specific py2exe io non sono a conoscenza di come PY2EXE_VERBOSE).

In secondo luogo, sembra solo in un posto prima di rinunciare (se i file sono in bundle all'interno del file EXE, sembra lì. In caso contrario, si guarda in library.zip).

EDIT 2 : Infatti, secondo questo , v'è una differenza tra lo sys.path nell'interprete Python e quella di eseguibili py2exe. Specificamente, sys.path contains only a single entry: the full pathname of the shared code archive. insignificante. Nessun fallback? Nemmeno la directory di lavoro corrente? Mi piacerebbe provare l'aggiunta di W:\ al PATH, ma py2exe non è conforme a qualsiasi tipo di standard per localizzare le librerie di sistema, in modo che non funzionerà.

Ora per il bit interessante. Il percorso si cerca di caricare atexit, os, ecc da è:

  

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

Si noti la singola barra dopo library.zip, ma la doppia barra dopo la lettera di unità (qualcuno mi corregga se questo è previsto e dovrebbe funzionare). Sembra che se questa è una stringa letterale, quindi dal momento che la barra non è raddoppiata, è letta come (non valido) sequenza di escape e il carattere grezzo viene stampato (dando W:\library.zipos.pyd, W:\library.zipos.dll, ... invece che con una barra); se non è una stringa letterale, la doppia barra potrebbe non essere normpath'd automaticamente (come dovrebbe essere) e quindi la doppia barra confonde il caricatore modulo. Come ho detto, non posso set PYTHONPATH=W:\\library.zip\\ perché ignora quella variabile.

Può valere la pena utilizzando sys.path.append all'inizio del mio programma, ma codificare percorsi dei moduli è un resort ULTIMO assoluto, tanto più che il problema si verifica in una configurazione di un sistema operativo obsoleto.

Unidee Y? Ho uno, che è quello di normpath il sys.path .. peccato ho bisogno os per questo. Un altro è di aggiungere solo os.getenv('PATH') o os.getenv('PYTHONPATH') a sys.path ... ancora una volta, che necessitano il modulo os. Il modulo site non riesce anche per inizializzare, quindi non posso utilizzare un file .pth.

Ho anche recentemente provato il seguente codice all'inizio del programma:

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

Ma non può caricare linecache.pyc, o qualsiasi altra cosa per quella materia; essa non può in realtà di eseguire questi comandi dagli sguardi di cose. C'è un modo per utilizzare la funzionalità built-in che non ha bisogno linecache modificare lo sys.path dinamicamente? Oppure io sono ridotto a codificare lo sys.path corretta?

Answer 1

Il problema non è più un problema per me, ho trovato una soluzione alternativa (che può o non può aver coinvolto lasciare il mio lavoro lì). Accettare questa risposta fino a quando qualcun altro in grado di fornire una soluzione più soddisfacente.

Answer 2

Questa non è una risposta diretta, ma forse un po 'di aiuto. Sei familiarità con l'opzione -v in Python. Digitare python -h per saperne di più. Si noti l'equivalente alla variabile di ambiente PYTHONVERBOSE per gli script py2exe'd è PY2EXE_VERBOSE, come descritto quasi da nessuna parte se non in questo post dal suo autore . A quanto pare si può assumere valori di 1 o 2, fondamentalmente come -v e -vv, anche se questo è un po 'diverso da come funziona PYTHONVERBOSE .

Si noti anche la tua idea sys.path: se hai importato già o no sys non avrebbe alcun effetto se è possibile importare os. Cioè, il percorso di Python (visibile in sys.path) è sempre disponibile, nel senso che essa riflette una caratteristica interna dell'interprete che è lì se hai importato il modulo sys o meno.

Come nel caso di una serie di altri moduli, sys è built-in, e quindi dovrebbe essere sempre importabile anche se la vostra applicazione è quasi totalmente paralizzato. Se vi aiuterà, si può essere in grado di utilizzare sys.builtin_module_names per vedere quello che sono per la versione di Python. Se l'interprete è in esecuzione a tutte quelle informazioni sarebbero disponibili, in modo che il seguente è il più piccolo programma utile che si può fare per vedere quello che hai:

import sys
print sys.builtin_module_names

Inoltre, vorrei consigliare contro di provare qualcosa di fantasia come impacchettare i file .pyc all'interno del exe. Hai già abbastanza lavoro contro di voi di essere bloccato supporto Win98, e se fossi in te mi piacerebbe andare per l'approccio più semplice che mi permetteva di ottenere il lavoro fatto e andare avanti in zone più interessanti. Se si può solo installare Python normalmente ed eseguire dai sorgenti, si dovrebbe assolutamente prendere in considerazione! :)

A cura per includere link alla PY2EXE_VERBOSE informazioni per commento di darvids0n.