On Fri, May 13, 2022, 11:33 AM Paolo Bonzini <pbonz...@redhat.com> wrote:
> 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 >
