https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

08/26/2022, 5:22 PM
Environment configuration design doc is ready (enough) for review 🙂 This unblocks the Docker project. https://docs.google.com/document/d/1vXRHWK7ZjAIp2BxWLwRYm1QOKDeXx02ONQWvXDloxkg/edit#
Most important thing for today is if we're able to confirm the data modeling for how environments are defined: options vs targets I'm almost done with the initial implementation of targets and can put it up for review soon
w

witty-crayon-22786

08/26/2022, 5:38 PM
thanks: i’m hoping to get https://github.com/pantsbuild/pants/issues/7490 out for review this morning, and then will look
❤️ 1
p

proud-dentist-22844

08/26/2022, 7:07 PM
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.
👍 1
__local__
is better than
<local>
😄
h

hundreds-father-404

08/26/2022, 7:09 PM
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?
The other workaround I was thinking is if we want an option to allow you to override certain values?
Copy code
[environments.override_values]
my_env = { python_interpreter_search_path = ["foo"] }
Maybe don't open the can of worms of
BUILD.private
? I could see that being a can of worms
p

proud-dentist-22844

08/26/2022, 7:11 PM
So, pants.rc would override
[environments].aliases.<target>
to point to a locally defined target instead of the in-repo target?
👍 1
h

hundreds-father-404

08/26/2022, 7:12 PM
exactly, and you either define that target in a checked in file or in
BUILD.private
p

proud-dentist-22844

08/26/2022, 7:13 PM
I think
[environments.override_values]
sounds more feasible than introducing
BUILD.private
mechanisms — that really does sound like a big can of worms.
👍 1
h

hundreds-father-404

08/26/2022, 7:13 PM
if we don't go with targets as the solution, thoughts on options 1 vs 2 vs 3?
p

proud-dentist-22844

08/26/2022, 7:14 PM
3
consolidate the logic, even if there is some repetition between the options.
👍 1
toml is designed such that it explicitly prefers duplicated config over introducing something like yaml anchors: https://github.com/toml-lang/toml/issues/77#issuecomment-14274593
1
h

hundreds-father-404

08/26/2022, 7:20 PM
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
p

proud-dentist-22844

08/26/2022, 7:21 PM
So, if that config is close together, it is easier to make sure you update all relevant options at the same time.
1
h

hundreds-father-404

08/26/2022, 7:26 PM
@happy-kitchen-89482 do you have thoughts on the modeling?
h

happy-kitchen-89482

08/26/2022, 7:40 PM
I don’t have commenting privs
h

hundreds-father-404

08/26/2022, 7:41 PM
you should be an editor as a pants maintainer. but either way, fixed
h

happy-kitchen-89482

08/26/2022, 7:54 PM
Thanks for the doc, this is interesting and nuanced
❤️ 1
h

hundreds-father-404

08/26/2022, 7:55 PM
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
h

happy-kitchen-89482

08/26/2022, 7:56 PM
I suggested an “Option 5” there, it’s very half-baked but LMK
👍 1
h

hundreds-father-404

08/26/2022, 9:07 PM
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?
w

witty-crayon-22786

08/26/2022, 9:55 PM
i think that target options are the strongest of the presented alternatives.
1
an option 6 (related to options 2 and 5) would be to add native support for marking individual options (rather than entire subsystems as in 2) as environment-specific, and then requiring that they be specified in a separate config file (similar to option 5)
but i think that option 4 is still stronger, because 6 attaches meaning to your config files in a way that isn’t great… you’d need to alias config files, basically
👍 1
h

hundreds-father-404

08/26/2022, 9:59 PM
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
h

happy-kitchen-89482

08/26/2022, 10:34 PM
I do like the idea of options being marked as environment specific! Regardless of which of the alternatives we take