[sagarun]

/rant If fedora really loves python, they should first start showing their love by publishing all their distribution related libraries to pypi. blivet, selinux, none of these are available in pypi. Why do they expect everyone to use rpms?

[mrmondo]

Personally I can't stand when I have to get language specific packages from one of their many package managers, that's the point of having a distribution - so it can be distributed.

[saghm]

Right, but the issue GP has with this is that the Python libraries that Fedora develops aren't available on other distros, and that submitting them to a Python repository would be an easy way to achieve that availablility

[rekado]

These libraries are in fact available for other distributions. The SELinux Python things, for example, are hosted on Github.

[ubernostrum]

Much depends on point of view.

For the operating system, sure, use the OS packages.

For writing and deploying an application in a language? Never use the OS packages; manage it using the language's tools. My Python applications deploy into a virtualenv and install their dependencies using pip.

[sdiepend]

Why not use RPM for example to deploy python code?

[concede_pluto]

This. Make as big a mess as you like on your own box (your sysadmin can pave it when you're hopelessly confused), but everything in prod has to be registered with the one and only package manager because otherwise nobody will know where it's deployed or what its dependencies are or whether they're up to date. cpan/pip/gem/cargo/go get/hackage/melpa are not sysadmin problems.

[ubernostrum]

everything in prod has to be registered with the one and only package manager

No. Never. Not for any reason, ever. Never.

The language's packaging ecosystem and toolchain are:

* Tailored to the language, not the operating system, which means they're reproducible on multiple operating systems. This is important, since your developers are not running RHEL server as their laptop OS, and as a result they'll be using the language toolchain regardless of what your "sysadmin" does to the production environment.

* More likely to be up-to-date and/or update-able than distro-format packages. Unless you want to be running two years ago's version of your libraries (or older), the only way you'll get distro-format packages is to build them yourself... which requires you to go grab them from the language's package system, since that's where they get published, and maintain your own pipeline to re-package them into the distro format. Now you've injected additional moving parts into your systems where none were needed.

Distro packages are only for the base operating system and things like your HTTP daemon. For application code and dependencies, the distro packages should only be involved insofar as they bootstrap you to the point of being able to use the language's toolchain. Insisting on distro-format packages for the whole thing is the path to overcomplex builds/deploys and difficult-to-update codebases.

because otherwise nobody will know where it's deployed or what its dependencies are or whether they're up to date

I can, at a glance, look at any application in production where I work and see what its full dependency tree is and whether those dependencies are up-to-date (and if not, whether they're just outdated or also subject to security advisories). Using things built on the language toolchain. Really. And this is not new cutting-edge technology here, we've had that capability for a good number of years now!

Even better, I can match up that information to what upstream actually publishes: if they say the bug I care about is fixed in version 3.1.4, I can upgrade to version 3.1.4. With distro packages, who knows? The distro might have backported the bugfix into 2.7.1 and bumped the patch number, for all I know. The more places I have to look to find out what's up-to-date and what versions I should use, the more opportunities I have to mess up. Reduce the number of places to look until it's one and only one: the upstream release notes, using upstream's versioning and upstream's packages.

Distro packages for the base OS, language packages for application and its dependencies. Deviate from this at your peril.

[concede_pluto]

If we ship code that runs on SuSE 234 and RHEL 345, that's what we test on. If we run on our own hardware or AWS, we pick a distro and test on that. I don't care whether it builds or runs on a laptop; I don't write twitch games and interesting problems don't fit on a single machine anymore.

It's been a decade since I worked at such a tiny nascent company that all the software was written in just one language. Language packages almost never express dependencies on either system packages or other languages' packages, making "bootstrap to the point of being able to use all of the languages' toolchains" a manual process that lacks any guardrails. Nothing ensures you have a httpd version that's compatible with all your apps, because each of them just sort of assume httpd is out there somewhere without saying anything about it. Staying on the right versions of shared libraries is even more error-prone since the system package manager literally doesn't know you're using them.

If you want to read upstream security advisories and use such bleeding-edge software that even the bleeding-edge distros don't trust it yet, you're basically rolling your own distro that only exists on one machine in the world (because some languages' package managers aren't idempotent and symmetric) and is supported by nobody besides you. I'd rather delegate that to the people who specialize, because the best case is that I don't fuck it up too badly, I'll never add value that way.

[lmm]

OS package managers are so much worse than language package managers though - no ability to install packages per-user or in a "local" environment, difficult to have multiple versions of the same package installed (a huge problem if you have a "diamond" where you depend transitively on two different version of the same library), no IDE integration, limited introspectibility, inconsistent testing standards...

[concede_pluto]

If the answer to "are my dependencies installed and up to date?" is "well, yes and no, we can't tell which copy I'm actually using", I am not ready to go to prod.

> "diamond" where you depend transitively on two different version of the same library

That's a trainwreck waiting to happen. It's not even worth testing, much less deploying.

[lmm]

> If the answer to "are my dependencies installed and up to date?" is "well, yes and no, we can't tell which copy I'm actually using", I am not ready to go to prod.

Language package managers are a lot better at that than OS package managers, IME. Much better for all deploys of version x to use the same version than for all deploys to host y to use the same version.

[kevin_thibedeau]

In the case of Debian it's an asset since you can run on stable without being stuck with horribly outdated, hard to upgrade Python packages.

[falcolas]

The case could be made for choosing to stick with well tested and battle hardened libraries instead of bleeding edge, backward-compatibility breaking releases.

Virtual environments tend to solve the problem in either case.

[sigzero]

Is that basically how Linux distros work? Debian has .deb and Redhat has .rpm etc.?

[saghm]

I think GP is saying that they want to be able to install the Fedora/Redhat libraries (like SELinux) on other distros as well

[dfox]

At least blivet is normal distutils package that can be installed by pip by providing URL to repository and/or source archive.