Re: [PATCH v3 1/8] meson: stop discovering native version of Python

From: Eli Schwartz <eschwartz@gentoo.org>
Date: Jul 9, 2025, 22:22 UTC
Message-ID: <1664d442-7985-41b7-9391-78f78ece7601@gentoo.org>
In-Reply-To: <xmqqikk1pfiz.fsf@gitster.g>

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