7 ms·

/rant If fedora really loves python, they should first start showing their love by publishing all their distribution related libraries to pypi. blivet, selinux,

/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?

sigzero 9y ago
Is that basically how Linux distros work? Debian has .deb and Redhat has .rpm etc.?
- saghm 9y ago
  I think GP is saying that they want to be able to install the Fedora/Redhat libraries (like SELinux) on other distros as well
mrmondo 9y ago
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 9y ago
  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 9y ago
    These libraries are in fact available for other distributions. The SELinux Python things, for example, are hosted on Github.
- ubernostrum 9y ago
  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 9y ago
    Why not use RPM for example to deploy python code?
    - concede_pluto 9y ago
      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 9y ago
        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.
- kevin_thibedeau 9y ago
  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 9y ago
    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.
- lmm 9y ago
  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 9y ago
    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 9y ago
      > 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.
dfox 9y ago
At least blivet is normal distutils package that can be installed by pip by providing URL to repository and/or source archive.

sigzero 9y ago

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

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

mrmondo 9y ago

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 9y ago
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 9y ago
  These libraries are in fact available for other distributions. The SELinux Python things, for example, are hosted on Github.
ubernostrum 9y ago
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 9y ago
  Why not use RPM for example to deploy python code?
  - concede_pluto 9y ago
    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 9y ago
      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.
kevin_thibedeau 9y ago
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 9y ago
  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.
lmm 9y ago
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 9y ago
  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 9y ago
    > 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.

dfox 9y ago

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