5 ms·

For context, the root cause to this is actually in Debian, not setuptools (or pip). Debian vendor-patches the stdlib distutils, which setuptools used to depend

For context, the root cause to this is actually in Debian, not setuptools (or pip). Debian vendor-patches the stdlib distutils, which setuptools used to depend on, but lost in v50 since it does not depend on the stdlib distutils anymore. This issue was known for quite a while, and IIRC more recent Debian (and thus Ubuntu) versions contain a fix. But the change was not backported for other reasons I am not personally familar with.

Iv 6y ago
While we are at it, can we finally get rid of python 2? And find some sane way to not need python3.6 python3.7 and python3.8 laying around and installing each their own libs versions?
- simcop2387 6y ago
  I have done this on my laptop running debian nextstable, so it is happening and will be the default soon.
  - Iv 6y ago
    Finally a good news!
- xorcist 6y ago
  Python has to implement all the same mistakes Java did. All they have to do is release a new major version twice a year and then they're done. Sorry, just joking (I hope). Also, we didn't have to suffer UTF-16.
- jnxx 6y ago
  A few days ago, I learned that the Python interpreter does not specifically uses semantic versioning. Which means that a change in the minor version number (like 3.8 to 3.9) could break backward compatibility.
  - Iv 6y ago
    "could" but does it, actually? The breaking changes they did from 2 to 3 caused enough headaches that I think no one wants to go through that again.
simonh 6y ago
I don't understand sorry, I must be misunderstanding you. If setuptools doesn't depend on the stdlib distutils provided by Debian anymore, why is this a problem due to Debian? How can you have a problem due to something you don't depend on?
- pas 6y ago
  Uh, it's complicated. I read this about three times, but I still don't know who messed up what: https://github.com/pypa/setuptools/issues/2350#issuecomment-683512526 https://github.com/pypa/setuptools/issues/2350#issuecomment-... Basically it seems the Debian python does not add site-packages to its search path, but manually installing pip (via get-pip.py) installs things there. And this all worked before, because Debian shipped a patched distutils, but now setuptools vendors that.
  - ptx 6y ago
    So it only affects non-distro-provided manual pip installations? If I use Debian's Python (or some manually downloaded Python) to create a venv and install the new pip in there, it would be fine, right? That would make it a complete non-issue for me. The global Python installation is managed by Debian. Pip is only ever used inside a venv.
    - uranusjr 6y ago
      That’s correct. Things only break if you pip install setuptools into the Debian-provided Python globally, not if you use both system-provided setuptools and pip, nor if you pip install setuptools into a venv. IMO neither party really did anything wrong, the situation is caused by users depending on implementation detail that used to work but no longer does. I would’t say it’s a non-issue though. There are so many instructions out there that recommend `sudo pip install -U pip setuptools`, and Python packaging developers take all the blame when the spacebar no longer overheats the CPU. This situation is, in some way, a microcosm of how people get the impression that “Python packaging is a mess”.
      - 6y ago

Iv 6y ago

While we are at it, can we finally get rid of python 2? And find some sane way to not need python3.6 python3.7 and python3.8 laying around and installing each their own libs versions?

simcop2387 6y ago
I have done this on my laptop running debian nextstable, so it is happening and will be the default soon.
- Iv 6y ago
  Finally a good news!
xorcist 6y ago
Python has to implement all the same mistakes Java did. All they have to do is release a new major version twice a year and then they're done. Sorry, just joking (I hope). Also, we didn't have to suffer UTF-16.
jnxx 6y ago
A few days ago, I learned that the Python interpreter does not specifically uses semantic versioning. Which means that a change in the minor version number (like 3.8 to 3.9) could break backward compatibility.
- Iv 6y ago
  "could" but does it, actually? The breaking changes they did from 2 to 3 caused enough headaches that I think no one wants to go through that again.

simonh 6y ago

I don't understand sorry, I must be misunderstanding you. If setuptools doesn't depend on the stdlib distutils provided by Debian anymore, why is this a problem due to Debian? How can you have a problem due to something you don't depend on?

pas 6y ago
Uh, it's complicated. I read this about three times, but I still don't know who messed up what: https://github.com/pypa/setuptools/issues/2350#issuecomment-683512526 https://github.com/pypa/setuptools/issues/2350#issuecomment-... Basically it seems the Debian python does not add site-packages to its search path, but manually installing pip (via get-pip.py) installs things there. And this all worked before, because Debian shipped a patched distutils, but now setuptools vendors that.
- ptx 6y ago
  So it only affects non-distro-provided manual pip installations? If I use Debian's Python (or some manually downloaded Python) to create a venv and install the new pip in there, it would be fine, right? That would make it a complete non-issue for me. The global Python installation is managed by Debian. Pip is only ever used inside a venv.
  - uranusjr 6y ago
    That’s correct. Things only break if you pip install setuptools into the Debian-provided Python globally, not if you use both system-provided setuptools and pip, nor if you pip install setuptools into a venv. IMO neither party really did anything wrong, the situation is caused by users depending on implementation detail that used to work but no longer does. I would’t say it’s a non-issue though. There are so many instructions out there that recommend `sudo pip install -U pip setuptools`, and Python packaging developers take all the blame when the spacebar no longer overheats the CPU. This situation is, in some way, a microcosm of how people get the impression that “Python packaging is a mess”.
    - 6y ago