5 ms·

Yes 1000x What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when

by gjvc 3y ago

Yes 1000x What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path. I still haven't figured out how to beat this dragon. All suggestions welcome!

eyegor 3y ago
I usually make a venv in ~/.venv and then activate it at the top of any python project. Makes it much easier to deal with dependencies when they're all in one place.
- synergy20 3y ago
  second this and it's what I do on all Linux distros, just run it inside .venv as the site-installation. if you need extra dependencies that pip can not do well in the .venv case, Conda can help with its own and similar site-based installation. I don't know how it is different in the python installation case between ubuntu and debian, they seem the same to me.
- gjvc 3y ago
  i am a big fan of .venv/ -- except when it takes ~45 mins to compile the native extension code in question -- then I want it all pre-packaged.
  - dgroshev 3y ago
    At this stage [0], uncompiled native extensions are not yet a bug, but a definite oversight of the maintainer. They should come as precompiled wheels [0]: https://pythonwheels.com https://pythonwheels.com
    - doliveira 3y ago
      Honestly I don't think I've ever used a precompiled package in Python. Every single C stuff seems to take ages and requires all that fun stuff of installing native system dependencies. Edit: skimming through this page, precompiling seems like an afterthought, and the linked packages don't even seem to mention how to integrate third-party libraries. So I guess I can see why it doesn't deliver on its promises.
      - toyg 3y ago
        Probably a function of the specific set of packages you use, or the pip options you specify. Pretty much all the major C packages come as wheels these days.
        doliveira 3y ago
        They all come as wheels, they just aren't precompiled.
        toyg 3y ago
        I honestly can't remember the last time I had to compile anything, and I am on Windows.
        orf 3y ago
        Can you link one that comes as a wheel but is really a source distribution?
      - dgroshev 3y ago
        You can try pip install pillow for a good example of how it works. I suspect there's a strong survivorship bias here, as you'd only notice the packages that don't ship with wheels.
        doliveira 3y ago
        Yeah, perhaps. One I remember from last year is the cryptography and numpy package, for instance. Now they do seem to ship with binary wheels, at least for my current Python and Linux version. Kerberos and Hadoop stuff obviously still doesn't, though. I guess the joke's on me for being stuck in this stack...
  - j0057 3y ago
    It's a good idea to be caching sdists and wheels — for resilience against PyPI downtime, for left-pad scenarios, and even just good netiquette — and for packages that don't have a wheel for your environment, you can fairly easily build that wheel yourself and stick it into the cache.
silon42 3y ago
dist packages are a must for software written in Python that is part of the distribution itself.
- smashed 3y ago
  You're not really answering why they are important? Is it because .deb packages will install inside dist-packages and when you run pip install as root without a virtual env, it installs inside site-packages? I don't really see how this helps though? Sure you won't get paths to clash between the two but you still have duplicate packages which is probably not what you want..
  - rlpb 3y ago
    Debian ships packages with a coherent dependency structure that crosses language boundaries. You don't need to care what language something is written in to be able to "apt install" it. The expectation is that if it "apt installed" then it should Just Work because all the required dependencies were also pulled in from Debian at the same time. Debian also tries to ship just one version of everything in a single distribution release to reduce the burden on its maintainers. This is fundamentally at odds with pip. If you've pip installed something, then that'll likely be the latest version of that package, and in the general case won't be the version of the same thing that shipped in the Debian release. If there exist debs that depend on that package and they are shared between pip and debs, now the deb could be using a different version of the dependency than the deb metadata says is acceptable, leading to breakage. Another way of putting this: it shouldn't be possible for you to pip upgrade a dependency that a deb shipped by Debian itself relies upon. Because then you'd creating a Frankenstein system where Debian cannot rely on its own dependencies providing what it expects. This is fixed by having two places where things are installed. One for what the system package manager ships, and one for your own use with pip and whatever you want to do. In this sense, having duplicate packages is actually exactly what you want.
    - sanderjd 3y ago
      Yep, I screw things up all the time with packages in homebrew that are written in python, when I forget to switch into a virtual env before doing stuff with pip. Debian's solution seems very sensible. And it is the same solution as homebrew, I suppose, as long as you don't interact with any of the homebrew-installed packages via pip. But I find it quite easy to accidentally do that.
kevin_thibedeau 3y ago
Dist packages is the right way to handle Python libs. You'd prefer to have the distro package manager clashing with Pip? Never knowing who installed what. Breaking things when updates are made.
stefanor 3y ago
> What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path. Hi, I'm one of the people that look after this bit of Debian (and it's exactly the same in Ubuntu, FWIW). It's like that to solve a problem (of course, everything has a reason). The idea is that Debian provides a Python that's deeply integrated into Debian packages. But if you want to build your own Python from source, you can. What you build will use site-packages, so it won't have any overlap with Debian's Python. Unfortunately, while this approach was designed to be something all package-managed distributions could do, nobody else has adopted it, and consequently the code to make it work has never been pushed upstream. So, it's left as a Debian/Ubuntu oddity that confuses people. Sorry about that. My recommendations are: 1. If you want more control over your Python than you get from Debian's package-managed python, build your own from source (or use a docker image that does that). 2. Deploy your apps with virtualenvs or system-level containers per app.
KingMachiavelli 3y ago
IMO bespoke containers using whatever python package manager makes sense for each project. Or make the leap to Nix(OS) and then still have to force every python project into compliance which can be very easy if the PyPy packages you need are already in the main Nix repo (nixpkgs) or very difficult if depends on a lot of uncommon packages, uses poetry, etc. Since PEP 665 was rejected the Python ecosystem continues to lack a reasonable package manager and the lack of hashed based lock files prevents building on top of the current python project/package managers.
probably_a_gpt 3y ago
> I still haven't figured out how to beat this dragon. All suggestions welcome! Docker

by gjvc 3y ago

eyegor 3y ago

I usually make a venv in ~/.venv and then activate it at the top of any python project. Makes it much easier to deal with dependencies when they're all in one place.

synergy20 3y ago
second this and it's what I do on all Linux distros, just run it inside .venv as the site-installation. if you need extra dependencies that pip can not do well in the .venv case, Conda can help with its own and similar site-based installation. I don't know how it is different in the python installation case between ubuntu and debian, they seem the same to me.
gjvc 3y ago
i am a big fan of .venv/ -- except when it takes ~45 mins to compile the native extension code in question -- then I want it all pre-packaged.
- dgroshev 3y ago
  At this stage [0], uncompiled native extensions are not yet a bug, but a definite oversight of the maintainer. They should come as precompiled wheels [0]: https://pythonwheels.com https://pythonwheels.com
  - doliveira 3y ago
    Honestly I don't think I've ever used a precompiled package in Python. Every single C stuff seems to take ages and requires all that fun stuff of installing native system dependencies. Edit: skimming through this page, precompiling seems like an afterthought, and the linked packages don't even seem to mention how to integrate third-party libraries. So I guess I can see why it doesn't deliver on its promises.
    - toyg 3y ago
      Probably a function of the specific set of packages you use, or the pip options you specify. Pretty much all the major C packages come as wheels these days.
      - doliveira 3y ago
        They all come as wheels, they just aren't precompiled.
        toyg 3y ago
        I honestly can't remember the last time I had to compile anything, and I am on Windows.
        orf 3y ago
        Can you link one that comes as a wheel but is really a source distribution?
    - dgroshev 3y ago
      You can try pip install pillow for a good example of how it works. I suspect there's a strong survivorship bias here, as you'd only notice the packages that don't ship with wheels.
      - doliveira 3y ago
        Yeah, perhaps. One I remember from last year is the cryptography and numpy package, for instance. Now they do seem to ship with binary wheels, at least for my current Python and Linux version. Kerberos and Hadoop stuff obviously still doesn't, though. I guess the joke's on me for being stuck in this stack...
- j0057 3y ago
  It's a good idea to be caching sdists and wheels — for resilience against PyPI downtime, for left-pad scenarios, and even just good netiquette — and for packages that don't have a wheel for your environment, you can fairly easily build that wheel yourself and stick it into the cache.

silon42 3y ago

dist packages are a must for software written in Python that is part of the distribution itself.

smashed 3y ago
You're not really answering why they are important? Is it because .deb packages will install inside dist-packages and when you run pip install as root without a virtual env, it installs inside site-packages? I don't really see how this helps though? Sure you won't get paths to clash between the two but you still have duplicate packages which is probably not what you want..
- rlpb 3y ago
  Debian ships packages with a coherent dependency structure that crosses language boundaries. You don't need to care what language something is written in to be able to "apt install" it. The expectation is that if it "apt installed" then it should Just Work because all the required dependencies were also pulled in from Debian at the same time. Debian also tries to ship just one version of everything in a single distribution release to reduce the burden on its maintainers. This is fundamentally at odds with pip. If you've pip installed something, then that'll likely be the latest version of that package, and in the general case won't be the version of the same thing that shipped in the Debian release. If there exist debs that depend on that package and they are shared between pip and debs, now the deb could be using a different version of the dependency than the deb metadata says is acceptable, leading to breakage. Another way of putting this: it shouldn't be possible for you to pip upgrade a dependency that a deb shipped by Debian itself relies upon. Because then you'd creating a Frankenstein system where Debian cannot rely on its own dependencies providing what it expects. This is fixed by having two places where things are installed. One for what the system package manager ships, and one for your own use with pip and whatever you want to do. In this sense, having duplicate packages is actually exactly what you want.
  - sanderjd 3y ago
    Yep, I screw things up all the time with packages in homebrew that are written in python, when I forget to switch into a virtual env before doing stuff with pip. Debian's solution seems very sensible. And it is the same solution as homebrew, I suppose, as long as you don't interact with any of the homebrew-installed packages via pip. But I find it quite easy to accidentally do that.

kevin_thibedeau 3y ago

Dist packages is the right way to handle Python libs. You'd prefer to have the distro package manager clashing with Pip? Never knowing who installed what. Breaking things when updates are made.

stefanor 3y ago

> What is it with them which makes them feel entitled to have special "dist-packages" vs "site-packages" as is the default? This drives me nuts, when I have a bunch of native packages I want to bundle in our in-house python deployment. CentOS and Ubuntu are vanilla, and only Debian (mind-boggingly) deviates from the well-trodden path. Hi, I'm one of the people that look after this bit of Debian (and it's exactly the same in Ubuntu, FWIW). It's like that to solve a problem (of course, everything has a reason). The idea is that Debian provides a Python that's deeply integrated into Debian packages. But if you want to build your own Python from source, you can. What you build will use site-packages, so it won't have any overlap with Debian's Python. Unfortunately, while this approach was designed to be something all package-managed distributions could do, nobody else has adopted it, and consequently the code to make it work has never been pushed upstream. So, it's left as a Debian/Ubuntu oddity that confuses people. Sorry about that. My recommendations are: 1. If you want more control over your Python than you get from Debian's package-managed python, build your own from source (or use a docker image that does that). 2. Deploy your apps with virtualenvs or system-level containers per app.

KingMachiavelli 3y ago

IMO bespoke containers using whatever python package manager makes sense for each project. Or make the leap to Nix(OS) and then still have to force every python project into compliance which can be very easy if the PyPy packages you need are already in the main Nix repo (nixpkgs) or very difficult if depends on a lot of uncommon packages, uses poetry, etc. Since PEP 665 was rejected the Python ecosystem continues to lack a reasonable package manager and the lack of hashed based lock files prevents building on top of the current python project/package managers.

probably_a_gpt 3y ago

> I still haven't figured out how to beat this dragon. All suggestions welcome! Docker