Доступ к программе py2exe по сети в Windows 98 выдает ImportErrors

Question

Я запускаю Python-скомпилированную программу Python с одного сервера на нескольких клиентских компьютерах (сопоставленных с сетевым диском на каждом компьютере, скажем, W:).

Для компьютеров с Windows XP и более поздними версиями проблемы с Python при обнаружении W:\python23.dll были нулевыми (да, я использую Python 2.3.5 для совместимости с W98 и все такое). Затем он использует W:\zlib.pyd для распаковки файла W:\library.zip, содержащего все файлы.pyc, такие как os и подобные, которые затем импортируются, и программа не запускается без проблем.

Проблема, с которой я сталкиваюсь, возникает на некоторых компьютерах с Windows 98 SE (примечание: на некоторых компьютерах с Windows 98 SE другие работают без видимых проблем). Что происходит, программа запускается из W:, я полагаю, W:\python23.dll найден (так как я получаю Python ImportErrors, нам нужно иметь возможность выполнить инструкцию импорта Python), но пара вещей не работает:

1) Если W:\library.zip содержит единственную копию файлов.pyc, я получаюZipImportError: can't decompress data; zlib not available (ерунда, учитывая, что W:\zlib.pyd IS доступен и отлично работает с машинами XP и выше в одной сети).

2) Если файлы.pyc фактически объединены ВНУТРИ исполняемого файла python с помощью py2exe, ИЛИ помещаются в тот же каталог, что и.exe, ИЛИ помещаются в именованный подкаталог, который затем задается как часть переменной PYTHONPATH (например, W:\pylib), Я получил ImportError: no module named os (os - первый импортированный модуль, до sys и всего остального).

Если подумать, sys.path не будет доступен для поиска, если ОС была импортирована раньше, чем это возможно? Я попытаюсь изменить порядок этих импортов, но мой вопрос остается открытым: почему это спорадическая проблема, работающая в одних сетях, но не в других? И как мне заставить Python найти файлы, которые находятся внутри самого исполняемого файла, который я запускаю? У меня есть немедленный доступ к работающей машине с Windows 98 SE, но я получаю доступ только к нерабочей (моей клиентке) каждое утро перед открытием их магазина.

Заранее спасибо!

---

РЕДАКТИРОВАТЬ: Хорошо, большой шаг вперед. После отладки с помощью PY2EXE_VERBOSE проблема, возникающая на конкретной машине W98SE, заключается в том, что она не использует правильный синтаксис пути при поиске импорта. Во-первых, кажется, что он не читает переменную окружения PYTHONPATH (может быть специфичная для py2exe, о которой я не знаю, например, PY2EXE_VERBOSE).

Во-вторых, он смотрит только в одном месте, прежде чем сдаться (если файлы связаны внутри EXE-файла, он выглядит там. Если нет, он просматривается в library.zip).

РЕДАКТИРОВАТЬ 2: Фактически, согласно этому, есть разница между sys.path в интерпретаторе Python и исполняемыми файлами Py2exe. В частности, sys.path contains only a single entry: the full pathname of the shared code archive. Мля. Нет откатов? Даже не текущий рабочий каталог? Я бы попробовал добавить W:\ в PATH, но py2exe не соответствует каким-либо стандартам поиска системных библиотек, поэтому он не будет работать.

Теперь для интересного. Путь, из которого он пытается загрузить atexit, os и т. Д., Является:

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

Обратите внимание на одиночную косую черту после library.zip, но двойную косую черту после буквы диска (кто-то поправит меня, если это задумано и должно работать). Похоже, если это строковый литерал, то, поскольку косая черта не удваивается, она читается как (недопустимая) escape-последовательность и печатается необработанный символ (давая W:\library.zipos.pyd, W:\library.zipos.dll, ... вместо косой черты); если это НЕ строковый литерал, двойная косая черта не может быть normpath'd автоматически (как и должно быть), и поэтому двойная косая черта сбивает с толку загрузчика модуля. Как я уже сказал, я не могу просто set PYTHONPATH=W:\\library.zip\\ потому что он игнорирует эту переменную.

Может быть, стоит использовать sys.path.append при запуске моей программы, но жесткие пути модулей - это абсолютное средство LAST, тем более что проблема возникает в ОДНОЙ конфигурации устаревшей ОС.

Есть идеи? У меня есть один, который должен sys.path.. Жаль, мне нужно os для этого. Другой просто добавить os.getenv('PATH') или же os.getenv('PYTHONPATH') в sys.path... опять же, нуждающийся в os модуль. site Модуль также не может инициализироваться, поэтому я не могу использовать файл.pth.

Я также недавно попробовал следующий код в начале программы:

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

Но он не может загрузить linecache.pyc или что-либо еще в этом отношении; на самом деле он не может выполнять эти команды по внешнему виду. Есть ли способ использовать встроенную функциональность, которая не требует linecache для динамического изменения sys.path? Или я просто усердно пишу правильный sys.path?

Answer 1

Проблема больше не является проблемой для меня, я нашел альтернативное решение (которое может включать или не включать уход с работы). Принимать этот ответ до тех пор, пока кто-то другой не сможет предоставить более удовлетворительное решение.

Answer 2

Это не прямой ответ, но, возможно, некоторая помощь. Вы знакомы с -v вариант в Python. Тип python -h Узнать больше. Обратите внимание на эквивалент PYTHONVERBOSE переменная окружения для сценариев py2exe'd PY2EXE_VERBOSEКак описано почти нигде, кроме как в этом посте его автором. По-видимому, он может принимать значения 1 или 2, в основном, как -v а также -vvхотя это немного отличается от того, как работает PYTHONVERBOSE.

Обратите внимание также на вашу идею sys.path: импортировали ли вы sys уже или нет не будет влиять на то, можете ли вы импортировать os, То есть путь Python (видимый в sys.path) всегда доступен, в том смысле, что он отражает внутреннюю функцию интерпретатора, которая существует независимо от того, импортировали ли вы модуль sys или нет.

Как и с рядом других модулей, sys встроен, поэтому он всегда должен быть импортируемым, даже если ваше приложение практически полностью повреждено. Если это поможет, вы можете использовать sys.builtin_module_names чтобы увидеть, что они для вашей версии Python. Если переводчик вообще работает, эта информация будет доступна, поэтому следующая программа может быть самой маленькой полезной, которую вы можете сделать, чтобы увидеть, что у вас есть:

import sys
print sys.builtin_module_names

Кроме того, я бы посоветовал не пытаться делать что-то необычное, например, упаковывать файлы.pyc в.exe. У вас уже достаточно работы против того, чтобы вы застряли с поддержкой Win98, и на вашем месте я бы выбрал самый простой подход, который позволил бы мне выполнить свою работу и перейти к более интересным областям. Если бы вы могли просто установить Python и запустить его из исходного кода, вы должны обязательно это учесть!:)

Отредактировано, чтобы включить ссылку на информацию PY2EXE_VERBOSE за комментарий darvids0n.