4 ms·

Your last sentence doesn't parse for me at all. How exactly do you get a pip installed on Python 3.6 to modify anything about another install of Python, let alo

Your last sentence doesn't parse for me at all. How exactly do you get a pip installed on Python 3.6 to modify anything about another install of Python, let alone a different version?

nerdponx 5y ago
If your distro dumps all the installed files into `/usr/lib/python3` without distinguishing among 3.8, 3.9, etc.
- rbanffy 5y ago
  > If your distro dumps all the installed files into `/usr/lib/python3` Oh dear... What kind of monster does this?
salawat 5y ago
Apt install python-pip3 You'll get pip3 from Python 3.6. apt install python3.8 You'll get system-level python3. Use pip3 in 3.6 to install the latest pip3 that requires Python 3.8, and drops that package in the dist-packages folder, which is shared between system Python runtime versions. Behold as further attempts to do something sane with APT blow up, because now you have 3.8 packages on 3.6's runtime path. I've lost weeks to this particular brand of distro daftness. I thought that surely no one would do that .. Alas...
- rbanffy 5y ago
  "Thou shalt not mess with the system Python"
  - dagw 5y ago
    While I agree with this statement, it's also kind of the distro's fault for making it so easy to mess with system Python. If I was ever to design a distro and needed a "system Python" I would make sure that it would be completely isolated from and invisible to users. It would only be upgraded as part of an overall major OS version upgrade.
  - salawat 5y ago
    Given, and yes I've heard that before, but I counter with: If you don't want someone to mess with it, name it as something other people will not regularly have a reason to muck with. One concerted effort to ship distro's with a "sys-python" symlink instead of /usr/bin/python, and for all things currently using the newly minted sys-python stuff can be free of wayward travelers and system sculptors like me mucking with things. No, pyenv is not the answer. Naming things is. And trust me. I get it. It's a rite of passage learned in due time, yada-yada. Got it. If we ever want to get this stuff easier to use though, we have to be willing to help draw clean distinctions between this and that. Virtual environments don't do that until it is far too late and a beginner is already in and over their head in breakage.
    - rbanffy 5y ago
      > No, pyenv is not the answer. Naming things is. In my experience, Pyenv is almost never the answer.
- Joker_vD 5y ago
  Ah, so that what happened in my anecdotal story in another comment in this thread [0]. But why would you need a newer python3 anyway? The package maintainers ship 3.6 by default for a reason and they know better than you! /s [0] https://news.ycombinator.com/item?id=29238700#29239446 https://news.ycombinator.com/item?id=29238700#29239446
  - salawat 5y ago
    In my case? Recreating a build environment in the process of debugging an issue with a build script and trying to get the runtime environment lined up just so; with a side objective of an exploration of the madness of how Python as a language handles packaging (part of which was what kind of footguns are presented by the lang specific package manager, which funnily enough also seems to be completely oblivious to the runtime version it's executing in). >The package maintainers ship 3.6 by default for a reason and they know better than you! /s Maybe then! Not anymore! It really does infuriate me because it breaks every aspect of the principle of least surprise and conventional software packaging practice.
- formerly_proven 5y ago
  > the dist-packages folder, which is shared between system Python runtime versions. I mean... I understand how hypothetically this could in theory make some sense because a distro might naively expect to ship the same package version for different Python versions and so all files could be the same except for native extensions, which are disambiguated by implementation name, so theoretically one could imagine a position where this could be conceived of as a thing one could do to save some space in case someone installs the same package for multiple Python versions. But in reality? Jesus fucking christ. However, I don't see how this can be blamed on Python. This isn't something that "just happens because Python" and is certainly far, far away from any kind of default Python configuration, where all default paths are below the prefix, which contains the Python version. This is something that can only happen because someone went extraordinarily far out of their way to shoot someones else's foot off.
  - salawat 5y ago
    I never blamed Python for it per SE, because that is 100% a packager thing. It's definitely the distro's fault (cough Ubuntu cough). >This is something that can only happen because someone went extraordinarily far out of their way to shoot someones else's foot off. Ding ding ding.

Your last sentence doesn't parse for me at all. How exactly do you get a pip installed on Python 3.6 to modify anything about another install of Python, let alone a different version?

nerdponx 5y ago

If your distro dumps all the installed files into `/usr/lib/python3` without distinguishing among 3.8, 3.9, etc.

rbanffy 5y ago
> If your distro dumps all the installed files into `/usr/lib/python3` Oh dear... What kind of monster does this?

salawat 5y ago

Apt install python-pip3 You'll get pip3 from Python 3.6. apt install python3.8 You'll get system-level python3. Use pip3 in 3.6 to install the latest pip3 that requires Python 3.8, and drops that package in the dist-packages folder, which is shared between system Python runtime versions. Behold as further attempts to do something sane with APT blow up, because now you have 3.8 packages on 3.6's runtime path. I've lost weeks to this particular brand of distro daftness. I thought that surely no one would do that .. Alas...

rbanffy 5y ago
"Thou shalt not mess with the system Python"
- dagw 5y ago
  While I agree with this statement, it's also kind of the distro's fault for making it so easy to mess with system Python. If I was ever to design a distro and needed a "system Python" I would make sure that it would be completely isolated from and invisible to users. It would only be upgraded as part of an overall major OS version upgrade.
- salawat 5y ago
  Given, and yes I've heard that before, but I counter with: If you don't want someone to mess with it, name it as something other people will not regularly have a reason to muck with. One concerted effort to ship distro's with a "sys-python" symlink instead of /usr/bin/python, and for all things currently using the newly minted sys-python stuff can be free of wayward travelers and system sculptors like me mucking with things. No, pyenv is not the answer. Naming things is. And trust me. I get it. It's a rite of passage learned in due time, yada-yada. Got it. If we ever want to get this stuff easier to use though, we have to be willing to help draw clean distinctions between this and that. Virtual environments don't do that until it is far too late and a beginner is already in and over their head in breakage.
  - rbanffy 5y ago
    > No, pyenv is not the answer. Naming things is. In my experience, Pyenv is almost never the answer.
Joker_vD 5y ago
Ah, so that what happened in my anecdotal story in another comment in this thread [0]. But why would you need a newer python3 anyway? The package maintainers ship 3.6 by default for a reason and they know better than you! /s [0] https://news.ycombinator.com/item?id=29238700#29239446 https://news.ycombinator.com/item?id=29238700#29239446
- salawat 5y ago
  In my case? Recreating a build environment in the process of debugging an issue with a build script and trying to get the runtime environment lined up just so; with a side objective of an exploration of the madness of how Python as a language handles packaging (part of which was what kind of footguns are presented by the lang specific package manager, which funnily enough also seems to be completely oblivious to the runtime version it's executing in). >The package maintainers ship 3.6 by default for a reason and they know better than you! /s Maybe then! Not anymore! It really does infuriate me because it breaks every aspect of the principle of least surprise and conventional software packaging practice.
formerly_proven 5y ago
> the dist-packages folder, which is shared between system Python runtime versions. I mean... I understand how hypothetically this could in theory make some sense because a distro might naively expect to ship the same package version for different Python versions and so all files could be the same except for native extensions, which are disambiguated by implementation name, so theoretically one could imagine a position where this could be conceived of as a thing one could do to save some space in case someone installs the same package for multiple Python versions. But in reality? Jesus fucking christ. However, I don't see how this can be blamed on Python. This isn't something that "just happens because Python" and is certainly far, far away from any kind of default Python configuration, where all default paths are below the prefix, which contains the Python version. This is something that can only happen because someone went extraordinarily far out of their way to shoot someones else's foot off.
- salawat 5y ago
  I never blamed Python for it per SE, because that is 100% a packager thing. It's definitely the distro's fault (cough Ubuntu cough). >This is something that can only happen because someone went extraordinarily far out of their way to shoot someones else's foot off. Ding ding ding.