[Do not merge] dogfood local environments for pantsbuild/pants #17043
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A common desire is to not use system Python interpreters on macOS because they tend to be broken. However, in CI, we do need to use those rather than Pyenv.
This PR demonstrates how to do that by defining 2 local_environment targets for macOS, and then overriding what the env name
macos
refers to in CI. It's necessary to overridenames
like this to avoid Pants erroring that there is ambiguity with what__local__
refers to because >1 target setscompatible_platforms
to the same values for macOS.How to change the env values locally
If a user does not like what
//:macos_local_env
is set to, then they would need to override[environments].names
, similar topants.ci.toml
.If they cannot use
//:macos_ci_env
, then this implies they would need to define a new target inBUILD
with their configuration, but not give it a name insidepants.toml
so that it's ignored by default. That's a bummer in that it's harder to change than before, as they need to check in their change toBUILD
. If this becomes a problem, we could explore:[environments]
to let people override the value of a particular environment.BUILD.rc
. We could ban this being anything more than environment targets.Future direction: more predicates
We could avoid needing to override the
names
option if we had better predicates, like "use this environment only if PYENV is defined", because it would mean we don't have ambiguity anymore. Even with 2 macOS environments, only one would match each predicate.Rejected idea:
local_override
optionWe could let the user tell us what
__local__
resolves to via an option. That would allow the user to define both macOS local_environment targets while avoiding ambiguity.However, this does not work out well. It requires that the local_override always be set to avoid ambiguity. But there is no way to set that value safely in
pants.toml
because we don't know the platform of who will be running Pants. For example, this option would break any Linux users:So, we could avoid that by using an option like
platforms_to_local_override
:That works well! But, it falls apart when we add future predicates like making by OS name (e.g.
centos
), because we would need to consider every single predicate in the option.Only a demo
We do not actually merge this PR because the risk that a pantsbuild/pants developer doesn't have Pyenv is too high. For example, they could be using Homebrew, which would show up via
<PATH>
. We don't want to break them.[ci skip-rust]