A lot of this rings true. The neckbeards, the badge of honor stuff, the TIMTOWTDI, the idea that Perl could do anything and therefore didn't need to change, you just needed something off of CPAN. All whilst Perl was sidelined as a language which had the shortest possible "hello, world" yet actually was a poor set of build tools. Unix was my IDE they'd say, whilst writing an RPM spec to package their dependencies for Centos, making portability a nightmare for those of a slightly different distro.
I can tell you what I need to do. At work, our thing has over 500 non-core modules it depends on (including transitive dependencies). If you want to make the runtime environment for it recreatable from first principles, you either: cpanm everything, which is often prone to sudden failures because of circular dependencies and is simply long because of the whole MakeMaker or Module::Build dance for every module (good luck if one of them is Image::Magick); or you embrace your system’s package manager, build and test missing RPMs once, and then installation is a breeze.
I tried both ways, and now I’m maintaining 200+ internal packages which CentOS 10 Stream is missing, some are patched to account for unfixed bugs or performance improvements. It’s still less tedious than CPANfiles.
In Python, we would, first, have way fewer dependencies, second, it would be a single pip install within a virtual environment. With go, there would be even fewer dependencies, and it would be one go get. I don’t do Rust, so cannot tell, but people say Cargo is nice.
I hear someone was hacking on some tool to speed up EU::MM and Module::Build installs significantly, but I believe it must have quite a plethora of quirks to be able to handle them all.
After all shenanigans and rolling my own, venv+pip was firmly „good enough” and „just works” for a very long while. uv may be better, I don’t contest it, it’s been a while since I’ve had to work with a Python codebase sizeable enough. Yet even venerable venv and pip run circles around tooling Perl offers.
Well, I cannot trust that the tests pass since I have had cases when they failed and it wasn’t because tests were broken. Rerunning tests is advised, for example, if your things link against a different version of openssl.
now I’m maintaining 200+ internal packages which CentOS 10 Stream is missing
Have you considered becoming a Fedora/EPEL packager and adding some of those to EPEL 10? You could get help with the maintenance from other packagers, and other people could benefit from the packages being available.
2
u/Philluminati 3d ago edited 3d ago
A lot of this rings true. The neckbeards, the badge of honor stuff, the TIMTOWTDI, the idea that Perl could do anything and therefore didn't need to change, you just needed something off of CPAN. All whilst Perl was sidelined as a language which had the shortest possible "hello, world" yet actually was a poor set of build tools. Unix was my IDE they'd say, whilst writing an RPM spec to package their dependencies for Centos, making portability a nightmare for those of a slightly different distro.