FindPython3 has unexpected behavior on Windows

[tejlmand]

Bug created based on: #24364 (comment)
@AdrianEggenberger

I just struggled after an issue that probably is related to this topic. Maybe I may add my observation here. If it would be better to open a new issue give me a note.

The difference in my case is that I'm using a windows system. There are three python instances installed on the system:

• Python 2.7.x
• Python 3.8.1 (x86)
• Python 3.8.2 (x64)

The last of these three is the only one that is in set in the PATH variable. It is also the installation that has west installed and i would prefer to use. Till the update from a previous release to the latest master commit everything worked fine. Since the update an attempt to build with "west build" starts the build process and than fails because west is not found. From the log (see below) I can see that the used Python instance is the one with version 3.8.1 (x86). Why is that? It's quite confusing now...

I think having two python 3 installations is probably not common, but I need both of these because I need to use prebuilt libraries that only works with the (x86) variant.

Is there an elegant way to solve this issue? Can it be solved in the framework?

------ build log -------
C:\Nordic\zephyrproject\zephyr\samples\bluetooth\hci_usb>west build
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): C:/Nordic/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: C:/Nordic/zephyrproject/zephyr/samples/bluetooth/hci_usb
-- Zephyr version: 2.2.99 (C:/Nordic/zephyrproject/zephyr)
-- Board: nrf52840dk_nrf52840
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'west'
CMake Error at C:/Nordic/zephyrproject/zephyr/cmake/host-tools.cmake:26 (message):
Unable to import west.version from 'C:/Python38x86/python.exe'
Call Stack (most recent call first):
C:/Nordic/zephyrproject/zephyr/cmake/app/boilerplate.cmake:483 (include)
C:/Nordic/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
C:/Nordic/zephyrproject/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:40 (include_boilerplate)
CMakeLists.txt:4 (find_package)

---

Thanks for this very thorough description of your setup.
I will try to see if I can reproduce same behavior.

But to just give you a brief history, then the changed behavior for finding Python is due to switching from having a Zephyr specific backport with local patches of FindPythonInterp.
The FindPythonInterp was deprecated with CMake 3.12, and as there were other issues related to Python location that had to be solved, then it was decided to go for the new FindPython3 CMake module, but as you noticed, it has introduced a new behavior, with some unexpected side-effects.

For a quick test, you can try to set the Windows search Python3_FIND_REGISTRY value to LAST.
https://cmake.org/cmake/help/latest/module/FindPython3.html#hints

but you are also welcome to wait till I have investigated on Windows.

On Windows, CMake FindPython3 will default look into Windows registry, so you can take a look to see if all Python versions installed are correctly registered:
[HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\ or
[HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\

[tejlmand]

@mbolivar-nordic Seems we have a use-case for providing Python used by west directly to CMake here.

[AdrianEggenberger]

I did a short try by adding the following line on top of the CMakeLists.txt:
set(Python3_FIND_REGISTRY "LAST")

This worked and fixed the usage of the wrong python instance. It is fine for me as a temporary workaround.

[tejlmand]

I did a short try by adding the following line on top of the CMakeLists.txt:
set(Python3_FIND_REGISTRY "LAST")

This worked and fixed the usage of the wrong python instance. It is fine for me as a temporary workaround.

Great to hear.
Will still be looking into this, and not blindly change the current code, cause I would like to ensure we don't introduce other side effects by such change.