La compilación de SciPy para Windows en Python 3.12 es considerada un pequeño milagro

• La compilación de SciPy para Windows en conda-forge estuvo disponible dos días después del lanzamiento de Python 3.12.0, por lo que la migración a Python 3.12 en la rama de SciPy avanzó con unos pocos días de retraso, en lugar de quedar estancada durante meses
• Como en Python 3.12 se eliminó distutils de la biblioteca estándar, SciPy decidió migrar a la herramienta de compilación Meson en lugar de numpy.distutils
• Se esperaba que Meson rechazara la combinación MSVC+gfortran que usaba conda-forge, y en Windows no había un compilador Fortran gratuito con ABI compatible que conda-forge pudiera usar
• conda-forge preveía que, si no lograba recompilar SciPy en Windows, la migración de al menos unas 1,000 dependencias de paquetes de SciPy se retrasaría en todas las plataformas, o que habría que excluir Windows de la migración de Python
• LLVM 17.0 fue la primera versión que eliminó la bandera -flang-experimental-exec en Flang, y se estimaba que Flang estaba en un nivel de madurez de “0.8”
• Tras agregar a Meson el manejo de llvm-flang, se logró compilar e instalar SciPy con éxito, y las pruebas terminaron con 54,987 passed, 2,866 skipped, 245 xfailed, 11 xpassed, 1 warning, con un 100% de aprobación {p:100}

[GN⁺]

Opiniones de Hacker News

• Fue un artículo realmente excelente, y ahora entiendo por qué fallaba pip install en Python 3.12, pero el futuro se ve más prometedor.
  Me gusta Python, pero también me ayudó a entender por qué el empaquetado de Python es un desastre manejable.
  La causa no es Python en sí, sino la falta de estandarización de las herramientas de compilación de C/C++/Fortran y lo enorme del ecosistema; hasta cierto punto, es una complejidad irreducible.
  Que esto funcione ya es casi un milagro.

  • Exacto, ahí está la razón de fondo por la que el empaquetado de Python es complejo.
    El éxito de Python se debe en gran parte a que pudo usar paquetes clave de lenguajes mixtos, y otros gestores de paquetes de lenguajes populares casi no lidian con este tipo de problemas.
    Por ejemplo, cargo de Rust es excelente, pero en su mayoría puede asumir el empaquetado de código solo en Rust; y aunque es un lenguaje compilado, el lenguaje “posee” el compilador, así que funciona una estrategia de distribución basada en compilación desde código fuente.
    No sé cómo maneja cargo Fortran de forma predeterminada, pero si los paquetes principales de cargo en Windows requirieran código Fortran, sospecho que sería difícil que funcionara bien.
    La mayor mejora del ecosistema de Python fue la estandarización de wheel, el formato de paquetes binarios, y solo entonces el ecosistema científico de Python empezó a prosperar de verdad en Windows.
    Aun así, la compatibilidad binaria es un enorme dolor de cabeza, sobre todo cuando se cruza entre lenguajes y CPU.
  • Decir que no tiene nada que ver con Python es demasiado: la razón por la que existen estos bindings FFI es que Python es demasiado lento.
  • Coincido con que “que esto funcione ya es un milagro”.
    La complejidad del ecosistema de software parece crecer exponencialmente, y me pregunto qué impide que termine en un colapso estilo Torre de Babel.
    Claro que no es un problema exclusivo del software, pero es un buen ejemplo.
  • Fue un artículo que realmente me abrió los ojos.
    A menudo veo gente que compara su gestor de paquetes favorito con el de Python y concluye que Python es pésimo, pero en realidad no es así.
    Lo que no termino de entender es por qué la gente de Python no usa bibliotecas matemáticas en C/C++ en lugar de Fortran.
  • El verdadero problema parece ser que Python tiende a atraer a personas sin formación en desarrollo de software.
    Es un desastre apilado encima de otro desastre.

• Cuando Linux era un caso marginal chirriante, operado por hackers coordinados de forma laxa y a veces con restricciones ideológicas poco prácticas, era fantástico que gente brillante dedicara enormes esfuerzos a darle soporte.
  Pero ahora que ese caso marginal chirriante se convirtió en un sistema propietario cuyas restricciones son básicamente hostiles y que está operado por ciberterratenientes, es más difícil ver con el mismo optimismo el trabajo de darle soporte.
  Por otro lado, es realmente admirable la profunda consideración de querer que todos puedan usar estas herramientas, y aplaudo ese trabajo.
  No digo en absoluto que cambien de rumbo; simplemente me deja pensando.
  Antes pensaba: “guau, qué bueno que este trabajo se esté haciendo”; ahora pienso más bien: “guau, qué habrían logrado esas personas brillantes si no tuvieran que estar dedicadas a esto”.

  • En realidad, no es algo que ellos tengan que hacer necesariamente.
    Como se ha dicho varias veces, los desarrolladores de SciPy son voluntarios.
    Gran parte de la historia explica por qué SciPy no tenía más opción que esperar a que alguien creara un compilador Fortran open source para Windows, y parece que el rescate vino principalmente de desarrolladores de NVIDIA.
  • Ni siquiera ese es el punto central.
    SciPy está pagando el precio de la decisión tonta y muy sesgada de los desarrolladores principales de Python de elegir MSVC en lugar de MinGW como toolchain para Python en Windows.
    Creo que la motivación provino del patrocinio de Microsoft.
    En la lista de desarrolladores principales hay bastantes empleados de Microsoft, a quienes Microsoft les paga por participar en esa lista; además, Microsoft también cubre los costos de los servidores de CI del proyecto CPython.
    Todo este problema podría haberse evitado si Python no hubiera usado herramientas propietarias en su toolchain.

• Que “Meson haya intentado rechazar la combinación MSVC+gfortran que se usaba en conda-forge” suena como un bug
  Creo que el propósito de una herramienta de compilación es ejecutar las órdenes que se le dan, no bloquearte con un “lo siento, Dave”

  • En realidad, quien se queja es el linker de MSVC
    El problema es que el runtime de C que usan MSVC y gfortran, en particular las propias bibliotecas de runtime de gfortran, que están escritas en C, no son compatibles a nivel de ABI
    La solución alternativa que usaba NumPy consistía en enlazar los objetos Fortran como DLL para agregar una capa indirecta mediante una import library y así calmar a MSVC
    Por eso hacía falta trabajo adicional para crear esas DLL
    Había que hacerlo ya fuera en el archivo de descripción de build o en Meson, pero el lado de SciPy no quería implementar esa capa indirecta en ninguno de los dos, y los desarrolladores de Meson tampoco tenían muchas ganas de ayudar activamente
    Claro que los desarrolladores de Meson sí ayudaron con cosas generales como el soporte de Fortran y Cython, pero no querían proporcionar un andamio peligroso
    En la práctica, esto era casi un hack y, por ejemplo, solo funcionaba porque el lado Fortran no usaba archivos abiertos desde el lado Python/C
    https://web.archive.org/web/20180711144501/https://pav.iki.f...
  • El artículo estaba bien escrito y era detallado, pero me sorprendió un poco la afirmación de que Meson “se usa ampliamente en proyectos C y C++”
    Personalmente he visto Bazel con más frecuencia que Meson
    Supongo que, al estar escrito en Python, Meson parecía una buena opción para SciPy, y al final salió bien, así que es algo para celebrar
    Aun así, pese a sus muchas rarezas, complejidades y problemas, creo que CMake sigue siendo prácticamente el estándar
  • Meson hace más que simplemente ejecutar las órdenes que le indica el usuario
    También puede sintetizar las órdenes para dar soporte a MSVC/gcc/clang
    Si le pides que sintetice órdenes para una combinación que no conoce, naturalmente no le queda otra que decir “lo siento, Dave”
  • Estoy de acuerdo
    Dejo claro que soy autor de un sistema de build competidor de Meson que se publicará pronto
    Dicho eso, [1] es una pequeña joya poco conocida, una rant que me hizo darme cuenta de lo que acabo de decir
    En resumen, un sistema de build debe ejecutar las órdenes que el usuario le dijo que ejecutara, y ya
    Porque a veces el programador de verdad sabe lo que está haciendo
    Me da vergüenza admitirlo, pero antes de leer ese comentario pensaba hacer que mi sistema de build fuera mágico
    Pero después de leerlo, entendí que justamente esa “magia” es la razón por la que la gente odia los sistemas de build
    [1]: https://ofekshilon.com/2016/08/30/cmake-rants/#comment-29273

• Pensé que para estas cosas todos usaban WSL2 y listo
  ¿Cuál es la razón para querer compilar una versión nativa de Windows?

  • Eso es como preguntarles a los desarrolladores de macOS por qué quieren builds nativos, si podrían trabajar en una máquina virtual con Linux
    Trabajar en una máquina virtual es incómodo y tiene menos integración
  • Muchos más investigadores de lo que uno cree usan Windows
    También los estudiantes
  • Sospecho que las grandes empresas donde es casi imposible recibir una máquina que no sea Windows son un grupo importante de usuarios
  • Que Microsoft y NVIDIA hayan resuelto el problema de los drivers CUDA en WSL2 fue una verdadera salvación
    Sobre todo cuando puedes usar Docker Desktop encima
    Es sacarle lo mejor posible a una situación que no es ideal

• El κατα de καταστροφή no significa “repentinidad”, sino más bien “hacia abajo” o “según”, con una fuerte implicación de torcerse en una mala dirección
  Lo contrario de κατα suele ser ανα, pero αναστροφή literalmente significa “giro hacia arriba” o inversión
  Así que ευστροφη, es decir, eustrophe, quizá sea un mejor neologismo para “buen giro”
  Aun así, si le ganas una discusión a JRR Tolkien sobre acuñación de palabras, eso sería ευκαταστροφη, es decir, buena fortuna
  En general me gusta que capture una gracia desbordante, algo que trae alegría y felicidad al mundo

  • El kata de katastrofi en realidad se acerca más a “against”, así que katastrofi corresponde a que las cosas “den la espalda”

• Tengo la impresión de que los mejores BLAS en general están hechos en C
  Cosas como MKL, BLIS y OpenBLAS
  Me pregunto hasta dónde se habría podido llegar solo con C y Python
  También me pregunto si, de empezar hoy, simplemente habrían elegido libflame
  Claro que SciPy tiene muchas otras funciones, como métodos iterativos y matrices dispersas, así que quizá sea difícil evitar Fortran
  Aun así, Fortran es un lenguaje excelente, y me alegra que la situación de herramientas en Windows al menos haya empezado a mejorar

  • En SciPy se discutió varias veces la eliminación de Fortran, pero no avanzó por las razones mencionadas
    SciPy en sí también contiene mucho código Fortran, y reescribirlo requeriría años-persona de trabajo
    Una vez que fue posible, se eliminaron algunas partes centrales que usaban Fortran
    Por ejemplo, las relacionadas con FFT
  • Honestamente, no esperaba encontrarme en 2023 con la frase “Fortran es un lenguaje excelente, y me alegra que la situación de herramientas en Windows haya empezado a mejorar”

• Excelente artículo
  Este año pasé mucho tiempo modernizando un proyecto C++ con CMake que tiene bindings de Python, y después de haberlo agregado con éxito a conda-forge como un feedstock nuevo, puedo decir con confianza:
  si me convierto en el nuevo emperador-dios, mi primera medida relacionada con TI será erradicar Windows de todo el universo para siempre

• Es una pregunta muy ingenua, pero ¿la semántica de Fortran es tan distinta que no se puede convertir primero a C y luego compilar con un compilador de C?
  Después, ¿no se podría mantener en C?
  No parece que haya mucha gente de Fortran manteniendo estas bibliotecas antiguas, pero aun así necesitan mantenimiento, ¿no?

  • Es posible si no te importa que sea más lento
    Fortran no tiene punteros y solo tiene arreglos; como los argumentos de las funciones no pueden tener alias, dejando de lado por un momento el horror de los bloques COMMON, es más fácil hacer optimizaciones agresivas y vectorización
    Las bibliotecas matemáticas estándar de Fortran simplemente funcionan bien y son rápidas
    En C/C++ también se puede escribir código con velocidad equivalente, sobre todo usando la palabra clave restrict de C
    Pero si conviertes código existente con un paso de f2c, en muchos casos el rendimiento empeora mucho
  • Fortran es un lenguaje de más alto nivel que C
    También hay suficientes desarrolladores de Fortran
    Es terrible para el desarrollo de aplicaciones, pero ese no es el campo principal de Fortran
  • Eso ya existe
    f2c existe desde hace décadas
  • Exacto, Fortran tiene arreglos nativos

• Tengo una pequeña duda: según entiendo, aarch64 y arm64 son lo mismo
  ¿Estoy equivocado?

  • Son lo mismo, pero antes había dos implementaciones de LLVM compitiendo en el backend
    [1] https://www.phoronix.com/news/MTY5ODk
  • Enlace obligatorio: https://lkml.org/lkml/2012/7/15/133
  • En Python, por lo que he visto, aarch64 normalmente se refiere a Linux, y arm64 normalmente se refiere a macOS ARM
    No conozco lo suficiente este campo como para entender por qué los nombres son distintos

• Es realmente difícil seguir los cambios en el sistema de build de Python
  También me dan curiosidad las cifras de rendimiento en Windows
  Aunque quizá no sean importantes en primera instancia
  Porque el trabajo serio probablemente se ejecute en máquinas Linux

  • Por suerte, parece que ahora se va a desacelerar
    La gran transición fue lograr que todos adoptaran PEP 517, especialmente migrar proyectos existentes de Setuptools
  • En cómputo puro de CPU, Windows es tan rápido como Linux
    Porque el 99.9% del tiempo se ejecuta código de usuario, no el sistema operativo

[ahwjdekf]

Vaya, aquí quedó brutalmente expuesta la miserable dependencia de los lenguajes compilados a binarios.

[kayws426]

¿No es que lo resolvieron para Python, pero no para otros ecosistemas? Por eso seguramente ofrecerán binarios precompilados.