On 5/13/22 16:38, John Snow wrote:
> It *should*, because "#!/usr/bin/env python3" is the preferred shebang
> for Python scripts.
>
> https://peps.python.org/pep-0394/ <https://peps.python.org/pep-0394/>
>
> 'python3' "should" be available. 'python' may not be.
>
> Probably the "python" name in Makefile for TESTS_PYTHON should actually
> be "python3" as well. In practice, all permutations (python, python3,
> python3.9, etc.) are symlinks* to the binary used to create the venv.
> Which links are present may be site configurable, but pep394 should
> guarantee that python3 is always available.
IIRC we have some cases (FreeBSD?) where only the python3.x executable
is available. This is why we 1) default to Meson's Python 3 if neither
--meson nor --python are passed, and 2) use the shebang you mention but
with *non-executable* files, which Meson treats magically as "invoke
with the Python interpreter that was used to launch me".
Paolo
pkg install python3 on fbsd 13.0-R gives you /usr/bin/python3 fwiw. do you know in what circumstances you get only a point release binary?
Creating a venv on fbsd with "python3 -m venv testvenv" created a python3 binary link, but not a python3.8 link, also.
Still leaning towards the idea that "python3" is safest, but maybe it depends on how you install from ports etc. I'd still say that it's reasonable to expect that a system with python pays heed to PEP0394, I think you've got a broken python install if you don't.
(But, what's the use case that forced your hand otherwise?)
--js