Build do SciPy para Windows no Python 3.12 é considerada um pequeno milagre

• O build do SciPy para Windows no conda-forge foi disponibilizado dois dias após o lançamento do Python 3.12.0, fazendo com que a migração do SciPy para o Python 3.12 avançasse com apenas alguns dias de atraso, em vez de ficar parada por meses
• Com a remoção do distutils da biblioteca padrão no Python 3.12, o SciPy decidiu migrar do numpy.distutils para a ferramenta de build Meson
• O Meson estava prestes a rejeitar a combinação MSVC+gfortran usada pelo conda-forge, e no Windows não havia um compilador Fortran gratuito compatível em ABI que o conda-forge pudesse usar
• O conda-forge previa que, se não conseguisse reconstruir o SciPy no Windows, a migração de pelo menos cerca de 1.000 pacotes que dependem do SciPy seria atrasada em todas as plataformas, ou então o Windows teria de ser excluído da migração do Python
• O LLVM 17.0 foi a primeira versão a remover a flag -flang-experimental-exec no Flang, que é estimado em um nível de maturidade “0.8 level maturity”
• Depois de adicionar o tratamento de llvm-flang no Meson, foi possível compilar e instalar o SciPy com sucesso, e os testes passaram 100% com 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning {p:100}

[GN⁺]

Opiniões do Hacker News

• Foi um texto realmente excelente e agora entendo por que o pip install falhava no Python 3.12, mas daqui para frente o cenário parece mais promissor
  Gosto de Python, mas isso também ajuda a entender por que o empacotamento em Python é uma bagunça ainda administrável
  A causa não é o Python em si, mas a falta de padronização das ferramentas de build em C/C++/Fortran e o tamanho gigantesco do ecossistema; em certa medida, é uma complexidade impossível de eliminar
  O simples fato de isso funcionar já é quase um milagre

  • Sim, é aí que está a razão fundamental da complexidade do empacotamento em Python
    O sucesso do Python se deve, em grande parte, ao fato de ter sido possível usar pacotes essenciais de linguagens mistas, e os gerenciadores de pacotes de outras linguagens populares quase não lidam com esse tipo de problema
    Por exemplo, o cargo do Rust é excelente, mas em geral pode pressupor o empacotamento de código exclusivamente em Rust; além disso, embora Rust seja uma linguagem compilada, a própria linguagem “possui” o compilador, então uma estratégia de distribuição por build a partir do código-fonte funciona
    Não sei como o cargo lida com Fortran por padrão, mas, se pacotes cargo importantes exigissem código Fortran no Windows, acho que dificilmente funcionaria bem
    A maior melhoria no ecossistema Python foi a padronização do formato de pacote binário wheel, e só então o ecossistema científico de Python começou a prosperar de verdade no Windows
    Ainda assim, compatibilidade binária é uma enorme dor de cabeça, especialmente quando atravessa linguagens e CPUs
  • É difícil dizer que isso não tem nada a ver com Python, porque a razão de existirem esses bindings FFI é que Python é lento demais
  • Concordo com a ideia de que “o simples fato de isso funcionar já é um milagre”
    A complexidade do ecossistema de software parece crescer exponencialmente, e fico curioso sobre o que, no fim das contas, impede que tudo caminhe para um colapso ao estilo Torre de Babel
    Claro que não é um problema exclusivo de software, mas é um bom exemplo
  • Foi um texto que realmente abriu os olhos
    Vejo com frequência pessoas compararem seu gerenciador de pacotes favorito com o do Python e concluírem que o Python é péssimo, mas na prática não é bem assim
    O que eu não entendo muito bem, porém, é por que o pessoal do Python não usa bibliotecas matemáticas em C/C++ em vez de Fortran
  • O problema real parece ser que Python tende a atrair pessoas sem formação em desenvolvimento de software
    É uma bagunça em cima de outra bagunça

• Quando o Linux era um caso periférico meio rangente, mantido por hackers com coordenação frouxa e às vezes com restrições ideológicas pouco práticas, era fantástico ver pessoas brilhantes se esforçando enormemente para dar suporte a ele
  Mas agora que esse caso periférico rangente virou um sistema proprietário em que as restrições são praticamente hostis, operado por senhores feudais cibernéticos, é difícil ver o trabalho de dar suporte a isso de forma tão positiva quanto antes
  Por um lado, é realmente admirável a profunda consideração de tentar tornar essas ferramentas acessíveis a todos, e aplaudo esse trabalho
  Não estou de forma alguma dizendo para mudarem de direção; é só algo que me faz refletir
  Antes eu pensava “uau, ainda bem que esse trabalho está sendo feito”; agora penso mais “uau, o que essas pessoas brilhantes poderiam ter realizado se não precisassem se dedicar a esse tipo de coisa”

  • Na verdade, não é algo que eles sejam obrigados a fazer
    Como já foi dito várias vezes, os desenvolvedores do SciPy são voluntários
    Boa parte da história explica por que o SciPy não teve alternativa a não ser torcer para que alguém criasse um compilador Fortran open source para Windows, e a salvação parece ter vindo principalmente de desenvolvedores da NVIDIA
  • Nem isso é o ponto central
    O SciPy está pagando o preço da decisão tola e extremamente enviesada dos principais desenvolvedores do Python de escolher MSVC em vez de MinGW como toolchain para Python no Windows
    Acredito que a motivação tenha vindo do patrocínio da Microsoft
    Há bastantes funcionários da Microsoft na lista de core developers; eles são pagos pela Microsoft para participar dessa lista e, além disso, a Microsoft também banca os custos dos servidores de CI do projeto CPython
    Se Python não usasse ferramentas proprietárias em sua toolchain, todo esse problema poderia ter sido evitado

• A afirmação de que “o Meson tentou rejeitar a combinação MSVC+gfortran usada no conda-forge” soa como bug
  Acho que o objetivo de uma ferramenta de build é executar os comandos que mandaram executar, não barrar dizendo “desculpe, Dave”

  • Na prática, quem reclama é o linker do MSVC
    O problema é que os runtimes C usados pelo MSVC e pelo gfortran, em especial a própria biblioteca de runtime do gfortran, que é escrita em C, não são compatíveis em ABI
    A solução de contorno usada pelo NumPy era linkar os objetos Fortran em uma DLL, acrescentar uma camada indireta via biblioteca de importação e assim apaziguar o MSVC
    Por isso era necessário trabalho extra para criar essa DLL
    Isso precisava ser feito no arquivo de descrição do build ou no Meson, mas o pessoal do SciPy não queria implementar essa camada indireta em nenhum dos dois lugares, e os desenvolvedores do Meson também não estavam muito dispostos a ajudar ativamente
    Claro que os desenvolvedores do Meson ajudaram em coisas gerais, como suporte a Fortran e Cython, mas não queriam fornecer um apoio perigoso
    Na prática, isso era quase um hack e, por exemplo, só funcionava porque o lado Fortran não usava arquivos abertos pelo lado Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • O texto era bem escrito e detalhado, mas fiquei um pouco surpreso com a afirmação de que o Meson é “amplamente usado em projetos C e C++”
    Pessoalmente, vi Bazel com mais frequência do que Meson
    Como o Meson é escrito em Python, parece ter parecido uma boa escolha para o SciPy e, no fim, deu certo, então é algo a comemorar
    Ainda assim, apesar de várias esquisitices, complexidades e problemas, acho que o CMake continua sendo algo próximo do padrão
  • O Meson faz mais do que simplesmente executar os comandos indicados pelo usuário
    Ele também pode sintetizar os próprios comandos para dar suporte a MSVC/gcc/clang
    Se você pede para ele sintetizar comandos para uma combinação que ele não conhece, é natural que ele não tenha escolha a não ser dizer “desculpe, Dave”
  • Concordo
    Deixo claro que sou o autor de um sistema de build concorrente do Meson que será divulgado em breve
    Dito isso, um pequeno rant pouco conhecido que me fez perceber exatamente o que acabei de dizer é o [1]
    Em resumo, um sistema de build deve executar os comandos que o usuário mandou executar, ponto
    Porque, às vezes, o programador realmente sabe o que está fazendo
    Tenho vergonha de admitir, mas antes de ler aquele comentário eu estava pensando em tornar meu sistema de build algo mágico
    Depois de lê-lo, porém, percebi que o motivo pelo qual as pessoas odeiam sistemas de build é justamente essa “mágica”
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Achei que, nesses casos, todo mundo simplesmente usasse WSL2 e pronto
  Qual seria o motivo para querer compilar uma versão nativa para Windows?

  • Isso é como perguntar a desenvolvedores de macOS por que eles não deixam de querer builds nativos e simplesmente trabalham em uma máquina virtual Linux
    Trabalhar em uma máquina virtual é inconveniente e tem menos integração
  • Muito mais pesquisadores usam Windows do que se imagina
    Estudantes também
  • Acho que grandes empresas, onde é quase impossível receber uma máquina que não seja Windows, devem ser uma base importante de usuários
  • Foi uma verdadeira salvação a Microsoft e a NVIDIA terem resolvido os problemas de drivers CUDA no WSL2
    Especialmente quando dá para usar o Docker Desktop em cima disso
    É tirar o melhor de uma situação longe do ideal

• O κατα em καταστροφή não significa “subitaneidade”, mas algo mais próximo de “para baixo” ou “de acordo com”, com uma forte implicação de virar para uma direção ruim
  O oposto de κατα normalmente é ανα, mas αναστροφή significa literalmente “virar para cima” ou inversão
  Portanto ευστροφη, isto é, eustrophe, talvez seja uma cunhagem melhor para significar “boa virada”
  Ainda assim, se você vencer uma discussão com JRR Tolkien sobre criação de palavras, isso seria ευκαταστροφη, ou seja, boa sorte
  No geral, gosto de como capta uma graça transbordante, algo que traz alegria e felicidade ao mundo

  • O kata em katastrofi na verdade é mais próximo de “against”, então katastrofi corresponde a algo que “vira as costas”

• Tenho a impressão de que os melhores BLAS em geral são em C
  Coisas como MKL, BLIS e OpenBLAS
  Fico curioso até onde teria sido possível chegar só com C e Python
  Também fico curioso se, começando hoje, talvez simplesmente escolhessem libflame
  Claro que o SciPy tem muitos outros recursos, como métodos iterativos e matrizes esparsas, então talvez fosse difícil evitar Fortran
  Ainda assim, Fortran é uma ótima linguagem, e é bom ver que a situação das ferramentas no Windows pelo menos começou a melhorar

  • A remoção de Fortran do SciPy já foi discutida algumas vezes, mas não avançou pelos motivos mencionados acima
    O próprio SciPy também contém muito código Fortran, e reescrevê-lo exigiria anos de trabalho
    Depois que isso se tornou possível, algumas partes centrais que usavam Fortran chegaram a ser removidas
    Por exemplo, as partes relacionadas a FFT
  • Sinceramente, eu não esperava ver em 2023 uma frase como “Fortran é uma ótima linguagem, e é bom ver que a situação das ferramentas no Windows começou a melhorar”

• Excelente texto
  Passei muito tempo este ano modernizando um projeto C++ com CMake que tem bindings para Python e, depois de conseguir adicioná-lo com sucesso ao conda-forge como um novo feedstock, posso dizer com confiança
  Se eu me tornasse o Imperador-Deus, minha primeira medida relacionada a TI seria erradicar o Windows de todos os universos para sempre

• Uma pergunta bem ingênua, mas a semântica de Fortran é tão diferente assim a ponto de não dar para primeiro converter para C e depois compilar com um compilador C?
  Depois disso, não seria possível fazer a manutenção em C?
  Não parece que haja muita gente de Fortran mantendo bibliotecas tão antigas, mas ainda assim a manutenção não é necessária?

  • É possível, se tudo bem ficar mais lento
    Fortran não tem ponteiros, só arrays, e os argumentos de função não podem ter aliases; então, deixando de lado por enquanto o horror dos blocos COMMON, fica mais fácil fazer otimizações agressivas e vetorização
    As bibliotecas matemáticas padrão em Fortran simplesmente funcionam bem e são rápidas
    Em C/C++ também é possível escrever código com velocidade equivalente, especialmente usando a palavra-chave restrict de C
    Mas, ao converter código existente por uma etapa com f2c, em muitos casos o desempenho piora bastante
  • Fortran é uma linguagem de nível mais alto que C
    Também há bastante desenvolvedores Fortran
    Para desenvolvimento de aplicações ela é horrível, mas esse não é o principal campo de uso de Fortran
  • Isso já existe
    f2c existe há décadas
  • Exato, Fortran tem arrays nativos

• Tenho uma curiosidade pequena: pelo que sei, aarch64 e arm64 são a mesma coisa
  Estou entendendo errado?

  • São a mesma coisa, mas antigamente havia duas implementações LLVM concorrentes no lado do backend
    [1] https://www.phoronix.com/news/MTY5ODk
  • Link obrigatório: https://lkml.org/lkml/2012/7/15/133
  • Pelo que vejo em Python, aarch64 normalmente se refere a Linux, e arm64 normalmente se refere a macOS ARM
    Não conheço essa área o suficiente para entender por que os nomes são diferentes

• As mudanças no sistema de build do Python são realmente difíceis de acompanhar
  Também tenho curiosidade sobre os números de desempenho no Windows
  Mas talvez isso não seja importante em primeiro lugar
  Porque trabalhos sérios provavelmente vão rodar em máquinas Linux

  • Felizmente, agora parece que isso vai desacelerar
    A grande transição foi fazer todo mundo adotar a PEP 517, especialmente converter projetos Setuptools existentes
  • Em computação puramente de CPU, o Windows é tão rápido quanto o Linux
    Porque 99,9% do tempo é executado código do usuário, não o sistema operacional

[ahwjdekf]

Isso expõe de forma bem crua a nossa maldita dependência de linguagens compiladas para binário.

[kayws426]

Não resolveram no Python, mas não foi resolvido em outros ecossistemas, certo? Por isso devem fornecer binários pré-compilados.