Add pants_runtime_python_version global option

[Eric-Arellano]

Problem

As discussed in pantsbuild/setup#30, we decided to add support for using Python 3 to every day user's setup script ./pants by having them pin the interpreter version they want to use in pants.ini, and then grepping that value to choose the relevant interpreter. However, this currently results in this error:

ERROR] Invalid option 'pants_runtime_python_version' under [GLOBAL] in /Users/eric/DocsLocal/code/projects/setup/pants.ini
Exception caught: (<class 'pants.option.config.ConfigValidationError'>)

Exception message: Invalid config entries detected. See log for details on which entries to update or remove.
(Specify --no-verify-config to disable this check.)

Solution

Exactly how we handle --pants-version, introduce a new global option --pants-runtime-python-version that allows users to set pants_runtime_python_version in their pants.ini.

Even though Pants code cannot dynamically change the interpreter it runs with—as it is too late to change the interpreter once the process is already running—we can check that Pants is running with the intended interpreter and print a helpful message if it is not.

You can leave off the option, and you'll get no runtime check. Setup scripts are free to implement Python interpreter resolution in another way if they prefer.

Result

• Including pants_runtime_python_version in pants.ini no longer results in an error.
• Running ./pants --pants-runtime-python-version=2.6 will error out. Running ./pants2 --pants-runtime-python-version=2.7 will work normally.

[Eric-Arellano]

Reviewers: I added so many of you all because I wanted your feedback on the option name pants_engine_python_version. This is going to end up in almost everyone's pants.ini, just as python_version does, so it's important to get right.

Also this option is not going to go away once we drop Py2, as users will still be able to choose between 3.6 vs. 3.7.

The important thing to make sure we're communicating with this option name is that this does not impact the interpreter they use for their own code, e.g. in their tests and other spawned subprocesses. This solely determines what Pants itself uses to run.

--

Please refer to pantsbuild/setup#30 for the plan on how this will all hook up.

[stuhood]

Thanks!

[illicitonion]

Yay time to bikeshed!

My first preference would be --python-version; the pants is implicit.
My second preference would be --pants-python-version, if we're trying to explicitly differentiate from e.g. pytest-python-version. But I'd prefer --python-version :)

I also have a vague question around where we should be using exact versions and where we should be using constraints...

[Eric-Arellano]

To recap, we now have multiple proposals for what to call the global option users will put in their pants.ini to pin the Python version they use to run Pants (not their own code).

• python_version_for_pants
• python_version_for_running_pants
• pants_runtime_python_version
• pants_engine_python_version
• pants_native_python_version
• pants_python_version
• python_version

My main priority is distinguishing between options like python_setup_interpreter_constraints, to make crystal clear this interpreter version is only what Pants uses to run itself and is not what subprocesses like ./pants run and ./pants test will use.

Edit: added Benjy and Borja's proposals.

[benjyw]

Does the word "runtime" help with this emphasis? E.g., pants_runtime_python_version?

[blorente]

I do like the verboseness of that option and I wouldn't be afraid of being overly verbose, since this is a thing that is written down in a config file, not typed in a terminal.

I'm not sure I like the word runtime, because for someone who doesn’t know what runtime means or implies, that word means nothing (and they will have to ask regardless), and for someone who does know, they don’t need the clarification anyway. I speak from my own experience, but mileage my vary.

How about something like python_version_for_pants, or even python_version_for_running_pants?

Love a good bikeshedding session.

[OniOni]

My two cents:
I like:

• pants_engine_python_version
• pants_runtime_python_version
  They're nice and explicit.

[CMLivingston]

+1 for Mathieu's suggestion.

[Eric-Arellano]

Thank you all. We've narrowed it down to:

• pants_engine_python_version
• pants_runtime_python_version

Thoughts on which of the two?

My two cents, I'd be happy with either. I prefer pants_engine_python_version because the word engine suggests to me this is some "under the hood" thing Pants has to have and it's an implementation detail, rather than impacting their own code, whereas pants_runtime_python_version isn't quite as clear to me what runtime refers to (e.g. runtime meaning when you run ./pants test?). Either way, both are good.

[blorente]

I prefer pants_engine_python_version. I can totally imagine myself being confused by it still, but that's as much bikeshedding as I'm willing to do :)

[illicitonion]

I have a pretty strong preference away from engine - we use engine in other places to have a very specific meaning, and it's basically a pants-developer facing term that most users shouldn't never need to know exists.

[OniOni]

I don't have strong feelings either way. But if engine does have a specific meaning in pants, I think that's enough to not use pants_engine_python_version.

So I would vote: pants_runtime_python_version

[cosmicexplorer]

I like pants_runtime_python_version because it doesn't seem like this is purely relevant to the engine, which alone would make me want to use runtime (I would even be ok with pants_python_version if that wasn't itself very ambiguous). I also like the idea of keeping the engine concept more specific. I think pants_runtime_python_version is something users can see and possibly understand immediately even without looking at the help, but engine immediately makes it more mysterious, which doesn't seem like what we'd want for a setup script for someone adding pants to their repo for the first time (for example).

[Eric-Arellano]

It looks like pants_runtime_python_version will work best! Thank you for pitching in everyone! I will make this update and merge after green CI 🎉

[stuhood]

This is using the previous option name.

[Eric-Arellano]

Oof. I thought I had fixed all the instances of this. Will hotfix this as part of #7365. Thanks for the catch!