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

Posted May 29, 2025 21:16 UTC (Thu) by zahlman (guest, #175387)
In reply to: (There's no need for all-caps vitriol.) by NYKevin
Parent article: Recent disruptive changes from Setuptools

> 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.