Nuitka
1.0.0
Este documento é a primeira leitura recomendada quando você começar a usar o Nuitka . Nesta página, você aprenderá mais sobre os fundamentos do Nuitka , como tipo de licença, casos de uso, requisitos e créditos.
Índice
Requisitos
Uso
Tutorial Configuração e compilação no Windows
Casos de uso
Ajustes
Problemas típicos
Pontas
Relatório de compilação
Desempenho
Funcionalidade não suportada
Nuitka é o compilador Python. Está escrito em Python. É uma substituição ou extensão perfeita para o interpretador Python e compila todas as construções que Python 2 (2.6, 2.7) e Python 3 (3.4 - 3.13) possuem, quando executado com essa versão Python.
Em seguida, ele executa o código não compilado e o código compilado juntos de uma maneira extremamente compatível.
Você pode usar todos os módulos da biblioteca Python e todos os módulos de extensão livremente.
Nuitka traduz os módulos Python em um programa de nível C que então usa libpython e arquivos C estáticos próprios para executar da mesma maneira que o CPython.
Toda otimização visa evitar sobrecarga, onde for desnecessária. Nenhum visa remover a compatibilidade, embora pequenas melhorias sejam feitas ocasionalmente, onde nem todos os bugs do Python padrão são emulados, por exemplo, mensagens de erro mais completas são fornecidas, mas há um modo de compatibilidade completo para desabilitar até mesmo isso.
Para garantir o bom funcionamento do Nuitka , certifique-se de seguir os requisitos do sistema, que incluem os seguintes componentes:
Compilador C
Pitão
Sistema operacional
Arquitetura
Você precisa de um compilador C com suporte para C11 ou, alternativamente, um compilador C++ para C++03 [1].
Atualmente, isso significa que você precisa usar um destes compiladores:
O compilador MinGW64 C11, no Windows, deve ser baseado no gcc 11.2 ou superior. Ele será baixado automaticamente se nenhum compilador C utilizável for encontrado, que é a forma recomendada de instalação, pois Nuitka também irá atualizá-lo para você.
Visual Studio 2022 ou superior no Windows [2]. Pacote de idioma inglês para melhores resultados (Nuitka filtra saídas de lixo, mas apenas para o idioma inglês). Ele será usado por padrão se instalado.
Em todas as outras plataformas, o compilador gcc de pelo menos versão 5.1, e abaixo dele o compilador g++ de pelo menos versão 4.4 como alternativa.
O compilador clang no macOS X e na maioria das arquiteturas FreeBSD.
No Windows, o compilador clang-cl no Windows pode ser usado se fornecido pelo instalador do Visual Studio.
| [1] | O suporte para este C11 é fornecido com gcc 5.x ou superior ou qualquer versão clang. Os compiladores MSVC mais antigos ainda não fazem isso. Mas como solução alternativa, com Python 3.10 ou anterior, o padrão de linguagem C++03 se sobrepõe significativamente ao C11 e é então usado em seu lugar. |
| [2] | Baixe gratuitamente em https://www.visualstudio.com/en-us/downloads/download-visual-studio-vs.aspx (as edições da comunidade funcionam perfeitamente). A versão mais recente é recomendada, mas não obrigatória. Por outro lado, não há necessidade de oferecer suporte a versões anteriores ao Windows 10, e elas podem funcionar para você, mas o suporte a essas configurações está disponível apenas para usuários comerciais. |
Python 2 (2.6, 2.7) e Python 3 (3.4 — 3.13) são suportados. Se a qualquer momento houver uma versão estável do Python que não esteja nesta lista, tenha certeza de que ela está sendo trabalhada e será adicionada.
Importante
Para Python 3.4 e somente essa versão, precisamos de outra versão do Python como dependência de tempo de compilação .
O próprio Nuitka é totalmente compatível com todas as versões listadas, mas o Scons como ferramenta usada internamente não é.
Para essas versões, você também precisa de um Python2 ou Python 3.5 ou superior instalado, mas apenas durante o tempo de compilação. Isso é para uso com Scons (que orquestra a compilação C), que não suporta as mesmas versões do Python que Nuitka.
Além disso, no Windows, o Python2 não pode ser usado porque clcache não funciona com ele, é necessário instalar um Python 3.5 ou superior.
Nuitka encontra essas versões necessárias do Python (por exemplo, no Windows via registro) e você não deve notar isso enquanto elas estiverem instaladas.
Cada vez mais, outras funcionalidades estão disponíveis quando outro Python tem um determinado pacote instalado. Por exemplo, a compactação onefile funcionará para um Python 2.x quando for encontrado outro Python que tenha o pacote zstandard instalado.
Movendo binários para outras máquinas
Os binários criados podem se tornar executáveis independentemente da instalação do Python, com as opções --standalone e --onefile .
Sufixo de nome de arquivo binário
Os binários criados possuem um sufixo .exe no Windows. Em outras plataformas eles não possuem sufixo para modo autônomo, ou sufixo .bin , que você pode remover ou alterar livremente, ou especificar com a opção -o .
O sufixo para o modo de aceleração é adicionado apenas para garantir que o nome do script original e o nome do binário nunca colidam, para que possamos sobrescrever o binário com segurança sem destruir o arquivo de origem original.
Tem que ser CPython, Anaconda Python ou Homebrew
Você precisa da implementação padrão do Python, chamada "CPython", para executar o Nuitka porque está intimamente ligada aos detalhes de implementação dele.
Não pode ser da loja de aplicativos do Windows
É sabido que o Python da loja de aplicativos do Windows definitivamente não funciona, é verificado.
Não pode ser pyenv no macOS
Sabe-se que o macOS “pyenv” não funciona. Use o Homebrew para instalações Python autocompiladas. Mas observe que o modo autônomo será pior nessas plataformas e não será tão compatível com versões anteriores do macOS.
Sistemas operacionais suportados: Linux, FreeBSD, NetBSD, macOS e Windows (32 bits/64 bits/ARM).
Outros também funcionarão. Espera-se que a portabilidade seja geralmente boa, mas, por exemplo, o uso interno dos Scons do Nuitka pode ter que ser adaptado ou precisar que os sinalizadores sejam passados. Certifique-se de combinar a arquitetura do compilador Python e C, caso contrário você receberá mensagens de erro enigmáticas.
As arquiteturas suportadas são x86, x86_64 (amd64) e arm, provavelmente muitas, muitas mais.
Espera-se que outras arquiteturas também funcionem imediatamente, já que Nuitka geralmente não usa nenhuma especificação de hardware. Estes são apenas os testados e conhecidos por serem bons. Comentários são bem-vindos. Geralmente, as arquiteturas suportadas pelo Debian também podem ser consideradas boas e testadas.
A maneira recomendada de executar o Nuitka é <the_right_python> -m nuitka para ter certeza absoluta de qual interpretador Python você está usando, para que seja mais fácil combinar com o que o Nuitka possui.
A próxima melhor maneira de executar o Nuitka é a partir de um checkout ou arquivo de origem, sem alterações nas variáveis de ambiente, o mais notável é que você não precisa mexer com PYTHONPATH para o Nuitka. Você apenas executa os scripts nuitka e nuitka-run diretamente, sem quaisquer alterações no ambiente. Você pode adicionar o diretório bin ao seu PATH para sua conveniência, mas essa etapa é opcional.
Além disso, se você deseja executar com o interpretador correto, nesse caso, certifique-se de executar <the_right_python> bin/nuitka e seja bom.
Escolha o intérprete certo
Se você encontrar um SyntaxError , certamente escolheu o interpretador errado para o programa que está compilando.
Nuitka tem uma opção --help para mostrar o que pode fazer:
nuitka --ajuda
O comando nuitka-run é igual a nuitka , mas com um padrão diferente. Ele tenta compilar e executar diretamente um script Python:
nuitka-run --help
Esta opção diferente é --run e passa argumentos após a primeira não opção para o binário criado, portanto é um pouco mais semelhante ao que python simples fará.
Para a maioria dos sistemas, haverá pacotes na página de download do Nuitka. Mas você também pode instalá-lo a partir do código-fonte conforme descrito acima, mas também como qualquer outro programa Python, ele pode ser instalado por meio da rotina normal python setup.py install .
Aviso para integração com fluxos de trabalho do GitHub, existe este Nuitka-Action que você deve usar e que facilita muito a integração. Você deve começar com uma compilação local, mas isso será mais fácil para compilação multiplataforma com Nuitka.
Nuitka é licenciado sob a Licença Apache, Versão 2.0; você não poderá usá-lo, exceto em conformidade com a Licença.
Você pode obter uma cópia da Licença em http://www.apache.org/licenses/LICENSE-2.0
A menos que exigido pela lei aplicável ou acordado por escrito, o software distribuído sob a Licença é distribuído "COMO ESTÁ", SEM GARANTIAS OU CONDIÇÕES DE QUALQUER TIPO, expressas ou implícitas. Consulte a Licença para saber o idioma específico que rege as permissões e limitações da Licença.
Estas são etapas básicas se você não tiver nada instalado, é claro, se tiver alguma das peças, basta pular.
Baixe e instale o Python em https://www.python.org/downloads/windows
Selecione um Windows x86-64 web-based installer (Python de 64 bits, recomendado) ou instalador x86 executable (Python de 32 bits).
Verifique se está funcionando usando o comando python --version .
python -m pip install nuitka
Verifique usando o comando python -m nuitka --version
mkdir Olá Mundo
crie um arquivo python chamado hello.py
def talk(mensagem):return "Talk " + mensagemdef main():print(talk("Olá Mundo"))if __name__ == "__main__":main()Faça como faria normalmente. Executar o Nuitka em código que funciona incorretamente não é mais fácil de depurar.
python olá.py
python -m nuitka olá.py
Observação
Isso solicitará que você baixe uma ferramenta de cache C (para acelerar a compilação repetida do código C gerado) e um compilador C baseado em MinGW64, a menos que você tenha um MSVC adequado instalado. Diga yes para ambas as perguntas.
Execute o hello.exe criado perto de hello.py .
Para distribuir, construa com a opção --standalone , que não produzirá um único executável, mas uma pasta inteira. Copie a pasta hello.dist resultante para a outra máquina e execute-a.
Você também pode tentar --onefile que cria um único arquivo, mas certifique-se de que o mero autônomo esteja funcionando, antes de recorrer a ele, pois isso tornará a depuração apenas mais difícil, por exemplo, no caso de arquivos de dados ausentes.
Se você quiser compilar um programa inteiro recursivamente, e não apenas o arquivo único que é o programa principal, faça assim:
python -m nuitka --follow-importa programa.py
Observação
Existem controles mais refinados do que --follow-imports disponíveis. Considere a saída de nuitka --help . Incluir menos módulos na compilação, mas em vez disso usar Python normal, tornará a compilação mais rápida.
Caso você tenha um diretório de origem com arquivos carregados dinamicamente, ou seja, um que não pode ser encontrado recorrendo após instruções normais de importação através do PYTHONPATH (que seria a forma recomendada), você sempre pode exigir que um determinado diretório também seja incluído no executável:
python -m nuitka --follow-imports --include-plugin-directory=plugin_dir programa.py
Observação
Se você não fizer nenhuma importação dinâmica, simplesmente configurar seu PYTHONPATH no momento da compilação é o que você deve fazer.
Use --include-plugin-directory somente se você fizer chamadas __import__() que Nuitka não pode prever e que venham de um diretório, para tudo da instalação do Python, use --include-module ou --include-package .
Observação
O nome do arquivo resultante será program.exe no Windows, program.bin em outras plataformas, mas --output-filename permite alterar isso.
Observação
O binário resultante ainda depende do CPython e dos módulos de extensão C usados sendo instalados.
Se você quiser copiá-lo para outra máquina, use --standalone e copie o diretório program.dist criado e execute o program.exe (Windows) ou program (outras plataformas) colocado dentro.
Se você quiser compilar um único módulo de extensão, tudo que você precisa fazer é o seguinte:
python -m nuitka --module some_module.py
O arquivo resultante some_module.so pode então ser usado em vez de some_module.py .
Importante
O nome do arquivo do módulo de extensão produzido não deve ser alterado, pois o Python insiste em uma função derivada do nome do módulo como ponto de entrada; neste caso, PyInit_some_module e renomear o arquivo não mudará isso. Combine o nome do arquivo do código-fonte com o nome binário que deveria ser.
Observação
Se o módulo de extensão e seu código-fonte estiverem no mesmo diretório, o módulo de extensão será carregado. As alterações no código-fonte só terão efeito após a recompilação.
Observação
A opção --follow-import-to também funciona, mas os módulos incluídos só se tornarão importáveis depois que você importar o nome some_module . Se esses tipos de importações são invisíveis para Nuitka, por exemplo, criadas dinamicamente, você pode usar --include-module ou --include-package nesse caso, mas para importações estáticas isso não deve ser necessário.
Observação
Um módulo de extensão nunca pode incluir outros módulos de extensão. Você terá que criar uma roda para que isso seja possível.
Observação
O módulo de extensão resultante só pode ser carregado em um CPython da mesma versão e não inclui outros módulos de extensão.
Se você precisar compilar um pacote inteiro e incorporar todos os módulos, isso também é viável, use o Nuitka assim:
python -m nuitka --module algum_pacote --include-package=algum_pacote
Observação
A inclusão do conteúdo da embalagem deverá ser feita manualmente; caso contrário, o pacote estará quase vazio. Você pode ser mais específico se quiser e incluir apenas parte ou excluir parte dele, por exemplo, com --nofollow-import-to='*.tests' você não incluiria a parte de teste não utilizada do seu código.
Observação
Os arquivos de dados localizados dentro do pacote não serão incorporados por este processo; você mesmo precisa copiá-los com esta abordagem. Alternativamente, você pode usar a incorporação de arquivo do comercial Nuitka.
Para distribuição para outros sistemas, existe o modo autônomo, que produz uma pasta para a qual você pode especificar --standalone .
python -m nuitka --programa autônomo.py
Seguir todas as importações é o padrão neste modo. Você pode excluir módulos seletivamente dizendo especificamente --nofollow-import-to , mas um ImportError será gerado quando a importação for tentada no tempo de execução do programa. Isso pode causar um comportamento diferente, mas também pode melhorar o tempo de compilação se for feito com sabedoria.
Para que os arquivos de dados sejam incluídos, use a opção --include-data-files=<source>=<target> onde a origem é um caminho do sistema de arquivos, mas o destino deve ser especificado de forma relativa. Para o modo autônomo, você também pode copiá-los manualmente, mas isso pode fazer verificações extras, e para o modo onefile, não há possibilidade de cópia manual.
Para copiar alguns ou todos os arquivos em um diretório, use a opção --include-data-files=/etc/*.txt=etc/ onde você pode especificar padrões de shell para os arquivos e um subdiretório onde colocá-los, indicado pela barra final.
Importante
Nuitka não considera o código dos arquivos de dados, não inclui DLLs ou arquivos Python como arquivos de dados e espera que funcionem, mas não funcionarão, a menos que você realmente saiba o que está fazendo.
A seguir, arquivos de dados sem código são todos arquivos que não correspondem a esses critérios.
| Sufixo | Justificativa | Solução |
|---|---|---|
.py | Nuitka corta até mesmo os módulos stdlib a serem incluídos. Se não vir o código Python, não há dependências analisadas e, como resultado, simplesmente não funcionará. | Use --include-module neles |
.pyc | O mesmo que .py . | Use --include-module neles a partir do código-fonte. |
.pyo | O mesmo que .pyc . | Use --include-module neles a partir do código-fonte. |
.pyw | O mesmo que .py . | Para incluir vários programas, use vários argumentos --main . |
.pyi | Eles são ignorados porque são semelhantes a códigos e não são necessários em tempo de execução. Para o pacote lazy que realmente dependeria deles, criamos uma solução de tempo de compilação que elimina a necessidade. | Levante um problema se o software de terceiros precisar. |
.pyx | Eles são ignorados porque são códigos-fonte Cython não usados em tempo de execução | |
.dll | Eles são ignorados, pois geralmente não são arquivos de dados. Para os casos em que pacotes de terceiros realmente os utilizam como dados, por exemplo, pacotes .NET , resolvemos isso na configuração do pacote. | Crie a configuração do pacote Nuitka para eles, com a seção dll para o pacote que os utiliza. Em casos raros, a seção de arquivos de dados com configuração especial pode ser a coisa correta a fazer. |
.dylib | Eles são ignorados, pois são módulos de extensão do macOS ou DLLs. | Precisa adicionar configuração com seção dll ou depends que está faltando |
.so | Eles são ignorados, pois são módulos de extensão ou DLLs do Linux, BSD, etc. | Precisa adicionar configuração com seção dll ou depends que está faltando |
.exe | Eles são binários para o Windows. | Você pode adicionar a configuração do pacote Nuitka para incluí-los como DLLs e marcá-los como executable: yes |
.bin | Eles são binários para não Windows, caso contrário são iguais a .exe . |
Além disso, as pastas são ignoradas, são site-packages , dist-packages e vendor-packages que, de outra forma, incluiriam um virtualenv completo, o que nunca é bom que aconteça. E a pasta __pycache__ também é sempre ignorada. Em sistemas não-MacOS, o arquivo .DS_Store também é ignorado, e as pastas py.typed têm significado apenas para IDEs e são ignoradas como os arquivos .pyi .
Para copiar uma pasta inteira com todos os arquivos sem código, você pode usar --include-data-dir=/path/to/images=images que os colocará no destino, e se quiser usar o --noinclude-data-files opção --noinclude-data-files para removê-los. Os arquivos de código são detalhados acima, DLLs, executáveis, arquivos Python, etc. e serão ignorados. Para aqueles, você pode usar o formulário --include-data-files=/binaries/*.exe=binary/ para forçá-los, mas isso não é recomendado e conhecido por causar problemas em tempo de execução.
Para dados de pacotes, existe uma maneira melhor, ou seja, usar --include-package-data , que detecta automaticamente todos os arquivos de dados não codificados de pacotes e os copia. Ele até aceita padrões em estilo concha. Isso evita a necessidade de você mesmo encontrar o diretório do pacote e deve ser preferido sempre que disponível. Funcionalmente é muito semelhante a --include-data-dir mas tem a vantagem de localizar a pasta correta para você.
Com arquivos de dados, você está praticamente sozinho. Nuitka mantém registro daqueles que são necessários para pacotes populares, mas pode estar incompleto. Levante problemas se você encontrar algo neles. Melhor ainda, aumente os PRs com melhorias na configuração do pacote Nuitka. Queremos que o software de terceiros funcione imediatamente.
Quando isso estiver funcionando, você pode usar o modo onefile, se desejar.
python -m nuitka --onefile programa.py
Isto criará um único binário, que se extrai no destino, antes de executar o programa. Mas observe que o acesso aos arquivos relativos ao seu programa é afetado, certifique-se de ler a seção Onefile: Encontrando arquivos também.
# Crie um binário que descompacte em uma pasta temporáriapython -m nuitka --onefile program.py
Observação
Existem mais opções específicas da plataforma, por exemplo, relacionadas a ícones, tela inicial e informações de versão. Considere a saída --help para obter detalhes sobre elas e verifique a seção Ajustes.
Para a descompactação, por padrão, um caminho temporário de usuário exclusivo é usado e, em seguida, excluído, no entanto, este padrão --onefile-tempdir-spec="{TEMP}/onefile_{PID}_{TIME}" pode ser substituído por um caminho especificação e, em seguida, usar um caminho em cache, evitando descompactações repetidas, por exemplo, com --onefile-tempdir-spec="{CACHE_DIR}/{COMPANY}/{PRODUCT}/{VERSION}" que usa informações de versão, e diretório de cache específico do usuário.
Observação
Usar caminhos em cache será relevante, por exemplo, quando o Firewall do Windows entrar em ação, caso contrário, o binário será diferente cada vez que for executado.
Atualmente, estes tokens expandidos estão disponíveis:
| Símbolo | Para que isso se expande | Exemplo |
|---|---|---|
| {TEMP.} | Diretório de arquivos temporários do usuário | C:Usuários...AppDataLocalsTemp |
| {PID} | ID do processo | 2772 |
| {TEMPO} | Tempo em segundos desde a época. | 1299852985 |
| {PROGRAMA} | Nome completo do arquivo executável em tempo de execução do programa. | C: SomeWhereYourOnefile.exe |
| {PROGRAM_BASE} | Sem sufixo do nome do arquivo em tempo de execução do executável. | C: SomeWhereYourOnefile |
| {CACHE_DIR} | Diretório de cache do usuário. | C:UsersSomeBodyAppDataLocal |
| {EMPRESA} | Valor fornecido como --company-name | Nome da sua empresa |
| {PRODUTO} | Valor fornecido como --product-name | Seu nome do produto |
| {VERSÃO} | Combinação de --file-version e --product-version | 3.0.0.0-1.0.0.0 |
| {LAR} | Diretório inicial do usuário. | /casa/alguém |
| {NENHUM} | Quando fornecido para saídas de arquivo, None é usado | veja aviso abaixo |
| {NULO} | Quando fornecido para saídas de arquivo, os.devnull é usado | veja aviso abaixo |
Importante
É sua responsabilidade tornar o caminho fornecido exclusivo, no Windows um programa em execução será bloqueado e, embora seja possível usar um nome de pasta fixo, pode causar problemas de bloqueio nesse caso, onde o programa é reiniciado.
Normalmente, você precisa usar {TIME} ou pelo menos {PID} para tornar um caminho único, e isso se destina principalmente a casos de uso, onde, por exemplo, você deseja que as coisas residam em um local que você escolher ou cumpra suas convenções de nomenclatura.
Importante
Para desabilitar a saída e stderr com --force-stdout-spec e --force-stderr-spec os valores {NONE} e {NULL} alcançam isso, mas com efeitos diferentes. Com {NONE} , o identificador correspondente se torna None . Como resultado, por exemplo, sys.stdout será None , o que é diferente de {NULL} onde será apoiado por um arquivo apontando para os.devnull , ou seja, você pode escrever nele.
Com {NONE} , você pode, por exemplo, obter RuntimeError: lost sys.stdout caso seja usado; com {NULL} isso nunca acontece. No entanto, algumas bibliotecas tratam isso como entrada para seu mecanismo de registro e, no Windows, é assim que você é compatível com pythonw.exe , que se comporta como {NONE} .
Se você tiver uma criação de rodas orientada por setup.py , setup.cfg ou pyproject.toml para o seu software, colocar o Nuitka em uso é extremamente fácil.
Vamos começar com a abordagem mais comum setuptools , você pode, tendo o Nuitka instalado, é claro, simplesmente executar o alvo bdist_nuitka em vez do bdist_wheel . Ele pega todas as opções e permite especificar mais algumas, específicas de Nuitka.
# Para setup.py se você não usar outros sistemas de compilação:setup( # Os arquivos de dados devem ser manipulados pelo setuptools e não pelo Nuitka
package_data={"algum_pacote": ["algum_arquivo.txt"]},
..., # Isso é para passar as opções do Nuitka.
command_options={ 'nuitka': { # opção booleana, por exemplo, se você se importa com comandos de compilação C '--show-scons': True, # opções sem valor, por exemplo, impor usando Clang '--clang': Nenhum, # opções com valores únicos, por exemplo, habilite um plugin do Nuitka '--enable-plugin': "pyside2", # opções com vários valores, por exemplo, evite incluir módulos '--nofollow-import-to' : ["*.testes", "*.distutils"],
},
},
)# Para setup.py com outros sistemas de compilação:# A natureza tupla dos argumentos é exigida pela natureza obscura de# "setuptools" e plugins para ele, que insistem em compatibilidade total,# por exemplo "setuptools_rust"setup( # Arquivos de dados devem ser tratados pelo setuptools e não pelo Nuitka
package_data={"algum_pacote": ["algum_arquivo.txt"]},
..., # Isso é para passar as opções do Nuitka.
..., command_options={ 'nuitka': { # opção booleana, por exemplo, se você se importa com comandos de compilação C '--show-scons': ("setup.py", True), # opções sem valor, por exemplo, impor usando Clang '--clang': ("setup.py", None), # opções com valores únicos, por exemplo, habilitar um plugin do Nuitka '--enable-plugin': ("setup.py", "pyside2"), # opções com vários valores, por exemplo, evite incluir módulos '--nofollow-import-to': ("setup.py", ["*.tests", "*.distutils"]),
}
},
) Se, por algum motivo, você não puder ou não quiser alterar o destino, poderá adicioná-lo ao seu setup.py .
# Para setup.pysetup( ..., build_with_nuitka = Verdadeiro)
Observação
Para desativar temporariamente a compilação, você pode remover a linha acima ou editar o valor para False ou obter seu valor de uma variável de ambiente, se desejar, por exemplo, bool(os.getenv("USE_NUITKA", "True")) . Isso depende de você.
Ou você pode colocá-lo em seu setup.cfg
[metadados]build_with_nuitka = verdadeiro
E por último, mas não menos importante, Nuitka também suporta a nova meta build , então quando você já tiver um pyproject.toml , simplesmente substitua ou adicione este valor:
[build-system]requires = ["setuptools>=42", "wheel", "nuitka", "toml"]build-backend = "nuitka.distutils.Build"# Os arquivos de dados devem ser manipulados por setuptools e não por Nuitka [tool.setuptools.package-data]some_package = ['data_file.txt'] [tool.nuitka]# Estes não são recomendados, mas tornam óbvio o seu efeito.# opção booleana, por exemplo, se você se importa com comandos de compilação C, os primeiros# traços são omitidosshow-scons = true# opções com valores únicos, por exemplo, enable um plugin de Nuitkaenable-plugin = "pyside2"# opções com vários valores, por exemplo, evite incluir módulos, aceita# list argument.nofollow-import-to = ["*.tests", "*.distutils"]
Observação
Para o requisito nuitka acima de caminhos absolutos como C:Users...Nuitka também funcionará no Linux, use um caminho absoluto com duas barras iniciais, por exemplo //home/.../Nuitka .
Observação
Qualquer que seja a abordagem adotada, os arquivos de dados nessas rodas não são gerenciados pelo Nuitka, mas pelas ferramentas de configuração. Você pode, no entanto, usar a incorporação do arquivo de dados do comercial Nuitka. Nesse caso, você realmente incorporaria os arquivos dentro do próprio módulo de extensão, e não como um arquivo na roda.
Se você tiver vários programas, cada um deles deveria ser executável, no passado você tinha que compilar várias vezes e implantar todos eles. Com o modo autônomo, isso, é claro, significava que você desperdiçava bastante, pois o compartilhamento das pastas poderia ser feito, mas não era realmente suportado pelo Nuitka.
Digite Multidist . Existe uma opção --main que substitui ou adiciona ao argumento posicional fornecido. E pode ser dado várias vezes. Quando fornecido várias vezes, Nuitka criará um binário que contém o código de todos os programas fornecidos, mas compartilhando os módulos usados neles. Portanto, eles não precisam ser distribuídos várias vezes.
Vamos chamar o nome base do caminho principal e do ponto de entrada. Os nomes destes devem, é claro, ser diferentes. Então o binário criado pode executar qualquer ponto de entrada e reagirá ao que sys.argv[0] aparece para ele. Portanto, se executado da maneira correta (com algo como subprocess ou API do sistema operacional, você pode controlar esse nome), ou renomeando ou copiando o binário, ou criando um link simbólico para ele, você poderá alcançar o milagre.
Isto permite combinar programas muito diferentes em um.
Observação
Este recurso ainda é experimental. Use com cuidado e relate suas descobertas caso encontre algo que seja um comportamento indesejável
Este modo funciona com aceleração autônoma, onefile e mera aceleração. Não funciona no modo módulo.
Para integração com fluxos de trabalho do GitHub existe este Nuitka-Action que você deve usar e que facilita muito a integração. Você deve começar com uma compilação local, mas isso será mais fácil para compilação multiplataforma com Nuitka.
Este é um exemplo de fluxo de trabalho baseado em todos os três sistemas operacionais
empregos:construir:estratégia:matriz:os: [macos-latest, ubuntu-latest, windows-latest]
executado: ${{ matriz.os }}
passos:
- nome: Repositório de check-out usa: actions/checkout@v4 - nome: Configuração Python usa: actions/setup-python@v5 com: python-version: '3.10' cache: 'pip' cache-dependency-path: | **/requirements*.txt - nome: Instale suas dependências, execute: | pip install -r requisitos.txt -r requisitos-dev.txt - nome: Construir executável com Nuitka usa: Nuitka/Nuitka-Action@main com: nuitka-version: main script-name: your_main_program.py # muitas mais opções de Nuitka disponíveis , consulte o documento de ação, mas é melhor # usar as opções nuitka-project: em seu código, então, por exemplo, você pode fazer # a diferença para o macOS e criar um pacote de aplicativos lá. onefile: true - name: Upload Artifacts usa: actions/upload-artifact@v3 com: name: ${{ runner.os }} Caminho de construção: | # corresponde ao que foi criado para os 3 sistemas operacionais build/*.exe build/*.bin build/*.app/**/* Se o seu aplicativo for uma GUI, por exemplo, your_main_program.py deve conter esses comentários conforme explicado em Opções do Nuitka no código, pois no macOS isso deve ser um pacote.
# Modo de compilação, independente em qualquer lugar, exceto no macOS, há pacote de aplicativos# nuitka-project-if: {OS} in ("Windows", "Linux", "FreeBSD"):# nuitka-project: --onefile# nuitka-project -if: {OS} == "Darwin":# nuitka-project: --standalone# nuitka-project: --macos-create-app-bundle#Para uma boa aparência, você pode especificar ícones. No Windows, você pode fornecer um arquivo de ícone, um modelo executável ou um arquivo PNG. Tudo isso funcionará e pode até ser combinado:
# Eles criam binários com ícones no Windowspython -m nuitka --onefile --windows-icon-from-ico=your-icon.png program.py python -m nuitka --onefile --windows-icon-from-ico=seu-icon.ico programa.py python -m nuitka --onefile --windows-icon-template-exe=your-icon.ico program.py# Eles criam pacotes de aplicativos com ícones no macOSpython -m nuitka --macos-create-app-bundle --macos- app-icon=seu-icon.png program.py python -m nuitka --macos-create-app-bundle --macos-app-icon=seu-icon.icns program.py
Observação
Com o Nuitka, você não precisa criar ícones específicos da plataforma, mas em vez disso ele converterá, por exemplo, PNG, mas também outros formatos durante a construção.
Os direitos para um pacote de aplicativos macOS podem ser adicionados com a opção --macos-app-protected-resource , todos os valores estão listados nesta página da Apple
Um valor de exemplo seria --macos-app-protected-resource=NSMicrophoneUsageDescription:Microphone access para solicitar acesso a um microfone. Após os dois pontos, deve ser fornecido o texto descritivo.
Observação
Esteja ciente de que, no caso provável de usar espaços na parte de descrição, você precisará citá-los para que seu shell chegue até Nuitka e não seja interpretado como argumentos de Nuitka.
No Windows, o console não é aberto por programas, a menos que você diga. O padrão de Nuitka é não mostrá-lo, mas você pode forçá-lo usando --console=force , então o programa abrirá uma nova janela de terminal quando for executado.
As telas iniciais são úteis quando a inicialização do programa é lenta. A inicialização do Onefile em si não é lenta, mas seu programa pode ser, e você não pode realmente saber quão rápido será o computador usado, então pode ser uma boa ideia tê-los. Felizmente, com o Nuitka, eles são fáceis de adicionar ao Windows.
Para a tela inicial, você precisa especificá-la como um arquivo PNG e, em seguida, certifique-se de desabilitar a tela inicial quando seu programa estiver pronto, por exemplo, tiver concluído as importações, preparado a janela, conectado ao banco de dados e desejar a tela inicial ir embora. Aqui estamos usando a sintaxe do projeto para combinar o código com a criação, compile isto:
# nuitka-project: --onefile# nuitka-project: --onefile-windows-splash-screen-image={MAIN_DIRECTORY}/Splash-Screen.png# Seja o que for, obviamenteprint("Atrasando a inicialização em 10s..." )import time, tempfile, ostime.sleep(10)# Use este código para sinalizar a remoção da tela inicial.if "NUITKA_ONEFILE_PARENT" em os.environ: splash_filename = os.path.join( tempfile.gettempdir(), "onefile_%d_splash_feedback.tmp" % int(os.environ["NUITKA_ONEFILE_PARENT"]),
) if os.path.exists(splash_filename): os.unlink(splash_filename)print("Concluído... o splash deve ter desaparecido.")
...# O resto do seu programa vai aqui.Para análise do seu programa e da embalagem do Nuitka, está disponível o Relatório de Compilação. Você também pode criar relatórios personalizados fornecendo seu modelo, com alguns deles integrados ao Nuitka. Esses relatórios contêm todas as informações detalhadas, por exemplo, quando um módulo tentou ser importado, mas não foi encontrado, você pode ver onde isso acontece. Para relatórios de bugs, é altamente recomendável fornecer o relatório.
Você pode anexar informações de direitos autorais e marca registrada, nome da empresa, nome do produto e assim por diante à sua compilação. Isso é então usado nas informações de versão do binário criado no Windows ou no pacote de aplicativos no macOS. Se você encontrar algo que está faltando, por favor nos avise.
Por padrão, o Nuitka compila sem --deployment o que deixa um conjunto de proteções e auxiliares de segurança ativados, que visam depurar usos errados do Nuitka.
Este é um novo recurso e implementa várias proteções e auxiliares, que estão documentados aqui.
Portanto, após a compilação, sys.executable é o binário compilado. Em caso de pacotes como multiprocessing , joblib ou loky o que estes normalmente fazem é esperar correr de um python completo com sys.executable e depois poder usar suas opções como -c command ou -m module_name e depois ser capaz de poder Inicie outro código temporária ou permanentemente como daemon de serviço.
Com Nuitka, no entanto, isso executa seu programa novamente e coloca esses argumentos, no sys.argv , onde você os ignora, e então você se quisesse novamente para lançar os daemons do ajudante. Às vezes, isso acaba gerando processos de contagem de CPU que geram processos de contagem de CPU que ... isso é chamado de bomba de garfo e, com quase todos os sistemas, que os congela facilmente até a morte.
É por isso que, por exemplo, isso acontece com o padrão nuitka:
./hello.dist/hello.bin -l tolo -m foom -n foon -o fooo -p Erro, o programa tentou se chamar com o argumento '-m'. Desativar com '--não-deployment-flag = auto-execução'.
Seu programa pode muito bem ter sua própria linha de comando analisar e não usar um pacote não suportado que tenta reexecionar. Nesse caso, você precisa em tempo de compilação para usar --no-deployment-flag=self-execution que desativa esse guarda específico.
Alguns pacotes produzem o que eles acham que são informações úteis sobre o motivo de uma importação fracassada pode significar. Com os programas compilados, muitas vezes são simplesmente errados. Tentamos reparar aqueles no modo de não implantação. Aqui está um exemplo, onde alteramos uma mensagem que solicita a instalação do PIP (que não é o problema) para apontar o usuário para o comando de inclusão que faz com que um plug -in imageio funcione.
- Módulo-name: 'imageio.core.imopen'
Anti-Bloat:
-Replacamentos_plain: '`pip instalar imageio [{config.install_name}]` para instalá-lo': '`--include-module = {config.module_name}` com nuitka para incluir it'err_type = importer': 'err_type = RunTimeError 'Quando:' Não implantação ' O modo de implantação é relativamente novo e possui constantemente mais recursos adicionados, por exemplo, algo para FileNotFoundError deve estar em breve.
É claro que todos esses ajudantes podem ser desativados imediatamente com-de --deployment , mas lembre-se de que, para a depuração, convém reativá-lo. Você pode usar as opções do projeto Nuitka e uma variável de ambiente para tornar isso condicional.
Você deve desativar todos eles?
Acreditamos que a desativação só deve acontecer seletivamente, mas com as atualizações do PYPI, o seu código muda, todos esses problemas podem voltar. A economia de espaço do modo de implantação é insignificante, então tente não fazê -lo, mas revise o que existe e e Se você sabe que isso não pode afetá -lo ou, se o fizer, não precisará. Alguns dos futuros, serão claramente voltados para o uso do nível do iniciante.
Os binários compilados no Windows com configurações padrão de Nuitka e nenhuma ação adicional tomada podem ser reconhecidas por alguns fornecedores da AV como malware. Isso é evitável, mas apenas no comercial de Nuitka, há suporte e instruções reais sobre como fazê -lo, vendo isso como um comercial típico que apenas precisa. https://nuitka.net/doc/commercial.html
Para o Linux Standalone, é muito difícil construir um binário que funcione em outras versões do Linux. Isso ocorre principalmente porque no Linux, muito software é construído especificamente direcionado a DLLs de concreto. Coisas como Glibc usadas são então codificadas no binário construído e não funcionará com um glibc mais antigo, apenas para dar um exemplo crítico.
A solução é desenvolver o sistema operacional mais antigo que você deseja ver suportado. Escolher isso e configurá -lo pode ser tedioso, então pode ser login e mantê -lo
