tag:github.com,2008:https://github.com/DaviKdS/GenPyEXE/releasesTags from GenPyEXE2026-08-05T17:11:49Ztag:github.com,2008:Repository/1316367154/v1.1.12026-08-05T17:25:37Zv1.1.1<p>GenPyEXE 1.1.1</p>
<p>Correcao de diagnostico. Quem ja usa a 1.1.0 corretamente nao ve diferenca.</p>
<p>O aplicativo que importava o proprio genpyexeks - quase sempre o exemplo da API
<br />copiado da documentacao para dentro do arquivo errado - era empacotado sem aviso
<br />nenhum, e so quebrava na maquina de quem instalasse, com um
<br />"ModuleNotFoundError: No module named 'genpyexeks'" sem contexto. O genpyexe
<br />build agora varre o projeto pela AST e aponta arquivo e linha logo na analise,
<br />antes de gastar os minutos da compilacao. E aviso, nao erro: quem empacota uma
<br />ferramenta baseada no genpyexeks segue livre para faze-lo.</p>
<p>O genpyexeks tambem deixou de ser inferido como dependencia do aplicativo. Sem
<br />requirements.txt as dependencias saem dos imports detectados, entao o mesmo
<br />trecho copiado o instalava no ambiente de build e arrastava PyInstaller, Jinja2,
<br />Pillow, Typer e Rich para dentro do executavel - um .exe dezenas de MB maior que
<br />disparava um build inteiro a cada abertura.</p>
<p>Os exemplos da API no README passam a dizer em que arquivo o codigo vai
<br />(build.py, fora do aplicativo). A omissao era a origem do engano.</p>github-actionstag:github.com,2008:Repository/1316367154/v1.1.02026-08-05T14:02:35Zv1.1.0<p>GenPyEXE 1.1.0</p>
<p>Ainda nao publicado no PyPI - esta versao para na Release do GitHub.</p>
<p>genpyexe helper grava um resources.py no seu projeto, com resource_path(),
<br />que resolve o caminho igual em desenvolvimento, --onefile e --onedir, e
<br />user_data_dir(), para o que o aplicativo precisa gravar. Empacotar assets/
<br />nunca bastou: dentro do executavel os dados vao para uma pasta temporaria, e
<br />um open("assets/logo.png") falha. O arquivo gerado usa so a biblioteca padrao,
<br />entao nao cria dependencia do seu app com o GenPyEXE.</p>
<p>genpyexe recipes abre o catalogo de receitas por biblioteca, ate agora
<br />invisivel e obrigatorio, e --no-recipes desliga a camada automatica sem
<br />descartar o que voce declarou em --hidden-import, --collect-all e --exclude.</p>
<p>LICENSE-EXCECAO-DE-SAIDA.md dispensa a atribuicao da MIT para tudo que a
<br />ferramenta grava no seu projeto - .spec, .iss, resources.py, notices e
<br />executaveis. O que se gera e seu; o genpyexeks continua MIT integral.</p>
<p>304 testes, ruff limpo.</p>github-actionstag:github.com,2008:Repository/1316367154/v1.0.12026-08-04T16:53:19Zv1.0.1<p>GenPyEXE 1.0.1</p>
<p>Publicado no PyPI: pip install genpyexe</p>
<p>Corrige o travamento ao construir a partir do GenPyEXE.exe: o executavel
<br />congelado se elegia interpretador Python e lancava copias de si mesmo,
<br />segurando o build ate a janela ser fechada a mao.</p>
<p>Corrige tambem o THIRD_PARTY_NOTICES, que podia omitir as dependencias
<br />realmente empacotadas - incluindo a LGPL do Qt.</p>
<p>A compressao do instalador passa a ser escolhida pelo modo de empacotamento,
<br />cortando pela metade o tempo dessa etapa em --onefile.</p>
<p>Novidades: genpyexe init --yes e ensaio no TestPyPI no workflow de release.</p>github-actionstag:github.com,2008:Repository/1316367154/v1.0.02026-07-29T16:56:34ZGenPyEXE 1.0.0<p>GenPyEXE 1.0.0</p>
<p>Primeira versao. Gera executavel Windows portatil e instalador 64 bits a
<br />partir de uma pasta de projeto Python.</p>
<p>Artefatos:
<br /> GenPyEXE-1.0.0-portable-x64.exe - executavel portatil
<br /> GenPyEXE-1.0.0-setup-x64.exe - instalador 64 bits
<br /> THIRD_PARTY_NOTICES.txt - licencas dos componentes empacotados</p>DaviKdS