• State Verified Answer
  • +2 person also asked this people also asked this
  • Replies 21 replies
  • Answers 1 answer
  • Subscribers 69 subscribers
  • Views 6574 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 251634
Options
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'

Jan Erik

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
  • 0

    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.

  • 0 in reply to IanAber

    I ran into another issue that was not resolved by editing the python.cmake. I was unable to change the project configuration because it was also using the wrong version of Python. I did a little more digging.

    The fundamental problem here is that if you execute Segger Embedded Studio from spotlight or finder it does NOT use the path environment variable defined for whatever shell you use in Terminal. OS X Catalina on the Mac now uses zsh so when using terminal you get the path as defined in ~/.zprofile. OS X comes with an installation of Python in the /usr/bin folder but this is actually Python3.8 whereas following the instructions in the Nordic getting started guide results in a home brew installation of Python3.9. Python3.9 is found first on the path when executing from a zsh shell but when executing from a finder or spotlight launched GUI app the first location on the path is /usr/bin and this results in Python3.8 being found by the find_package command in cmake.

    There appear to be two ways to solve this problem.

    1. If you do not want ot mess with the path settings for all GUI applications you can simply launch Segger Embedded Studio from a terminal shell. e.g.  Open Terminal and enter (including the double quotes) "/Applications/arm_segger_embedded_studio_v520b_macos_x64_nordic/SEGGER Embedded Studio for ARM 5.20b.app/Contents/MacOS/emStudio"

    2. You can set the GUI path by executing this command from a terminal session.
    sudo launchctl config user path /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin.
    This will place the home brew managed executables ahead of the built in path and cause GUI launched applications to pick up the correct version of Python. You will need to reboot to get this to take effect.

  • 0 in reply to IanAber

    Sorry but I did both and I keep having this issue. I'm switching to windows now but would be grate if this could be fixed. :)

Reply Children
Related

core_v2_widget.Hide()