Acessando programa py2exe em cima de rede no Windows 98 lança ImportErrors
-
18-09-2019 - |
Pergunta
Estou executando um programa de python compilados-py2exe de uma máquina de servidor em um número de máquinas clientes (mapeado para uma unidade de rede em cada máquina, dizer :) W.
Para o Windows XP e máquinas posteriores, até agora tinha zero problemas com Python pegando W: \ python23.dll (sim, eu estou usando Python 2.3.5 para compatibilidade W98 e tudo o que). Será, então, usar W: \ zlib.pyd para descomprimir W:. \ Library.zip contendo todos os arquivos .pyc como OS e tal, que são importados e o programa é executado sem problemas
A questão que estou recebendo é em algum do Windows 98 máquinas SE (Nota: Algumas máquinas Windows 98 SE, outros parecem funcionar sem problemas aparentes). O que acontece é, o programa é executado de W :, o W: \ python23.dll é, presumo, encontrado (desde que eu estou recebendo ImportErrors Python, tínhamos necessidade de ser capaz de executar uma instrução de importação Python), mas um algumas coisas não funcionam:
1) Se W: \ library.zip contém a única cópia dos arquivos .pyc, recebo
ZipImportError: can't decompress data; zlib not available
(nonsense, considerando W: \ zlib.pyd está disponível e funciona bem com o XP e máquinas mais elevados na mesma rede).
2) Se os arquivos .pyc são realmente empacotado DENTRO do exe python por py2exe, ou colocar no mesmo diretório como o .exe, ou colocado em um subdiretório chamado que é então definido como parte da variável PYTHONPATH (por exemplo, W :. \ pylib), recebo ImportError: no module named os
(oS é o primeiro módulo importado, antes sys e qualquer outra coisa)
Venha para pensar sobre isso, sys.path não seria disponíveis para pesquisa Se o OS foi importada antes que talvez? Vou tentar mudar a ordem dessas importações, mas a minha pergunta ainda permanece: Por que isso é uma questão esporádica, trabalhando em algumas redes, mas não em outros? E como eu forçar Python para encontrar os arquivos que são empacotados dentro do muito executável I run? Eu tenho acesso imediato ao trabalho Windows 98 SE máquina, mas eu só tenha acesso ao não-trabalho um (um cliente da mina), todas as manhãs antes de sua loja abre.
Agradecemos antecipadamente!
EDIT: Ok, grande passo em frente. Após a depuração com PY2EXE_VERBOSE, o problema que ocorre na máquina específica W98SE é que ele não está usando a sintaxe caminho certo quando se olha para as importações. Em primeiro lugar, não parece ler a variável de ambiente PYTHONPATH (pode haver um específico-py2exe Eu não estou ciente de, como PY2EXE_VERBOSE).
Em segundo lugar, ele só olha em um lugar antes de desistir (se os arquivos são empacotados dentro do EXE, parece lá. Se não, ele parece estar em library.zip).
EDIT 2 : Na verdade, de acordo com a este , há uma diferença entre o sys.path no interpretador Python e que de executáveis ??py2exe. Especificamente, sys.path contains only a single entry: the full pathname of the shared code archive.
Blá. Não fallbacks? Nem mesmo o diretório de trabalho atual? Eu tentaria adicionando W:\
para PATH, mas py2exe não se conforma com qualquer tipo de normas para a localização de bibliotecas do sistema, por isso não vai funcionar.
Agora, para o pouco interessante. O caminho ele tenta atexit carga, os, etc. a partir de é:
W:\\library.zip\<module>.<ext>
Observe a barra único após library.zip, mas a barra dupla após a letra da unidade (alguém me corrija se este se destina e deve funcionar). Parece que, se este é um literal de cadeia, em seguida, uma vez que a barra não é dobrada, ele é lido como um (inválido) sequência de escape e o caráter cru é impresso (dando W:\library.zipos.pyd, W:\library.zipos.dll, ...
em vez de com uma barra); Se não é um literal string, a barra dupla não pode ser normpath'd automaticamente (como deveria ser) e assim a barra dupla confunde o carregador de módulo. Como eu disse, eu não posso simplesmente set PYTHONPATH=W:\\library.zip\\
porque ignora essa variável.
Pode valer a pena usar sys.path.append no início do meu programa, mas embutir caminhos módulo é um último recurso absoluto, especialmente desde que o problema ocorre em uma configuração de um sistema operacional desatualizado.
Umy idéias? Eu tenho um, que é a normpath o sys.path
.. pena que eu preciso os
para isso. Outra é os.getenv('PATH')
acrescentar apenas ou os.getenv('PYTHONPATH')
para sys.path ... novamente, precisando o módulo os
. O módulo site
também falha para inicializar, então eu não posso usar um arquivo .pth.
Eu também tentei recentemente o seguinte código no início do 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')
Mas não pode carregar linecache.pyc, ou qualquer outra coisa para essa matéria; ele não pode realmente executar os comandos a partir da aparência das coisas. Existe alguma maneira de usar o built-in funcionalidade que não precisa linecache para modificar o sys.path dinamicamente? Ou estou reduzido a embutir o sys.path correto?
Solução 2
O problema já não é um problema para mim, eu encontrei uma solução alternativa (que pode ou não pode ter envolvido deixar o meu emprego lá). Aceitando esta resposta até que alguém pode fornecer uma solução mais satisfatória.
Outras dicas
Esta não é uma resposta direta, mas, possivelmente, alguma ajuda. Você está familiarizado com a opção -v
em Python. Digite python -h
para saber mais. Observe o equivalente à variável de ambiente PYTHONVERBOSE
para scripts py2exe'd é PY2EXE_VERBOSE
, como descrito quase nenhum, exceto em este post por seu autor . Aparentemente, ele pode assumir valores de 1 ou 2, basicamente como -v
e -vv
, apesar de que é um pouco diferente de como PYTHONVERBOSE funciona .
Note-se também sobre sua idéia sys.path: se você importou sys
já ou não teria nenhum efeito sobre se você pode importar os
. Ou seja, o caminho do Python (visível na sys.path
) está sempre disponível, no sentido de que ele reflete uma característica interna do intérprete que está lá se você importou o módulo sys ou não.
Tal como acontece com um número de outros módulos, sys
é built-in, por isso deve ser sempre importable mesmo se sua aplicação é quase totalmente aleijado. Se ele vai ajudar, você pode ser capaz de usar sys.builtin_module_names
para ver o que eles são para a sua versão do Python. Se o intérprete está funcionando em toda essa informação estaria disponível, então o seguinte pode ser o programa útil menor você pode fazer para ver o que você tem:
import sys
print sys.builtin_module_names
Além disso, eu aconselho a tentar algo extravagante como empacotar os arquivos .pyc dentro do .exe. Você já tem trabalho suficiente contra você sendo preso Win98 de apoio, e se eu fosse você eu iria para a abordagem mais simples que iria me deixar fazer o trabalho e passar para áreas mais interessantes. Se você poderia simplesmente instalar Python normalmente e executar a partir da fonte, você deve definitivamente considerar isso! :)
Editado para incluir link para informações PY2EXE_VERBOSE por comentário por darvids0n.