Melhora a obtenção das informações do sistema em que o executável foi feito.

[samuelveigarangel]

Descrição

• Adiciona funções em build_metadata.py que obtem informações do sistema.
• Adiciona testes
• Remove build_info.py

Como poderia ser testado

Executar o script de compilação de acordo com o seu sistema.

[pitangainnovare]

Ótimo que tenha norteado o script a forçar uso de Qt, quando conveniente. Mas infelizmente outro bug surgiu: o diálogo de seleção de arquivos não mostra nada e pelo que notei, parece ser um bug conhecido dessa backend (pywebview com Qt). Veja

Mais precisamente: o HTML tem accept=".zip". O pywebview passa isso para o diálogo de arquivo do backend. Com Qt, esse filtro parece estar afetando a navegação/listagem de diretórios de forma ruim (não mostra arquivos, nem diretórios). Em GTK, funciona normalmente.

Talvez seja o caso de forçar a app a ficar em GTK.

[pitangainnovare]

É realmente necessário informar o usuário sobre isso de converter para AppImage?
No futuro pode ser interessante adotarmos o AppImage para disponibilizar os executáveis.

[Rossi-Luciano]

Ambiente de teste

• OS: Ubuntu 24.04.4 LTS (kernel 6.8.0-124-generic, x86_64)
• Python: 3.12.3
• Pacotes de sistema relevantes já instalados via apt: python3-pyqt5 5.15.10, python3-gi 3.48.2, gir1.2-webkit2-4.1 2.52.3

Resumo

Testei localmente o #19 (que já inclui todo o diff do #17) rodando o app em modo browser e executando packaging/build_linux.sh do zero.

Modo browser (spsvalidator --browser): funciona, e o rodapé agora mostra corretamente "Build de desenvolvimento (Linux)" em vez do "Compilado para macOS 26.3.1" que aparece no #17. Esse último mostra a plataforma errada porque usa o build_info.py estático commitado, com valores de uma build antiga feita num Mac. O #19 corrige isso ao detectar a plataforma em runtime.

Script de build (bash packaging/build_linux.sh): falha antes de gerar o binário, com este erro do PyInstaller:

ERROR: Aborting build process due to attempt to collect multiple Qt bindings packages:
attempting to run hook for 'PyQt6', while hook for 'PyQt5' has already been run!
PyInstaller does not support multiple Qt bindings packages in a frozen application:
either ensure that the build environment has only one Qt bindings package installed,
or exclude the extraneous bindings packages via the module exclusion mechanism.

dist/ fica vazio, nenhum executável é gerado.

Causa raiz: a venv de build usa --system-site-packages (build_linux.sh), então enxerga o python3-pyqt5 que já vem instalado via apt neste Ubuntu. Ao mesmo tempo, o script instala pywebview[qt], que traz um PyQt6 novo via pip dentro da própria venv. O PyInstaller não aceita empacotar dois bindings Qt ao mesmo tempo e aborta. Isso deve reproduzir em qualquer máquina Ubuntu/Debian que já tenha PyQt5 do sistema, que é justamente o ambiente que a maioria dos usuários Linux vai ter.

Outros pontos observados na revisão do código

1. spsvalidator_linux.spec: o excludes remove black, pytest, isort e plataformas de outros SOs, mas nunca exclui PyQt5, PyQt6 ou qtpy. Sem isso, qualquer binding Qt "extra" que vaze do --system-site-packages entra no build. É a causa do erro acima.
2. build_linux.sh: a instrução de apt impressa quando falta GTK sugere gir1.2-webkit-6.0, mas o .spec importa gi.repository.WebKit2, que vem de gir1.2-webkit2-4.1 (pacote diferente). Quem segue a instrução do próprio script ainda assim não resolve o import.
3. build_linux.sh: a checagem [[ -z "${VIRTUAL_ENV:-}" ]] para decidir se cria a venv de build não cobre ambientes conda (que normalmente não setam VIRTUAL_ENV), então a resolução de python3 pode continuar indo pro Python do conda em vez do sistema.
4. spsvalidator_linux.spec: a coleta de dados do packtools regrediu de --collect-all packtools (script antigo) para collect_data_files("packtools"). Isso deixa de coletar hiddenimports e binaries, então submódulos alcançados só por import dinâmico podem faltar no binário final.
5. version.py e spsvalidator_linux.spec: no binário empacotado, importlib.metadata.version("spsvalidator") deve sempre lançar PackageNotFoundError, porque o .spec só faz copy_metadata("setuptools"), nunca copy_metadata("spsvalidator"). O fallback silencioso pra "0.0.0" faz o app empacotado mostrar versão 0.0.0 sempre. Não cheguei a gerar o binário pra confirmar isso ao vivo, já que o build trava antes, no ponto 1, mas vale conferir assim que o build passar.
6. build_metadata.py: version, _, build, _ = platform.win32_ver() desempacota errado. A tupla real é (release, version, csd, ptype), então a versão real do Windows acaba descartada.

Sugestão

Concordo com o comentário do @pitangainnovare sobre forçar o app a ficar em GTK. Acho que resolve o ponto 1 (build quebrado) e também o bug do diálogo de arquivos com Qt relatado na review. Bastaria excluir os bindings Qt/PyQt de forma explícita no .spec:

excludes=[
    "webview.platforms.qt",
    "PyQt5",
    "PyQt6",
    "qtpy",
    "webview.platforms.android",
    "webview.platforms.cocoa",
    "webview.platforms.winforms",
    "webview.platforms.edgechromium",
    "black",
    "pytest",
    "isort",
],

E remover a instalação e a checagem de pywebview[qt] em build_linux.sh, mantendo o build só GTK que a descrição do PR já promete.

[Rossi-Luciano]

Detalhes completos da revisão e da reprodução do build quebrado no comentário acima.