Outset doesn't play nice with Python 3 installed via the package from python.org

[kai-h]

In setting up some brand-new macOS Catalina machines, with Catalina 15.5.5, I have installed Python 3 from the package at python.org (currently 3.8.3) which installs python in /usr/local/bin/python3 Then I installed Outset 3.0.0.

After rebooting, or logging out and logging in again, macOS brings up the window prompting me to install the command-line developer tools:

If I open Terminal and type "which python3" I get /usr/local/bin/python and when I run python3 --version it tells me that it's Python 3.8.3

[gregneagle]

which python3 tells you your PATH, not the PATH outset uses, which is running as root and started via a launchd job (so it's not likely to get any adjustments to PATH included in various shell init files)

The behavior you note implies that either /usr/local/bin is not in the PATH, or is after /usr/bin.

You might experiment with adding an EnvironmentVariables dictionary to the launchd plists for Outset, IOW adding something like:

<key>EnvironmentVariables</key>
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>

[kai-h]

Thank you Greg, as always your advice is timely and straight to the point. In order to work around this, I had initially modified the shebang line of the script to point directly to /usr/local/bin/python but your solution is a better fix.

I did try escalating myself to root via "sudo su -" and checked the environment variables there, however it must have been inheriting the path from my user profile.

[gregneagle]

Frankly, either choice seems perfectly defensible.

[chilcote]

Using env is probably a terrible idea, amongst a selection of possible terrible ideas. Of all the terrible ideas, maybe using a symlink to /usr/local/outset/symlink_your_python_here is the least terrible? But even that surfaces the problem of “how do you configure that symlink?” Maybe we need an outset for outset?

[erikng]

maybe use macadmins/python?

[chilcote]

Well it doesn’t require pyobjc and works with python.org and the one that CL Tools installs. I’d rather not force yet-another-python as a dependency. But they are more than welcome to use that python bundle!

[kai-h]

Using env is probably a terrible idea, amongst a selection of possible terrible ideas. Of all the terrible ideas, maybe using a symlink to /usr/local/outset/symlink_your_python_here is the least terrible? But even that surfaces the problem of “how do you configure that symlink?” Maybe we need an outset for outset?

Could a search for a working python3 binary be performed as part of a postinstall script for Outset, that then creates /usr/local/outset/python3 as a symlink to the currently installed version of Python 3? You wouldn't need to search the entire drive, just check the common places for where Python 3 usually lives - /usr/bin, /usr/local/bin or /Library/ManagedFrameworks/Python3.framework/Versions/Current/bin/

Although, if you're going to the trouble of finding a working python3, why make the symlink in the first place and why not just have the postinstall put the path to a working python in the shebang line at the top of the script, or as Greg suggested, add it to the path in the launchd plists?

[chilcote]

See if the latest commit on this branch suits your needs: https://github.com/chilcote/outset/tree/pythons

[kai-h]

Thank you, Joseph. That change in the post install script looks perfect. I will update my munki repository with this new version straight away.