Re: [PATCH v3 1/8] meson: stop discovering native version of Python
On 7/9/25 11:09 AM, Junio C Hamano wrote:
Show 30 quoted lines
>> -python = import('python').find_installation('python3', required: get_option('python'))
>> -target_python = find_program('python3', native: false, required: python.found())
>> -if python.found()
>> +# Python is not used for our build system, but exclusively for git-p4.
>> +# Consequently we only need to determine whether Python is available for the
>> +# build target.
>> +target_python = find_program('python3', native: false, required: get_option('python'))
>> +if target_python.found()
>> build_options_config.set('NO_PYTHON', '')
>> else
>> libgit_c_args += '-DNO_PYTHON'
>
> We ask explicitly for Python 3 here.
>
> Does find_program() have some magic to deal with installations where
> Python3 is simply called /usr/bin/python (and worse yet, not as a
> symbolic link to /usr/bin/python3)?
>
> I found
>
> "Since 0.50.0 if the "python3" program is requested and it is
> not found in the system, Meson will return its current
> interpreter",
>
> which I suspect refers to the path to python3 used during the build
> and is not what we want, at
>
> https://mesonbuild.com/Reference-manual_functions.html#find_program
>
> which got me a bit worried.Well, this patch doesn't really change that. But a cross compile where build != host and thus the build meson and build python don't represent the host `git`, already needs a cross env setup to define the right C compiler which can produce host binaries, and that's where you'd define the host python too.
[binaries] c = 'usr/bin/aarch64-linux-gnu-gcc'
# we have python 3.13, but our cross target is really old python3 = '/usr/bin/python3.6'
> Perhaps everybody with Python3 has it at /usr/bin/python3 these
> days, and my worries are unfounded? ;-)
>
> Thanks.
Python installs as python3.13 or some other major.minor version. "python3" is a symlink to that.
"python" may be a symlink to python 2.x, or 3.x, or not exist at all. I am not aware of *any* scenario where a distributor has re-packaged Python, "python" exists on PATH and is a real Python 3.x interpreter, but "python3" doesn't exist.
I am not aware of this ever being an existing real world scenario in the past, either -- it is not a "we no longer live in the bad old days" scenario.
The only big change to how people deploy python was around the unversioned "python" name.
Since 1996 and earlier, "python" was a symlink pointing to the "full" name, "python1.4". The full name was created by "make altinstall".
And "make install" had a Makefile dependency on "altinstall", and then additionally created symlinks. You could run "install" for a full default install, or "altinstall" if you wanted to install multiple versions side by side.
Python 3.x originally didn't create a "python" symlink, only a "python3" symlink, because too many people would have scripts running "python" and expect it to be version 2.x; this problem obviously never existed for "python3", as having the major version was new for "python3" and indeed the whole point of adding a new "prog{MAJORVERSION}" was to avoid confusing versions 2.x and 3.x
Anyways, yes, it is in my reasonably knowledgeable opinion flat out *impossible* for
find_program('python')to ever be a good idea when you could do
find_program('python3')The former will correctly work in a strict subset of cases that the latter already works; in some cases it seems to work but returns a bad program; in some cases it fails but using the right name would work.
--
Eli Schwartz
Patrick Steinhardt
