I HATE PYTHON

I work with much more perl than python too, primarily on RHEL-style machines, and I don't run CPAN as root to install system wide files, I make RPMs. perl doesn't need a python-wheel style package format because the RPM integration with the perl/CPAN ecosystem is _excellent_ and by working directly with the system-wide package database including dependency management, you don't end up with two different ecosystems with a partial dependency graph fighting each other and breaking stuff, you just use the normal RPM mechanisms for detecting and resolving conflicts. From what I can tell the provided rpmmacros to pass Makefile.PL/Build.PL cli options are comprehensive and the provided scripts reliably collect the inbound and outbound runtime dependencies using simple regex matching for /^(use|require) (.+)/ and /^package "(.+)"/ with more specific builddeps templated in by `cpanspec`. It helps a lot that there is a standard naming convention mapping perl packages to RPM package and library dependency names, eg. perl lib `Foo::Bar` is rpm `perl-Foo-Bar` and provides `perl(Foo::Bar)`. python setuptools can create an RPM but it doesn't populate it with any of the data pip uses to resolve dependencies AFAICT and the RPM build macros/scripts don't seem to have any way to parse import statements to make that list either, or an agreed upon way to map between the two systems, if there are better tools which can give RPM the same info that pip/uv have I haven't found them yet.

I don't know enough about either ecosystems native packaging metadata formats to comprehensively compare and contrast them, I don't use them I just build my in-house perl using RPM and let the built-in rpmbuild scripts handle it, but I have found building python packages for system-wide install to be more complicated, and I never found a tool as good as `cpanspec` or even `rpmbuild-newspec -t perl` such that I've pretty much given up on it and just package an entire venv as an RPM that other scripts can depend on, rather than making individual RPMs for each part of the dependency tree (for NAPALM). I don't know if it's because python and pypi is operating at a much larger scale than cpan, so you see problems more often, or if the culture around backwards compatibility is very different, but with perl I've rarely or never had an app with an incompatible shared dependency with some other system-wide installed utility, or even libraries with breaking changes over the last 10-15 years, in fact some of the code in the darkest depths of the application appears to be written in a perl4 style and still works fine, but I've definitely had to be very careful with python because it's been far more common for some library in the dependency tree to bump a new major version that is incompatible and break the app at runtime, even when building a virtualenv I sometimes have to mask library versions until other parts catch up. I've also had the case where (re)installing a python app in a venv with a version that is more than 6mo old becomes difficult unless you froze a list of exactly what versions of the entire venv library set were available at the time the app was initially released, because it's basically guaranteed that something will have made an incompatible change in that time and the app won't run until you figure out which libraries you need to pin their versions back, which is very tedious if you run an app for longer than a 6-week sprint cadence. Maybe my old perl code is just depending on stagnant unmaintained libraries, stable because they are old and unchanging, but most of what we use is in RHEL or EPEL so must still be in active use by common shipping software, and we still haven't had nearly the problems as with python, but I can't make a definitive statement as to the true reasons why.

I wouldn't mind a deeper dive comparing CPAN to PyPI and NPM to see what problems each solved differently and why, CPAN is the OG maybe they learned something about how to do library management at scale, or maybe there are language support differences which means that the same solution in one ecosystem can't be translated to the other for technical reasons, or maybe there are longstanding policy differences that preclude some family of technical solutions to these problems. I dunno and can definitely stand to learn more about it.