bug#53530: [PATCH] python: add 3.10 - 3.15 to the version search list

[Mike Frysinger]

On 26 Jan 2022 10:09, Zack Weinberg wrote:
> On Wed, Jan 26, 2022, at 6:37 AM, Mike Frysinger wrote:
> > Fixes automake bug https://bugs.gnu.org/53530.
> >
> > Based on the cadence of Automake releases, add the current Python
> > release (3.10), the current Python development (3.11), and then 4
> > more versions on top of that.  It doesn't hurt to check for a few
> > extra versions here since this is the fallback logic when the main
> > `python` and `python3` programs aren't found.
> 
> It's unfortunate that we keep having to update this list.  I wonder if 
> there's a clean way to detect all the available /^python\d\.\d+/ commands and 
> then sort them.

i posted some thoughts to Kerry, but looks like that thread went private.
so i'll paste them here.

Python is designed to have an arbitrary number of versions installed in
parallel, and for the canonical `python` to be pointing to any of them.
we have requests (that i think we should support) for compiling more than
one version in a single build.

so i agree that this handcoded list sucks, but i'm not sure of a better
way atm to handle it.  we could snoop $PATH manually with globs looking
for python[0-9].[0-9]+ and then sort by version, but doing that portably
is a bit of a nightmare, and i don't think autoconf provides any macros
off the shelf that we could leverage.

we could make the code a bit dynamic -- start at 3.0 and then count up
remembering the last version we saw, and repeat until we hit like 20
missing versions in a row.  but that doesn't exactly improve the code
that much, and this hardcoded version list is a fallback for when the
canonical `python` & `python3` are missing.  which, while possible,
shouldn't be that common ...
-mike

signature.asc
Description: PGP signature