# Find newer Python using old FindPython
**URL:** https://discourse.cmake.org/t/find-newer-python-using-old-findpython/15221
**Category:** Usage
**Tags:** os:linux, os:windows, os:macos
**Created:** [October 7, 2025, 8:54am UTC](https://discourse.cmake.org/t/find-newer-python-using-old-findpython/15221 "2025-10-07T08:54:05Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Andrej730](https://discourse.cmake.org/u/Andrej730)
#### Post date: [October 7, 2025, 8:54am UTC](https://discourse.cmake.org/t/find-newer-python-using-old-findpython/15221/1 "2025-10-07T08:54:05Z")
In my cmake I fetch a couple Python components - `Development`, `Interpreter` and for simplicity I wanted to provide Python installation by just prefixing the PATH (e.g. ` -DCMAKE_PREFIX_PATH="/my/install/python-3.13.6"`) instead of providing 3 variables explicitly (`Python_INCLUDE_DIR`, `Python_LIBRARY`, `Python_EXECUTABLE`).
Which does work for Python 3.9-3.12, but cmake fails to find it in case of Python 3.13.
Investigating, I’ve learned that Python 3.9-3.12 work because FindPython manages to find python `python3.12-config` and it’s used to deduce libraries path later.
It also fallbacks to `find_library` search with debug path hints, but again, it won’t suceed because `python3.13.a` is not present among the `NAMES`.
And in my case the system cmake is 3.26.5 and apparently the list of config files to search is hardcoded
```auto
find_program called with the following settings:
VAR: _Python_CONFIG
NAMES: "python3.12-config"
"python3.11-config"
"python3.10-config"
"python3.9-config"
"python3.8-config"
"python3.7-config"
"python3.6-config"
"python3.5-config"
"python3.4-config"
"python3.3-config"
"python3.2-config"
"python3.1-config"
"python3.0-config"
```
Which comes from ([ref](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/FindPython/Support.cmake?ref_type=heads#L26-32)):
```cmake
if (_${_PYTHON_PREFIX}_REQUIRED_VERSION_MAJOR EQUAL "3")
set(_${_PYTHON_PREFIX}_VERSIONS 3.12 3.11 3.10 3.9 3.8 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0)
elseif (_${_PYTHON_PREFIX}_REQUIRED_VERSION_MAJOR EQUAL "2")
set(_${_PYTHON_PREFIX}_VERSIONS 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0)
else()
```
And since Python 3.13 didn’t existed at the time, it’s not listed in the list of versions and it fails to find it’s `python3.13-config` and fails to find Python in general.
Providing `-DPython_ROOT_DIR` (though it would be less desirable, since it adds a special variable, instead of just prefixing PATH) doesn’t work too.
So I guess the only solution is to provide all 3 variables mentioned above.
I guess this kind of situation will keep reoccurring each year with new Python coming up, so if user’s script that’s using `cmake` is planning to support the most recent Python versions, then they should avoid relying on prefixing `PATH` and provide all variables explicitly.
Perhaps there could be more general solution? I’ve also noticed that Python installation includes in `bin` not just `python3.13-config`, but non-version-specific`python3-config`, which in theory FindPython could search for too and this would allow finding Python versions from the future.
PS With that being said, I’ve only tested finding 3.13 on cmake 3.26.5. It’s possibly that this issue is resolved in newer `cmake` (e.g. maybe now it’s possible to find 3.15 by using current FindPython), but couldn’t find the discussion about this.
---
### Author:  [@Andrej730](https://discourse.cmake.org/u/Andrej730)
#### Post date: [October 7, 2025, 11:57am UTC](https://discourse.cmake.org/t/find-newer-python-using-old-findpython/15221/2 "2025-10-07T11:57:53Z")
Investigating some more, it seems `python3-config` doesn’t provide a direct way to get version with `--version` or something.
>
Apparently it would be only possible to get it by parsing it either from one of it’s options (e.g. `--includes` returns `/include/python3.13`) or from `VERSION="3.13"` line in the file.
Both approaches seems a bit fragile for FindPython to use them ☹
And also on Windows there’s no `pythonx.xx-config.exe` (though currently cmake is still searching for it using `find_program` - probably just an overlook) and not sure what would be the alternative for this system.