10 ms·

Fedora Loves Python

151 points by type0 9y ago

sagarun 9y ago
/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.
saghm 9y ago
Most of this seems pretty standard for Linux distros; python2 and python3 installed by default, ability to install venv through `python -m`, other versions of Python and various packages available in the repositories. Is there something I'm missing here?
- lima 9y ago
  Installing different Python versions is not possible with many distros (you'd have to compile it from source/use something like pyenv): https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html https://developer.fedoraproject.org/tech/languages/python/mu...
  - saghm 9y ago
    Ah, I missed the "CPython in multiple 3.X and 2.X versions". Thanks for pointing that out to me!
  - fiddlerwoaroof 9y ago
    As far as I remember Debian has always been able to support multiple versions of python simultaneously although I think they've dropped packages for <~2.7 now
    - toyg 9y ago
      But: - iirc they can only go down one version (i.e. 3.4/3.5, no 3.4.1/3.4.2) - it's always been a real b@llache to install newer versions on Debian releases where it has not been officially packaged (e.g. 3.6 on jessie). With most packages, you can grab the source from Sid and rebuild it on Stable; with Python it's become basically impossible, the pile of dependencies below and above the package is unwieldy. And this despite tons of policies around packaging python apps, which was supposed to make it easier to run multiple versions. If Fedora really made things easier in this area, it's most welcome. However, when a marketing page starts with "you can now do this standard thing that actually most people have been doing for years already" (-m venv), I'm somewhat skeptical.
  - 9y ago
Temasik 9y ago
Why should I use fedora on my laptop over Ubuntu? Even on servers? Does fedora increases my productivity?
- pmoriarty 9y ago
  In my experience most Fedora users are from corporations that want a support contract from RedHat. That's really the only reason. I've yet to meet anyone who uses Fedora willingly otherwise.
  - tavert 9y ago
    Fedora (and other rpm-based distros, OpenSUSE in particular) are easier to build/modify packages for than deb-based distros and have easier to use build services with better automation, IMO.
  - emidln 9y ago
    Fedora has "just-worked" for awhile and I don't have a particularly good reason to move to Ubuntu. It's nice that Fedora doesn't patch upstream much, and I learned how to build custom RPMs about 20 years ago.
  - no_wizard 9y ago
    To counter that I have found Fedora's bleeding edge approach quite usable on my home machine for doing my personal programming. It was also.the first Linux distribution with true (and great imo) High DPI support that to me was very good. Almost as good as macOS in implementation.
  - dizzystar 9y ago
    I use it willingly. I don't work in any place remotely related to RH. Don't knock it until you try it.
  - johnny22 9y ago
    If you want support contracts you don't use Fedora, you use RHEL
merraksh 9y ago
Off topic, but it seems to me that the "Python 3 by default" logo has cobras, not pythons.
- Qwertious 9y ago
  Maybe it's a python pretending to be a cobra?
  - nolepointer 9y ago
    If a man can identify as a woman, why can't a cobra identify as a python? Gosh!
    - sctb 9y ago
      Trolling like this on Hacker News will get your account banned. Please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
nippples 9y ago
tips fedora furiously
- TeMPOraL 9y ago
  Colorless green pythons tip fedoras furiously.
type0 9y ago
Relevant to their "Fedora Python initiative": https://labs.fedoraproject.org/en/python-classroom/ https://labs.fedoraproject.org/en/python-classroom/
drcwu 9y ago
Fedora can not be python3 only, if you want to have offline documents, e.g.: there is a `python2-matplotlib-doc`, which depends on `python2-matplotlib`, however no `python3-matplotlib-doc` or a generic `python-matplotlib-doc` exists. On the other hand, ubuntu /debian packages are well organized at this point.
chroem- 9y ago
Another fine example of heartwashing. It just doesn't feel genuine when all these companies start plastering hearts all over everything.
hobarrera 9y ago
> Python 3 by default Two lines below: > However, /usr/bin/python remains Python 2, [...] Not sure what they call "default". They seem to quote some PEP that only specified that this was okay during a transition period. I think we're WAY past that. If not, then the first statement is plainly wrong.
- proaralyst 9y ago
  The PEP does say `should' and that a future PEP will require the python command to be Python 3.x. Given a default Fedora install does not have the python command but does have python3, I'd say it's 3.x by default.
- iamthad 9y ago
  I read PEP 394 (https://www.python.org/dev/peps/pep-0394 https://www.python.org/dev/peps/pep-0394) differently. It states > The more general python command should be installed whenever any version of Python 2 is installed and should invoke the same version of Python as the python2 command Rather than permitting python to refer to python2 during a transition period, that is the recommendation. They later state > It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.
- kingosticks 9y ago
  I believe this means that python3 is installed by default and python2 is not. /usr/bin/python is not installed unless python2 is installed. PEP394 actually states the "recommendation will be periodically reviewed over the next few years, and updated when the core development team judges it appropriate.". You might think we are way past that, but it seems they don't.

151 points by type0 9y ago

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

saghm 9y ago

Most of this seems pretty standard for Linux distros; python2 and python3 installed by default, ability to install venv through `python -m`, other versions of Python and various packages available in the repositories. Is there something I'm missing here?

lima 9y ago
Installing different Python versions is not possible with many distros (you'd have to compile it from source/use something like pyenv): https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html https://developer.fedoraproject.org/tech/languages/python/mu...
- saghm 9y ago
  Ah, I missed the "CPython in multiple 3.X and 2.X versions". Thanks for pointing that out to me!
- fiddlerwoaroof 9y ago
  As far as I remember Debian has always been able to support multiple versions of python simultaneously although I think they've dropped packages for <~2.7 now
  - toyg 9y ago
    But: - iirc they can only go down one version (i.e. 3.4/3.5, no 3.4.1/3.4.2) - it's always been a real b@llache to install newer versions on Debian releases where it has not been officially packaged (e.g. 3.6 on jessie). With most packages, you can grab the source from Sid and rebuild it on Stable; with Python it's become basically impossible, the pile of dependencies below and above the package is unwieldy. And this despite tons of policies around packaging python apps, which was supposed to make it easier to run multiple versions. If Fedora really made things easier in this area, it's most welcome. However, when a marketing page starts with "you can now do this standard thing that actually most people have been doing for years already" (-m venv), I'm somewhat skeptical.
- 9y ago

Temasik 9y ago

Why should I use fedora on my laptop over Ubuntu? Even on servers? Does fedora increases my productivity?

pmoriarty 9y ago
In my experience most Fedora users are from corporations that want a support contract from RedHat. That's really the only reason. I've yet to meet anyone who uses Fedora willingly otherwise.
- tavert 9y ago
  Fedora (and other rpm-based distros, OpenSUSE in particular) are easier to build/modify packages for than deb-based distros and have easier to use build services with better automation, IMO.
- emidln 9y ago
  Fedora has "just-worked" for awhile and I don't have a particularly good reason to move to Ubuntu. It's nice that Fedora doesn't patch upstream much, and I learned how to build custom RPMs about 20 years ago.
- no_wizard 9y ago
  To counter that I have found Fedora's bleeding edge approach quite usable on my home machine for doing my personal programming. It was also.the first Linux distribution with true (and great imo) High DPI support that to me was very good. Almost as good as macOS in implementation.
- dizzystar 9y ago
  I use it willingly. I don't work in any place remotely related to RH. Don't knock it until you try it.
- johnny22 9y ago
  If you want support contracts you don't use Fedora, you use RHEL

merraksh 9y ago

Off topic, but it seems to me that the "Python 3 by default" logo has cobras, not pythons.

Qwertious 9y ago
Maybe it's a python pretending to be a cobra?
- nolepointer 9y ago
  If a man can identify as a woman, why can't a cobra identify as a python? Gosh!
  - sctb 9y ago
    Trolling like this on Hacker News will get your account banned. Please don't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

nippples 9y ago

tips fedora furiously

TeMPOraL 9y ago
Colorless green pythons tip fedoras furiously.

type0 9y ago

Relevant to their "Fedora Python initiative": https://labs.fedoraproject.org/en/python-classroom/ https://labs.fedoraproject.org/en/python-classroom/

drcwu 9y ago

Fedora can not be python3 only, if you want to have offline documents, e.g.: there is a `python2-matplotlib-doc`, which depends on `python2-matplotlib`, however no `python3-matplotlib-doc` or a generic `python-matplotlib-doc` exists. On the other hand, ubuntu /debian packages are well organized at this point.

chroem- 9y ago

Another fine example of heartwashing. It just doesn't feel genuine when all these companies start plastering hearts all over everything.

hobarrera 9y ago

> Python 3 by default Two lines below: > However, /usr/bin/python remains Python 2, [...] Not sure what they call "default". They seem to quote some PEP that only specified that this was okay during a transition period. I think we're WAY past that. If not, then the first statement is plainly wrong.

proaralyst 9y ago
The PEP does say `should' and that a future PEP will require the python command to be Python 3.x. Given a default Fedora install does not have the python command but does have python3, I'd say it's 3.x by default.
iamthad 9y ago
I read PEP 394 (https://www.python.org/dev/peps/pep-0394 https://www.python.org/dev/peps/pep-0394) differently. It states > The more general python command should be installed whenever any version of Python 2 is installed and should invoke the same version of Python as the python2 command Rather than permitting python to refer to python2 during a transition period, that is the recommendation. They later state > It is anticipated that there will eventually come a time where the third party ecosystem surrounding Python 3 is sufficiently mature for this recommendation to be updated to suggest that the python symlink refer to python3 rather than python2.
kingosticks 9y ago
I believe this means that python3 is installed by default and python2 is not. /usr/bin/python is not installed unless python2 is installed. PEP394 actually states the "recommendation will be periodically reviewed over the next few years, and updated when the core development team judges it appropriate.". You might think we are way past that, but it seems they don't.