Christmas is nearly here and that means it's time to join us for our December meet, hosted by #Nitor!

https://www.meetup.com/helpy-meetups/events/304793959/

Creating Python modules and libraries using #Rust, by Akseli Lukkarila

#Meson: a Build system in and for Python, by Jussi Pakkanen

#JAX: A Python ecosystem for machine learning and numerical computation, by Nazaal Ibrahim @nazaal

And did someone say something about a quiz?

I suppose I could use my experience to give some #PEP517 build system recommendations.

For pure #Python packages:

1. #flit_core (https://pypi.org/project/flit-core/) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).

2. #hatchling (https://pypi.org/project/hatchling/) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in #Gentoo).

For Python packages with C extensions: #meson-python (https://pypi.org/project/meson-python/) — which combines the power and correctness of meson build system with good very Python integration.

For Python packages with Rust extensions: #maturin (https://pypi.org/project/maturin/) — which is simply a good builder for precisely that kind of packages.

Now, I strongly discourage:

A. #setuptools — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.

B. #poetry-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).

C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.

For two weeks now, the latest #setuptools release has a major race condition bug. Sure, it's not the first race condition in C extension builds. However, this one has a known cause, with clear explanation why the change was wrong, and causes a regression for many packages that weren't affected before.

And perhaps the most absurd part is that many people are using setuptools only for their C extension building support, and that one feature that's keeping the project still relevant today keeps being broken in so many ways. At this point, I'm going to suggest using #meson and its #PEP517 backend, meson-python.

https://github.com/pypa/setuptools/issues/4653

Does anyone have an example they can point me to for bundling a CSS stylesheet with a GTK library that *isn’t* a full theme? Specifically this would be for styling a custom widget. I know how to package a stylesheet with an application, but I can’t seem to figure out how to make it work when developing a library.

I created a small blog post. How to combine #meson and #PDM to build #Python extensions.
It's a good alternative to good old setup.py.

https://gaphor.org/2024/07/28/meson-python-pdm/

# Packaging #MesonPython

Mumbles something about some kernel projects suddenly becoming not reproducible, using broken #makefile based setups, also offering #meson, but that being broken (and leading to differing output!!), too.

I'm quite tired of these types of untested projects, without any CI. Maintainers pointing contributors to their 10 step "easy to follow" mail based workflow isn't helping either I guess

I have less and less energy packaging stuff like that.

My expectation: #Rust will replace most other low level languages for relatively low level use cases. For example platform libraries, kernels, OS components, like services etc.
But I also think that a lot of these projects (especially platform libraries) care about that they won't just be able to be used by other Rust code.
Also my expectation: For a lot of these projects, #Meson will replace #cargo, because it just supports more features, and makes integration into an existing system easier.

#GCC14 promoted some warnings to errors. This can break #autoconf, #CMake, #Meson or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.

Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:

#!/bin/sh
exec /usr/bin/gcc -fpermissive "$@"

Hot take after an afternoon un-fsck-ing a #CMake project: `*Config.cmake` files are so much harder to debug than `*.pc` #PKGConfig files, so not only are you trying to make sense of a Turing complete project definition but all the transitive dependencies that happen to use CMake too

I'm increasingly a #meson fan.

I suppose everyone and their grandmother is now using the xz/sshd exploit to further their own agenda, so I am going to take this opportunity to further mine as well.

1. #Autotools are a bad build system. If configure scripts are completely unreadable, there should be no surprise that people won't notice obfuscated malicious code in there, provided that everything else is obfuscated by design.

2. Static linking and vendoring is bad. Do you know why the prompt #security response was possible? Because we just had to revert to older liblzma. We didn't have to check, patch and re-release hundreds of projects. It wouldn't be this easy with #RustLang and cargo.

3. You can blame #OpenSource for being underfunded and open to abuse in core system packages. However, no IT project can be resilient to a sufficiently powerful bad actor, and that it happened to xz is just an incident. Corporate projects aren't resilient to it, neither is proprietary, closed-source software.

So, embrace #Meson, embrace dynamic linking, embrace distribution packaging and donate to open source developers.

Zdaje się, że już wszyscy i ich babcie używają exploitu w xz/sshd, by szerzyć swoją agendę, więc i ja nie będę gorszy.

1. #Autotools to zły system budowania. Skryptu configure są absolutnie nieczytelne, więc nikogo nie powinno dziwić, że nikt nie zauważył złośliwego kodu — wszak nie różni się niczym od całej reszty tego bełkotu.

2. Statyczna konsolidacja i włączanie zależności są złe. Wiecie, dlaczego tak szybko udało się rozwiązać problem z liblzma? Bo wystarczyło cofnąć systemową bibliotekę do wcześniejszej wersji. Nie trzeba było przeszukiwać, łatać i wydawać na nowo setek projektów. Z #RustLang i Cargo nie byłoby tak łatwo.

3. Możecie winić #OpenSource za bycie niedofinansowanym i tym samym otwartym na tego rodzaju nadużycia w kluczowych projektach. Ale tak naprawdę żaden projekt IT nie jest w stanie być odpornym na poczynania złoczyńców o dostatecznych zasobach, a że przydarzyło się to xz, to tylko przypadek. Korpoprojekty też nie są bezpieczne, a tym bardziej własnościowe oprogramowanie z zamkniętym kodem źródłowym.

Tak więc: doceńcie Mesona, doceńcie dynamiczne ładowanie bibliotek, doceńcie dostawę oprogramowania przez dystrybucje, i rzućcie grosza wie… chciałem powiedzieć, devom open source.

Man, #meson is pretty good. Fast, separate build directory, OK config language…

Over the last months the Rust/cargo support in meson improved a lot.

It's now ready to build and install a GTK4 Rust application with around 70 dependencies without having to write almost any custom build glue for the dependencies.

https://github.com/sdroege/mandelbrot#meson-build

The application in question is just a small experiment of mine for rayon and GTK4 input handling / rendering. The more or less same should work for other GTK4 applications at this point.

All this still depends on two unmerged meson PRs, but it's a huge step forward from the situation just a few months ago.

Thanks to the hard work of @xclaesse and dcbaker!

I hope in the future this will allow GNOME applications written in Rust to have a less strange and fragile build setup than what they have right now with mixing cargo and meson.

Here's something that the upcoming @pidgin 3 can do that Pidgin 2 could never hope to achieve:
building itself and all¹ of its dependencies (such as @GTK and @gstreamer) from source with MSVC, using the same build system as everywhere else, thanks to #Meson.

You can even run it without installing, using Meson's excellent devenv (though some icons are not found).

https://youtu.be/O3-dR8zXOsc

"If I were to summarize what I learned in a single sentence, it would be this: we talk about programming like it is about writing code, but the code ends up being less important than the architecture, and the architecture ends up being less important than social issues."

-- Evan Martin, designer of the Ninja build system
https://neugierig.org/software/blog/2020/05/ninja.html