It’s come up that homebrew now only provides python3. Unless you have a previous homebrew python 2.7, there’s no way to build SMTK without building your own python. (The macos-provided python will not work due to security sandboxing that prevents installing new site packages.) TJ has verified the SMTK/CMB superbuild will not build python on macos.
Going forward, should we
- prioritize getting SMTK/CMB to build using python3?
- try to get the superbuild on macos to build python2?
- forcing everyone to build their own python2?
Note that
is something we might use in the superbuild on all platforms instead of having something Windows-specific. It supports both Python 2 and 3.
Another option is to set the defaults for numpy and matplotlib to be the system ones. I think the system python2 on MacOS works with that configuration.
According to Apple, we should not use the system python. The very bottom of the linked page says:
Developers using Perl, Python, Ruby, or any other scripting languages that ship with OS X, are encouraged to manage their own installations of the language and dependencies in /usr/local/. When distributing programs written with a scripting language, developers are encouraged to bundle the language runtime and any required components into a self-contained binary.
While we might be able to make it work in the build directory, it sounds like installing SMTK’s python modules system-wide would be impossible and perhaps even installing in ~/Library/
is discouraged.
Without input from Ben, I am reluctant to try and make the common superbuild build python on a mac. I have a sinking feeling that there is a long story behind the following two lines:
superbuild/projects/apple/python.cmake:
superbuild_add_project(python
MUST_USE_SYSTEM)
Then again, we can’t freeze the build until we find out why system python is used on OS X. Kindly disregard my last comment!
Over the weekend I did another brew update and see that they now offer brew install python@2
which will probably work for now.