Kind folks,
The more things change, the more they stay the same 
. At lest it seems that way. I submitted a similar message seven months ago. I see a recent spate of related messages from other Mac users having nRF Connect installation issues. Here's my current assessment of the situation with the automatic installation process:
- I tried using the latest update of the nRF Connect app v3.7.1 using the Toolchain Manager v0.9.4 plugin, clicking on nRF Connect SDK v1.7.0 "Install". This process downloaded the SDK and toolchain files but then halted, without installing the toolchain (e.g., the SEGGER Embedded Studio app).
- (Documentation note: At this point, the "Install" has changed to "First steps to build". If you single click on this field, it opens a page of instructions for using SES. Wrong move! it appears that the proper course of action is to click on the downward-pointing triangle to the right, which acts like a 5 element selection, which in fact isn't a selector, but apparently an indication of the five steps to necessary to "get ready" to build with SES. Very bad UI, ambiguous and misleading!! Would hope your UI designers could come up with something better.
- In any case, on my system, I can contrive to install SES so that the app can be launched in normal mcOS fashion.
- Somewhere in this chain, I got a "CMake not installed" popup. No sweat. Took care of that with brew.
- But this process eventually fails, during the toolchain update process, with the following error popup:
Gave up on the automatic installation process and went over to your webpage for manual installation of SDK v1.7.0:
- Turns out this was essentially a repeat of of my experience of seven months ago (reported in the message linked above) ending in problems with west issues.
Core Issue: Python version management on macOS
I have come to the conclusion that all of these problems (as well as many of those reported by other Mac users) are due to problematic issues with Python versions on recent macOS versions up through Big Sur (and probably Monterey). Here are several issues and questions related to this issue:
- Recent macOS releases have come with Python 2.7 and Python 3.6 versions preinstalled and linked to "python" and "python3" respectively. These installed binaries are in a Read Only section of the system and cannot be changed.
- Additional versions can be installed, but various tricks need to be employed to get them to be used instead of the pre-installed versions
- In particular, virtual Python environments can be setup using the venv tool for Python or the more general asdf tool.
- But this can be problematic if we can't ensure that the same virtual environment is used by both from both the command line and by script handling internal to your code.
So as a step toward solving my and other Mac users' problems with SDK v1.7.0 installation, both automatic and manual, can you please provide us with the following information (which I haven't found in any of your documentation):
- The exact Mac configuration used by your developers to test and qualify SDK v1.7.0 installation, both automatic and manual:
- Machine type: e.g., MacBook Pro 10,1 (probably not critical, earliest and latest machine types would be informative)
- macOSmacOS versions used: earliest and latest
- Exact software configuration on test Macs prior to SDK v1.7.0 installation, both automatic and manual, especially with regard to:
- Python installations
- Virtual environment tools and their use
- Any Linux (via brew) or Python packages (via pip) installed and not mentioned in your pre-requisites
- Any suggestions you have for qualification tests that can be used after each substantial step (in the manual installation) to validate proper completion of the prior step.
Note: As a former software development manager of a dozen person team, part of a 150 person engineering group that develops software that runs on the vast majority of PCs, Macs and Linux machines in the world, I appreciate the difficulty your team has. It's very difficult to anticipate what environments will be encountered by your software, especially automated installation tools. (Sometimes you even have to start with a clean out-of-the-box machines.) If you can get me answers to the above questions and, better yet, setup a channel for communication with your macOS team, I'll be happy to contribute effort on macOS testing and UI design.
Hoping we can get the installation and use of your software on Macs at least as smooth and easy as the Windows version.
TIA,
Mike
