On Wed, Jun 2, 2021 at 2:22 PM Ben Greiner <code@bnavigator.de> wrote:
Am 02.06.21 um 14:52 schrieb Adam Majer:
On Wed, Jun 02, 2021 at 10:50:11AM +0200, Jan Engelhardt wrote:
On Wednesday 2021-06-02 10:45, Ben Greiner wrote:
Am 02.06.21 um 10:26 schrieb Jan Engelhardt:
python3 would hardly exec /usr/bin/python (v2). They're still sane.
Many ignorant python scripts
Ignorant scripts are one thing. Ignorant node runtimes is another level.
Well, I kind of detect a bias? Here's a naive python example,
f133:~ # cat worker.py #!/usr/bin/python3
import platform print(platform.python_version())
f133:~ # cat daemon.py #!/usr/bin/python3
import subprocess
subprocess.Popen(['./worker.py']).wait()
f133:~ # python3. python3.6 python3.6m python3.8 python3.9 f133:~ # python3.6 ./daemon.py 3.8.10 f133:~ # python3.6 ./worker.py 3.6.13
So, with node, if you did this experiment, and you started it with node10, you would get node10 in the worker irrespective what /usr/bin/node points to.
Basically, once we allow multiple interpreters to be co-installed, they actually should run as expected.
But how do you know what "is expected"? In the Python case we can only assume that PEP 394 is the de-facto standard:
---PEP 394--- - When reinvoking the interpreter from a Python script, querying sys.executable to avoid hardcoded assumptions regarding the interpreter location remains the preferred approach. ---PEP 394---
No? Saying the problem is "out of scope" tells me that something is abused for purposes that were not intended (looking at update-alternatives here).> Anyway, this is an example of why pure symlinks are bad and actually result in confusion at runtime.
Your example does not involve u-a at all. We don't put the python3 command under u-a control. We even go out of our way and fix the "ignorant scripts", who install wrong script interpreter lines and do something to the extent of replacing `subprocess.call("./worker.py")` or `subprocess.call("python", "./worker.py")` with `subprocess.call(sys.executable, "./worker.py")`.
Am 02.06.21 um 10:46 schrieb Adam Majer:
python3 exec python3, of course. But what happens if you have python3.8 and python3.10 installed and want your app to use python3.8? That app then starts a child process and you are in python3.10 then?
If you know you want python3.8, then call python3.8. If the app depends on the same python version as it is called on the toplevel call, it MUST use `sys.executable`. `"/usr/bin/python3"` is always the current TW primary python3 flavor and all dependencies for the script calling it must be provided in that flavor.
When Python setuptools installs "entrypoints" it takes care of the correct script interpreter automatically. In the case of multiple flavors, this is overwritten by `%python_clone -a %{buildroot}%{_bindir}/myentrypoint` creating the u-a symlinks and adjusting the script interpreter lines.
Any python package, which installs commands into %{_bindir} must either be for the primary python3 flavor only or the handling of different flavors must be taken care of by u-a and adjusted script interpreter lines as described above.
Apparently Node.js is more lenient on different flavors. But as you describe, this calls for problems with u-a.
Why are we using alternatives with Python anyway? Why not just use the swappable package strategy for `/usr/bin/python` and `/usr/bin/python3`? -- 真実はいつも一つ！/ Always, there's only one truth!