7 ms·

> I'd like details on the "installing libraries" comment. for python, most distros come with a package, otherwise compilation is rarer. Installing python modul

> I'd like details on the "installing libraries" comment. for python, most distros come with a package, otherwise compilation is rarer. Installing python modules from a system's package manager is not something people should do. It causes more issues than it solves.

majewsky 10y ago
Can you go into more detail? So far, for my basic scripting needs, system packages have always been fine.
- ubernostrum 10y ago
  First of all, distro packages essentially always lag behind the released upstream versions, so you have to begin with figuring out which version the distro packaged, and find documentation for that, include that version in all your questions to the mailing list for the library, and hope that you're not on a version so old that it's no longer supported upstream. Then there's the way distros like to make changes for "consistency" with the rest of their system. Command-line entry points get renamed or have options and behavior changed to reflect the distro's standards, but now the thing you're running isn't the thing upstream wrote or documented, so you're even more on your own if you hit trouble. Also, it's not unheard-of for distros to take something that's a single packaged entity upstream, and split it into multiple distro packages, possibly without making it entirely clear that to get full functionality you'll have to install multiple distro packages. And, again, this is specific to the distro and their choices, so of course upstream won't document it and may be just as baffled as you are when you ask why something that's important to you doesn't seem to be in the package you got. Finally, the Python ecosystem is built around the Python packaging and distribution toolchains. You're going to find plenty of expertise in things like using pip and virtual environments to develop and deploy Python, but all that goes out the window when you switch to using the distro package manager and packages. So you're giving up a lot of tooling built by and for Python engineers, for something which had to be a one-size-fits-all solution for the operating system it's bound to. So while you can do all right with system packages and tooling for quite a few use cases, the dangers aren't that far away and are ready to hurt you, badly, as soon as you stray just a little bit outside of what the distro optimized for, or need help with a package beyond what the distro and its packagers are able to provide.
  - majewsky 10y ago
    Hm okay, at least the first two things don't apply for me since Arch Linux updates usually within a few days, and likes to stay as close to upstream as possible.
- xj9 10y ago
  This applies mostly to applications, which often rely on specific library versions which may or may not be available on the target system.
- fnord123 10y ago
  I'll go out on a limb and give general advice. I'm happy to receive constructive criticism in case I'm wrong. The OS package manager is for system programs to administer the system. So if you have an admin tool it should run with `#!/usr/local/bin/python -E` (or wherever Python is installed). Note: It uses a hard coded path for `python` and it uses `-E` to ignore PYTHONPATH. This is so no matter how trashed your environment becomes, you can still run administration tools written in Python. The OS package manager should be installing programs that adhere to this policy. Your applications that you develop should be using `#!/usr/bin/env python -S` This uses `env` to determine the correct Python version that your script should use. It also uses `-S` so it doesn't accidentally pull in an OS installed library which may have conflicts with libraries that you want to use.
lqdc13 10y ago
People should do it in some cases because sometimes Python libs have to link against some other non-Python libs that are not part of the pip package. Then if you just install the dependencies, sometimes the newer version in the PyPI requires a newer version of the dependencies, so you are stuck installing those things from source and building packages.
Steeeve 10y ago
This is not true with Gentoo. With debian, ubuntu, or rhel - the vendor provided packages are frequently out of date.

majewsky 10y ago

Can you go into more detail? So far, for my basic scripting needs, system packages have always been fine.

ubernostrum 10y ago
First of all, distro packages essentially always lag behind the released upstream versions, so you have to begin with figuring out which version the distro packaged, and find documentation for that, include that version in all your questions to the mailing list for the library, and hope that you're not on a version so old that it's no longer supported upstream. Then there's the way distros like to make changes for "consistency" with the rest of their system. Command-line entry points get renamed or have options and behavior changed to reflect the distro's standards, but now the thing you're running isn't the thing upstream wrote or documented, so you're even more on your own if you hit trouble. Also, it's not unheard-of for distros to take something that's a single packaged entity upstream, and split it into multiple distro packages, possibly without making it entirely clear that to get full functionality you'll have to install multiple distro packages. And, again, this is specific to the distro and their choices, so of course upstream won't document it and may be just as baffled as you are when you ask why something that's important to you doesn't seem to be in the package you got. Finally, the Python ecosystem is built around the Python packaging and distribution toolchains. You're going to find plenty of expertise in things like using pip and virtual environments to develop and deploy Python, but all that goes out the window when you switch to using the distro package manager and packages. So you're giving up a lot of tooling built by and for Python engineers, for something which had to be a one-size-fits-all solution for the operating system it's bound to. So while you can do all right with system packages and tooling for quite a few use cases, the dangers aren't that far away and are ready to hurt you, badly, as soon as you stray just a little bit outside of what the distro optimized for, or need help with a package beyond what the distro and its packagers are able to provide.
- majewsky 10y ago
  Hm okay, at least the first two things don't apply for me since Arch Linux updates usually within a few days, and likes to stay as close to upstream as possible.
xj9 10y ago
This applies mostly to applications, which often rely on specific library versions which may or may not be available on the target system.
fnord123 10y ago
I'll go out on a limb and give general advice. I'm happy to receive constructive criticism in case I'm wrong. The OS package manager is for system programs to administer the system. So if you have an admin tool it should run with `#!/usr/local/bin/python -E` (or wherever Python is installed). Note: It uses a hard coded path for `python` and it uses `-E` to ignore PYTHONPATH. This is so no matter how trashed your environment becomes, you can still run administration tools written in Python. The OS package manager should be installing programs that adhere to this policy. Your applications that you develop should be using `#!/usr/bin/env python -S` This uses `env` to determine the correct Python version that your script should use. It also uses `-S` so it doesn't accidentally pull in an OS installed library which may have conflicts with libraries that you want to use.

lqdc13 10y ago

People should do it in some cases because sometimes Python libs have to link against some other non-Python libs that are not part of the pip package. Then if you just install the dependencies, sometimes the newer version in the PyPI requires a newer version of the dependencies, so you are stuck installing those things from source and building packages.

Steeeve 10y ago

This is not true with Gentoo. With debian, ubuntu, or rhel - the vendor provided packages are frequently out of date.