This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

After upgrading from 1.3.0-rc1 to 1.3.0 I get the error ModuleNotFoundError: No module named 'yaml'

Hi,

I'm trying to upgrade nRF Connect SDK from 1.3.0-rc1 to 1.3.0 because I need one of the bugfixes to keep developing.

I'm on macOS catalina and I've used the Toolchain Manager.

Now I get this annoying and apparently well known error message when opening projects:
ModuleNotFoundError: No module named 'yaml'

I can go back out and "Open IDE" for version 1.3.0-rc1 in Toolchain Manager and then it works.

I have fixed my python executable as described in Bjørn's comment at the bottom of this thread.
https://devzone.nordicsemi.com/f/nordic-q-a/62172/thingy91-is-useless-without-working-samples-and-sdk/255301#255301


Best regards,

Jan Erik Foss
BikeFinder





Parents
  • I found that there is a couple of lines at the bottom of python.cmake in the zephyr/cmake folder that cause cmake to search for Python and disregard the directive specified in the nRF Connect application. In my system the python found is 3.8 which is part of the developer command line tools in OS X not version 3.9 which is loaded normally based on the path designation for the shell. Since this is not the python version into which yam was installed it fails.

    To fix this and allow cmake to use the default version of python 'i simply commented these two lines out.


    # find_package(Python3 ${PYTHON_MINIMUM_REQUIRED} REQUIRED ${PYTHON_EXACT})
    # set(PYTHON_EXECUTABLE ${Python3_EXECUTABLE})

    The environment variable, PYTHON_EXECUTABLE, is already set so there is no need to change it.

    Perhaps this should be changed in the distribution for MAC installation.

  • Hi, Ian! Thanks for suggesting this fix. However, note that this will block the user from building on the command line as it leads to erroneous behavior in the west.cmake script. I believe this stems from the command line environment not having PYTHON_EXECUTABLE defined, while SES does have it defined. I believe the best way to mitigate this issue is to ensure that the correct python distribution is used when installing and handling packages.

    We're working hard on providing adequate support for MacOS and Linux so we're thankful for all input!

    Best regards,
    Carl Richard

Reply
  • Hi, Ian! Thanks for suggesting this fix. However, note that this will block the user from building on the command line as it leads to erroneous behavior in the west.cmake script. I believe this stems from the command line environment not having PYTHON_EXECUTABLE defined, while SES does have it defined. I believe the best way to mitigate this issue is to ensure that the correct python distribution is used when installing and handling packages.

    We're working hard on providing adequate support for MacOS and Linux so we're thankful for all input!

    Best regards,
    Carl Richard

Children
  • I understand. I find it odd that anyone would seriously want to use the command line to build a project when there is a perfectly good ide.

    The problem you have with OS X is that it ships with python and you cannot override it easily. Since Seeger has a specific setting to provide the python interpreter it seems odd that this would then be ignored later. Why provide the setting?
    I would set up a definition for the python executable in the shell environment and document that as a requirement for command line compilation. Anyone using command line stuff will be very happy to add that to their shell environment. 
    Another option is simply don’t set the python path in the make file if it is already set. You could even spit out a debug line to say you found an existing value and did not override it. 
Related