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?

Foi útil?

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.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top