Out of curiosity how many people are using pants on macs vs linux machines? I ran into some issues initially running pants on my personal mac, but I’m not sure how much of that was pants itself vs company code that was linux-specific

there are a fair number of macOS users… possibly a majority (of non-CI usage, at least)

speaking of the default interpreters, what I have ended up setting up for the Pants monorepo is for MacOS

[python-setup]
# Python that is guaranteed to be present on a MacOS device having XCode installed
interpreter_search_paths = ["/usr/bin"]

for Linux CI

[python-setup]
# the Python versions of interest are assumed to be on the $PATH in Linux CI
interpreter_search_paths.add = ["<PATH>"]

but we are somewhat lucky because developers need to have XCode installed so we know they will have Python 3.8 shim.

/usr/bin/python3

 provides a connection to the actual Python interpreter accessible at 

/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8

. This means we can avoid situations when developers have other Python environments (of arbitrary Python versions) that may take priority. Relying on homebrew’s Python is a path I would not suggest taking given how easy things break upon

brew update

. The

pyenv

is nice, but we can’t enforce it for every developer. So the XCode’s Python seemed like a good compromise.

The 

pyenv

 is nice, but we can’t enforce it for every developer.

it’s possible to enforce it by setting your search path such that only pyenv interpreters are used. but yea, it can be extra steps.

yes, exactly. By enforcing I meant telling every developer to install

pyenv

— an external thing is less appealing when you have a built-in XCode’s one 🙂

yes, true. to get that you’d set both an

interpreter_constraint

to match the particular python, and a search path.

thanks, that’s useful!

with the “use system Python”: someone on an older/newer machine will not get your one Python to rule them all

Oh sorry, I wasn’t clear perhaps — it’s not the Python that comes with the Mac, but rather the one that gets installed when one installs XCode. If my research was comprehensive, one is safe on Python 3.8.x with XCode 12. So if you are on XCode 12, which you need to have installed, then you are fine. Once we update the XCode across the whole fleet of machines, then it will be 3.9.x, for instance (but this is something we can control and can happen once a year for instance)

I ran into a few issues when I first set up pants, although I didn’t take careful notes (and some of the problems were company code compatibility issues since everyone else has linux)

@steep-waitress-53641 yep, that’s right. But we are not using system Python, but rather Python that comes after installing XCode 🙂 I have no problems juggling tons of Python interpreters and my Mac and get Pants working, but we can’t expect this from other developers who just want to run their Python script! 😄

Huh, interesting. I thought I had xcode installed but I can’t find it. Apparently you don’t need it if all you run is xcode-select --install. That certainly explains a lot. And definitely agreed about juggling python interpreters. At least I no longer need to support python 2 🙂

@steep-waitress-53641: if your org isn’t ready to manage Python installs on macOS, you can ask Pants to use a particular interpreter search path on your machine, independent of settings in any particular repository, using a

pantsrc

file: i use:

$ cat ~/.pants.rc
[python-setup]
# Avoid system python.
interpreter_search_paths = ["<PYENV>"]

Ah interesting. I’ll make a note of that. I think I’m the only one on Mac, everyone else is on Linux but I anticipate that changing as the company grows

aside from pyenv there's also modules