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

"west -V" issues "bad interpreter" error immediately after west installation on macOS Big Sur

Kind folks,

Attempting to install the Nordic Connect SDK again after failing several times before. (Always seem to have something slightly wrong in my installation which causes problems later.). So going carefully through the manual installation instructions here, which leads to Step 3 on the Zephyr page for installing west, which appears to succeed:

% pip3 install west
Collecting west
  Using cached west-0.9.0-py3-none-any.whl (79 kB)
Requirement already satisfied: setuptools in /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages (from west) (49.2.1)
...
Installing collected packages: west
Successfully installed west-0.9.0
%

But when I immediately double-check the version of west, I get:

% west -V
zsh: /usr/local/bin/west: bad interpreter: /usr/local/opt/[email protected]/bin/python3.9: no such file or directory
West version: v0.9.0
%

Note that this is on a MacBook Pro running macOS Big Sur, which has Python 2.8 and 3.8 installed by default and in the protected system image, so they can't be removed.  I have installed Python 3.9.2, but it's found in /usr/local/bin, not /usr/bin (which is in the protected system area). This has caused my lots of grief before with various Python tools, has driven me to careful use of Python virtual environments, and to be suspicious of related issues (e.g., Python use in west).  

Does the west error message shown above portend future problems with the tool?

For possible help in deciphering this problem, here are a couple probes into my Python installation:

% python3 -V
Python 3.9.2
% where python3
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
/usr/local/bin/python3
/usr/bin/python3
% /usr/bin/python3 -V
Python 3.8.2
% /usr/local/bin/python3 -V
Python 3.9.2
% ls -al /usr/local/opt/[email protected]/bin/p*       
zsh: no matches found: /usr/local/opt/[email protected]/bin/p*
% ls -al /usr/local/opt/python*          
lrwxr-xr-x  1 mike  admin  26 Feb 21 13:50 /usr/local/opt/python@3 -> ../Cellar/[email protected]/3.9.2
% 

Is this west error significant?  Could it be causing problems later?  How to correct it?

TIA,

Mike

Parents
  • Hi Mike,

    Are you planning on using command line and west to build and flash samples, or SES? Are you able to use other west commands successfully, such as west update and building and programming with west (west build -b build_target and west flash)?

    For installing nRF Connect SDK I would recommend following the guide found here instead of the one in your first link, as this is the official documentation for NCS. You should only need to do step 2 "Install dependencies" in Zephyr's getting started guide, installing Homebrew and using brew to install dependencies. After that you should follow the guide in the NCS documentation again. Another option is to install it using the Toolchain manager, as explained here. The documentation states that Toolchain manager is only for Windows, but it works on macOS as well.

    Best regards,

    Marte

  • Marte,

    Thanks for the quick feedback.

    I plan to use both command line and and SES, more often the latter.

    I've discovered the problem that was creating the west error msg.  Your Getting Started instructions specify installing python3 with brew. But if python3 is already installed, as it is on a stock macOS Big Sur machine (version 3.8 in that case) or by the user (an additional 3.9.2 version, by me), then there is a valid python3 already but the link to it might not be the specific one where west is looking (i.e., in /usr/local/opt/...)

    If I do an additional python 3 installation, specifically using brew, as in "brew install python3", then this new copy will have a link at the specific path at which west is looking for it.

    I did that and that eliminated the error message which I was getting every time west was invoked.

    SUGGESTION: West should be more robust in how it locates the version of python3 it's using.

    BIGGER PROBLEM: Having solved this problem, I get further, but only to confront a bigger Python version problem I've seen before, when trying to setup SES to "Open an nRF Connect SDK Project...".  I believe I have the correct settings in the Tools | Options | nRF Connect pane (specifically the Python Executable setting for my 3.9.2 installation), but when I go through the "nRF Connect Options" window and click OK, I get an error (as shown in the console output):

    Creating solution peripheral_lbs.emProject
      /usr/local/bin/cmake -GNinja -DBOARD=nrf52840dongle_nrf52840 -DBOARD_DIR=/Users/mike/ncs/zephyr/boards/arm/nrf52840dongle_nrf52840 -B/Users/mike/ncs/nrf/samples/bluetooth/peripheral_lbs/build_nrf52840dongle_nrf52840 -S/Users/mike/ncs/nrf/samples/bluetooth/peripheral_lbs -DZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb -DGNUARMEMB_TOOLCHAIN_PATH=/Users/mike/gnuarmemb -DPYTHON_EXECUTABLE=/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 -DCMAKE_MAKE_PROGRAM=/usr/local/bin/ninja -DDTC=/usr/local/bin/dtc -D WEST=/Library/Frameworks/Python.framework/Versions/3.9/bin/west -DEXTRA_KCONFIG_TARGETS=menuconfig_ses -DEXTRA_KCONFIG_TARGET_COMMAND_FOR_menuconfig_ses=/Applications/SEGGER_SES/html/configure_nordic_project_menuconfig.py
      -- Application: /Users/mike/ncs/nrf/samples/bluetooth/peripheral_lbs
      -- Zephyr version: 2.4.99 (/Users/mike/ncs/zephyr)
      -- Found Python3: /usr/bin/python3 (found suitable exact version "3.8.2") found components: Interpreter 
      -- Board: nrf52840dongle_nrf52840
      -- Cache files will be written to: /Users/mike/Library/Caches/zephyr
      -- Found dtc: /usr/local/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
      -- Found toolchain: gnuarmemb (/Users/mike/gnuarmemb)
      -- Found BOARD.dts: /Users/mike/ncs/zephyr/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840.dts
      -- Configuring incomplete, errors occurred!
      Including boilerplate (Zephyr base): /Users/mike/ncs/zephyr/cmake/app/boilerplate.cmake
      Traceback (most recent call last):
        File "/Users/mike/ncs/zephyr/scripts/dts/gen_defines.py", line 30, in <module>
          import edtlib
        File "/Users/mike/ncs/zephyr/scripts/dts/edtlib.py", line 75, in <module>
          import yaml
      ModuleNotFoundError: No module named 'yaml'
      CMake Error at /Users/mike/ncs/zephyr/cmake/dts.cmake:229 (message):
        gen_defines.py failed with return code: 1
      Call Stack (most recent call first):
        /Users/mike/ncs/zephyr/cmake/app/boilerplate.cmake:533 (include)
        /Users/mike/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:24 (include)
        /Users/mike/ncs/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:35 (include_boilerplate)
        CMakeLists.txt:8 (find_package)
      
      
      
      error: cmake failed
      create_nordic_project.py failed (1)

    Note line 5 of this console output.  CMake insists on using Python 3.8.2, the default python3 on macOS Big Sur, rather than my 3.9 version and, therefore, is missing required module (e.g., yaml in this specific case.)

    I believe this problem will be encountered by all macOS Catalina and Big Sur users (where Python 3.8 is installed in the read/only system) until this problem is fixed.

    Please let me know if you need any additional diagnostic information.  Would love to see this problem fixed.

    Thanks,

    Mike

  • Hi Mike,

    We are aware of problems with Python on macOS, and that the problem is often caused because of the different Python installations. We are working on fixing and improving this. If you open the file <ncs_installation>/zephyr/cmake/python.cmake you can see that it looks for a Python installation that satisfies the requirements, and it seems like the first one it finds is the Python 3.8.2 in /usr/bin/python3, instead of the one installed with brew.

    Could you please try the solutions proposed by IanAber here? I have copied them here as well:

    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.

    You can also try to specify the path to the west tool as additional CMake option in SES. This can be done when you open a nRF Connect SDK Project by selecting Extended Settings and adding the additional options to Extra CMake Build Options, or by going to Tools Options nRF Connect and adding it to additional CMake options there. Set the following, where path_to_west is the path to your west installation:

    -DWEST=path_to_west

    Did you install the additional Python dependencies? Open a terminal window in the ncs folder and enter the following commands:

    pip3 install -r zephyr/scripts/requirements.txt
    pip3 install -r nrf/scripts/requirements.txt
    pip3 install -r bootloader/mcuboot/scripts/requirements.txt

    Installing NCS through the Toolchain manager is also an option, as I stated in my last reply.

    Best regards,

    Marte

Reply
  • Hi Mike,

    We are aware of problems with Python on macOS, and that the problem is often caused because of the different Python installations. We are working on fixing and improving this. If you open the file <ncs_installation>/zephyr/cmake/python.cmake you can see that it looks for a Python installation that satisfies the requirements, and it seems like the first one it finds is the Python 3.8.2 in /usr/bin/python3, instead of the one installed with brew.

    Could you please try the solutions proposed by IanAber here? I have copied them here as well:

    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.

    You can also try to specify the path to the west tool as additional CMake option in SES. This can be done when you open a nRF Connect SDK Project by selecting Extended Settings and adding the additional options to Extra CMake Build Options, or by going to Tools Options nRF Connect and adding it to additional CMake options there. Set the following, where path_to_west is the path to your west installation:

    -DWEST=path_to_west

    Did you install the additional Python dependencies? Open a terminal window in the ncs folder and enter the following commands:

    pip3 install -r zephyr/scripts/requirements.txt
    pip3 install -r nrf/scripts/requirements.txt
    pip3 install -r bootloader/mcuboot/scripts/requirements.txt

    Installing NCS through the Toolchain manager is also an option, as I stated in my last reply.

    Best regards,

    Marte

Children
No Data
Related