Environment configuration design doc is ready (enough) for review 🙂 This unblocks the Docker project. https://docs.google.com/document/d/1vXRHWK7ZjAIp2BxWLwRYm1QOKDeXx02ONQWvXDloxkg/edit#

thanks: i’m hoping to get https://github.com/pantsbuild/pants/issues/7490 out for review this morning, and then will look

OK. I like modeling environments as targets. I’m concerned about the ability to modify things like search paths for the local environment. On my Mac, for example, I use MacPorts, but most others use Homebrew. So, defining the paths specific to my machine in the open source project’s config is generally not kosher.

~/.BUILD.local

(or

BUILD.private

) would need to be restricted so that it can only define environment targets, and possibly override target config from a path defined in the repo… Those local overrides are messy no matter what format (toml/BUILD) they’re in.

Thanks for taking a look, Jacob. I agree that is the haziest part of targets imo What do you think about this workflow? You define the environment in a BUILD file checked in for everyone, and then override some option in pants.rc to tell Pants to use your

local_environment

rather than what everyone else has by default?

So, pants.rc would override

[environments].aliases.<target>

to point to a locally defined target instead of the in-repo target?

exactly, and you either define that target in a checked in file or in

BUILD.private

I think

[environments.override_values]

sounds more feasible than introducing

BUILD.private

mechanisms — that really does sound like a big can of worms.

if we don't go with targets as the solution, thoughts on options 1 vs 2 vs 3?

3

which is fine for most of our options, including

[python].resolves_to_x

, because there's little duplication across options. Here, it seems very likely to have duplication

So, if that config is close together, it is easier to make sure you update all relevant options at the same time.

@happy-kitchen-89482 do you have thoughts on the modeling?

I don’t have commenting privs

you should be an editor as a pants maintainer. but either way, fixed

Thanks for the doc, this is interesting and nuanced

I nerd sniped myself into staying up till 4 am working on it and in particular https://github.com/pantsbuild/pants/pull/16661 for some gnarly parser.py stuff to derisk the target approach 🙈 every time I closed my eyes, I thought of a new idea lmao

I suggested an “Option 5” there, it’s very half-baked but LMK

In the interest of unblocking the Docker experiment, which this environment mechanism blocks, I propose that we use targets for now. I'm almost done implementing it, whereas • options 3 (a subsystem w/ Plugin Options) and 5 (pants.toml files per env) both require new technology to be invented. • option 2 (subscopes) is vetoed • option 1 (dict options) has less traction than targets I am not trying to strong-arm this. I'll intentionally minimize work on making the target modeling more ergonomic, and instead focus on stuff useful regardless. And then once I'm done unblocking the overall project, and Benjy is back from a trip in a week, we re-evaluate? thoughts @witty-crayon-22786?

i think that target options are the strongest of the presented alternatives.

yeah, note

pants.ci.toml

for example - is that an env, or only extra config? Also forcing you to use TOML to set options violates our core options mechanism w/ --args and env vars

I do like the idea of options being marked as environment specific! Regardless of which of the alternatives we take