(There's no need for all-caps vitriol.) [LWN.net]

(There's no need for all-caps vitriol.)

Posted May 22, 2025 17:07 UTC (Thu) by NYKevin (subscriber, #129325)
In reply to: (There's no need for all-caps vitriol.) by zahlman
Parent article: Recent disruptive changes from Setuptools

Fun fact: If a distro wants to support --user, it's not outrageously hard to do so. You just have to make sure that any system packages that require Python set the -s flag (on /usr/bin/python) or the PYTHONNOUSERSITE environment variable (to any value), and then whatever is in the user's home directory is silently ignored. I imagine there are varying levels of difficulty here:

* For stuff managed by whatever init you are using (let's not start a systemd holy war here), this should be trivial.
* For stuff managed by systemd --user (or any equivalent, as well as session-related stuff like GDM/KDM/login/getty/etc.), this should also be trivial.
* That just leaves binaries that the user runs. If it's run through the desktop shell, this can be configured in the .desktop file, and if it's run from the command line, it can be configured in the shebang line... unless you are using the #!/usr/bin/env python trick, in which case you already used up your one argument and cannot pass flags through to Python (or, for that matter, ask env to set the environment variable for you). But if you're the distro, you should know where Python is installed and do not need to use /usr/bin/env in the first place.

I imagine the main reason they don't do this in practice is the shebang. All of the other things can plausibly use the environment variable, which is preferable because it Just Works and does not require pervasively editing /usr/bin/python command line flags everywhere. The shebang, on the other hand, does require pervasive editing and also has the downside of not being automatically inherited by child processes. So it's a question of whether distros are willing to spend the time to support that.

to post comments

(There's no need for all-caps vitriol.)

Posted May 29, 2025 21:16 UTC (Thu) by zahlman (guest, #175387) [Link]

> unless you are using the #!/usr/bin/env python trick, in which case you already used up your one argument and cannot pass flags through to Python (or, for that matter, ask env to set the environment variable for you). But if you're the distro, you should know where Python is installed and do not need to use /usr/bin/env in the first place.

More to the point, the distro *shouldn't* use /usr/bin/env this way, because that allows the user to override which Python is used - in particular, after "activating" a virtual environment, that would generally be used instead. Which will generally be Bad for system-provided scripts.

(But for the user's use, some versions of env support the -S flag, which *does* allow for passing command-line options like -s along to Python. And, of course, you can always put a shell wrapper around the startup process too.)

> I imagine the main reason they don't do this in practice is the shebang. All of the other things can plausibly use the environment variable, which is preferable because it Just Works and does not require pervasively editing /usr/bin/python command line flags everywhere. The shebang, on the other hand, does require pervasive editing and also has the downside of not being automatically inherited by child processes.

If the child is also Python code, there are other ways to run that code in a new process, but they aren't trivial changes.