We ran into an issue on a machine which had both Python 3.5 and Python 3.8 installed, and our software selected two different versions in various places. It seems that PythonInterp selected the 3.5 version even though the 3.8 was also there, seeming to prefer 3.5.x "exactly" instead of just "the newest" available.
Find the two versions is a different problem (two or more ways to find python in our CMake logic) that should be handled in a different set of pull requests, but the way the problem presented itself was that our Python code failed during the build of other packages due to the use of "format strings", which were introduced in Python 3.6. So this pull request (and a related one in python_cmake_module: https://github.com/ros2/python_cmake_module/pull/10) just do the bare minimum and update the required version to something we can actually use.
We ran into an issue on a machine which had both Python 3.5 and Python 3.8 installed, and our software selected two different versions in various places. It seems that
PythonInterp
selected the 3.5 version even though the 3.8 was also there, seeming to prefer 3.5.x "exactly" instead of just "the newest" available.Find the two versions is a different problem (two or more ways to find python in our CMake logic) that should be handled in a different set of pull requests, but the way the problem presented itself was that our Python code failed during the build of other packages due to the use of "format strings", which were introduced in Python 3.6. So this pull request (and a related one in
python_cmake_module
: https://github.com/ros2/python_cmake_module/pull/10) just do the bare minimum and update the required version to something we can actually use.