chilcote/outset

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

kai-h opened this issue · 9 comments

kai-h commented

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:

Command line developers tools prompt

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 commented

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 commented

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 commented

Frankly, either choice seems perfectly defensible.

chilcote commented

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 commented

maybe use macadmins/python?

chilcote commented

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 commented

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 commented

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

kai-h commented

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

  • 👍1