4 ms·

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaki

It is such a non problem it forced them to hack a „fuck you this Python is owned by the distribution not you“ message into pip requiring you to agree to „breaking your system“ to use it. Of all the languages, python in the base system has been an unmitigated garbage fire.

bgwalter 1y ago
This should become the official error message!
zahlman 1y ago
> it forced them to hack a It was not their action, nor is it hacked, nor is the message contained within pip. The system works by pip voluntarily recognizing a marker file, the meaning of which was defined by https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/ — which was the joint effort of people representing multiple Linux distros, pip, and Python itself. (Many other tools ignore the system Python environment entirely, as mine will by default.) Further, none of this causes containers to be necessary for installing ordinary projects. Further, it is not a problem unique to Python. The distro simply can't package all the Python software out there available for download; it's completely fair that people who use the Python-native packaging system should be expected not to interfere with a system package manager that doesn't understand that system. Especially when the distro wants to create its tools in Python. You only notice it with Python because distros aren't coming with JavaScript, Ruby etc. pre-installed in order to support the system.
- bgwalter 1y ago
  Well the essential system Python should be in /usr/sbin and read-only (insofar Python allows that with its __pycache__ spam). The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.
  - zahlman 1y ago
    > the essential system Python should be in /usr/sbin There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL.... > insofar Python allows that with its __pycache__ spam This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pycache__` folders in those locations). This leverages the standard library `compileall` module — from the Makefile: @ # Build PYC files for the 3 optimization levels (0, 1, 2) -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi $(DESTDIR)$(LIBDEST)/compileall.py \ -o 0 -o 1 -o 2 $(COMPILEALL_OPTS) -d $(LIBDEST) -f \ -x 'bad_coding|badsyntax|site-packages' \ $(DESTDIR)$(LIBDEST) > The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken. Please do not spread FUD. They don't have to do any of that. All they have to do is make a virtual environment, which can have any name, and the creation of which is explicitly supported by the standard library. Further, reading the PEPs is completely irrelevant to end users. They only describe the motivation for changes like --break-system-packages. Developers may care about PEPs, but they can get a better summary of the necessary information from https://packaging.python.org https://packaging.python.org ; and none of the problems there have anything to do with Linux system Python environments. The config files that developers care about are at the project root. Today, on any Debian system, you can install an up-to-date user-level copy of yt-dlp (for example) like so, among many other options: sudo apt install pipx pipx install yt-dlp You only have to know how one of many options works, in order to get a working system.
    - im3w1l 1y ago
      > All they have to do is make a virtual environment Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script. Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.
- nmstoker 1y ago
  Thank you! Exactly what I wanted to explain.
  - hedora 1y ago
    Yet, if I write a dockerfile, and need to use perl, system perl is fine. If I need a python script, I have to arrange for all the RUN lines to live inside a virtual environment inside the container.
cozzyd 1y ago
yes because then you're starting to use non-distro python packages. If you want to do that, use a virtualenv, there is no safe other way (even if there was no python in the base system) .
- stefan_ 1y ago
  Yes, the distro people are strong believers in virtual environments as best practice - for you, not them.
  - cozzyd 1y ago
    There's a good reason for this. The average user has no idea and doesn't care what language some random distro-packaged program is written in. They want to be able to run ubxtool or gdal_calc or virt-manager or whatever without setting up a virtual environment. Python developers on the other hand should be adept at such things, should they choose to use a non-distro packaged version of something. The tricky part is when "users" start using pip to install something because someone told them to.
pdntspa 1y ago
People are too harsh on this. It's not hard to install a version manager and set your primary python to that. Which is just good hygiene. My understanding of the reasoning is that python-based system packages having dependencies managed through pip/whatever present a system stability risk. So they chose this more conservative route, as is their MO. Honestly if there is one distribution to expect those kinds of shennanigans on it would be Debian. I don't know how anybody chooses to use that distro without adding a bunch of APT sources and a language version manager.

bgwalter 1y ago

This should become the official error message!

zahlman 1y ago

> it forced them to hack a It was not their action, nor is it hacked, nor is the message contained within pip. The system works by pip voluntarily recognizing a marker file, the meaning of which was defined by https://peps.python.org/pep-0668/ https://peps.python.org/pep-0668/ — which was the joint effort of people representing multiple Linux distros, pip, and Python itself. (Many other tools ignore the system Python environment entirely, as mine will by default.) Further, none of this causes containers to be necessary for installing ordinary projects. Further, it is not a problem unique to Python. The distro simply can't package all the Python software out there available for download; it's completely fair that people who use the Python-native packaging system should be expected not to interfere with a system package manager that doesn't understand that system. Especially when the distro wants to create its tools in Python. You only notice it with Python because distros aren't coming with JavaScript, Ruby etc. pre-installed in order to support the system.

bgwalter 1y ago
Well the essential system Python should be in /usr/sbin and read-only (insofar Python allows that with its __pycache__ spam). The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken.
- zahlman 1y ago
  > the essential system Python should be in /usr/sbin There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL.... > insofar Python allows that with its __pycache__ spam This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pycache__` folders in those locations). This leverages the standard library `compileall` module — from the Makefile: @ # Build PYC files for the 3 optimization levels (0, 1, 2) -PYTHONPATH=$(DESTDIR)$(LIBDEST) $(RUNSHARED) \ $(PYTHON_FOR_BUILD) -Wi $(DESTDIR)$(LIBDEST)/compileall.py \ -o 0 -o 1 -o 2 $(COMPILEALL_OPTS) -d $(LIBDEST) -f \ -x 'bad_coding|badsyntax|site-packages' \ $(DESTDIR)$(LIBDEST) > The fact that users have to keep up with multiple PEPs, error messages, --single-version-externally-managed, --break-system-packages, config files everywhere, stealth packages in .local and uv to paper over all of this shows that Python packaging is completely broken. Please do not spread FUD. They don't have to do any of that. All they have to do is make a virtual environment, which can have any name, and the creation of which is explicitly supported by the standard library. Further, reading the PEPs is completely irrelevant to end users. They only describe the motivation for changes like --break-system-packages. Developers may care about PEPs, but they can get a better summary of the necessary information from https://packaging.python.org https://packaging.python.org ; and none of the problems there have anything to do with Linux system Python environments. The config files that developers care about are at the project root. Today, on any Debian system, you can install an up-to-date user-level copy of yt-dlp (for example) like so, among many other options: sudo apt install pipx pipx install yt-dlp You only have to know how one of many options works, in order to get a working system.
  - im3w1l 1y ago
    > All they have to do is make a virtual environment Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script. Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.
nmstoker 1y ago
Thank you! Exactly what I wanted to explain.
- hedora 1y ago
  Yet, if I write a dockerfile, and need to use perl, system perl is fine. If I need a python script, I have to arrange for all the RUN lines to live inside a virtual environment inside the container.

cozzyd 1y ago

yes because then you're starting to use non-distro python packages. If you want to do that, use a virtualenv, there is no safe other way (even if there was no python in the base system) .

stefan_ 1y ago
Yes, the distro people are strong believers in virtual environments as best practice - for you, not them.
- cozzyd 1y ago
  There's a good reason for this. The average user has no idea and doesn't care what language some random distro-packaged program is written in. They want to be able to run ubxtool or gdal_calc or virt-manager or whatever without setting up a virtual environment. Python developers on the other hand should be adept at such things, should they choose to use a non-distro packaged version of something. The tricky part is when "users" start using pip to install something because someone told them to.

pdntspa 1y ago

People are too harsh on this. It's not hard to install a version manager and set your primary python to that. Which is just good hygiene. My understanding of the reasoning is that python-based system packages having dependencies managed through pip/whatever present a system stability risk. So they chose this more conservative route, as is their MO. Honestly if there is one distribution to expect those kinds of shennanigans on it would be Debian. I don't know how anybody chooses to use that distro without adding a bunch of APT sources and a language version manager.