I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`.

Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an example, I don't feel that your comparison is apple to an apple.

>Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful.

They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by standard Python development, whereas I would rarely expect that to be the case with however each component chooses to execute JavaScript.

Apps that rely on OS provided Webview and electron apps are totally different situation. This is exactly what I said. And no, they don't use any standard nodejs installation like python. And they are different as I said. so this is still apples to orange comparison.

>Apps that rely on OS provided Webview and electron apps are totally different situation.

No, they're not. I'm talking about core apps and services that are essential to a functional operating system. This is exactly the same situation. The difference is choices made by the OS and language ecosystem about how to manage dependencies in various use-cases. It is an apples to oranges comparison because of those decisions and not because of the language.

Which apps would that be ? I'm pretty sure there's zero node server running on my desktops & laptops at the moment

My slightly heretical opinion is that Debian would have been better off removing system pip entirely. The system python is for the system.

My not so heretical opinion is that PIP should behave like NPM by default, and work under a local environment subdirectory, just like "npm install" already creates a "node_modules" directory where to put all files, without the user needing to specify how and where and which env tool to use.

Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal.

It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case for shells where they're actually UI, but I've seen so much effort wasted over the years trying to let system interpreters do double-duty as both system tools and development environments that I've come to the conclusion that it's simply not worth the hassle.

That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps:

  1. npm install
  2. node my_script.js

First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file.

Second one runs the interpreter with the script file and against the locally downloaded dependencies.

I.e. the local env dirs in Node.js are not a suggestion that you need to learn about, make choices, and actually use; they are just how the tool works by default, which makes the experience of using Node.js with NPM by far much better and less confusing than the default experience of using Python with PIP.

I have years of painful experience with node.js, yes. The critical difference between node and python is that there are no system-provided scripts on my system which have `#!/usr/bin/node` as a first line.

There are a load of scripts with `#!/usr/bin/python` (or similar) in `/bin`, which means package resolution can't look first in a local subdir otherwise all bets are off. Again: your system will break depending on which directory you run bits of it from. The system-provided process would be loading dependencies that it was not tested against. In case this is unclear, you do not want that to happen. It would be bad. On my system I can see python scripts involved in driver management. I do not want them to do unexpected things. It would be bad.

Python package management is a mess in lots of ways, but this particular choice isn't one of them.

> which means package resolution can't look first in a local subdir

Sure it can, it's just a matter of examining where it's being run from.

I wrote python-wool to load packages from a venv if it finds one.

https://github.com/fragmede/python-wool

Yep. That comes under the category of "not default". Although now you've pointed it out I'll probably be using it.

Python is a scripting language. I shouldn’t need to faff about with environments if I want to run my script on another machine.

Encountered this too. So annoying.