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

ancient-vegetable-10556

09/23/2022, 7:02 PM
@witty-crayon-22786 @hundreds-father-404 In the Environment Redesign doc, there’s a few instances of fields on targets that look like those fields are going to be environment-sensitive. Do we have a design for such a thing yet?
(I’d be happy to straw-man one if not, but those are specific items that are blocked, unless we decide they’re out of scope for now)
w

witty-crayon-22786

09/23/2022, 7:03 PM
which ones are you thinking of? we briefly discussed test extra env fields, but came to the conclusion that those would be test specific rather than environment specific. and that someone could parametrize if need be
a

ancient-vegetable-10556

09/23/2022, 7:06 PM
test_env_vars
is one of them, there’s also
experimental_shell_command
and
python_distribution
which both have
env_vars
settings
h

hundreds-father-404

09/23/2022, 7:17 PM
For it to work, we need either for the environment target to take a dictionary of targets -> values, or for the consuming targets like python_test to have a dictionary of environments -> values. I'd bias much more towards it living on each relevant target, like python_test, so it stays decentralized I'm skeptical we need that, as Stu says, at least for now. Maybe in the future we get clever and let those fields either be StringListOption (current), or DictOption, depending on how much precision you need. It might be worth creating a ticket so that users can let us know if they need the mechanism?
a

ancient-vegetable-10556

09/23/2022, 7:19 PM
Yeah, the latter of the two designs, where you define based on environment matchers made a lot of sense to me
👍 1
w

witty-crayon-22786

09/23/2022, 8:02 PM
“env_vars to use when invoking a PEP-517 build backend” seems like something that could be migrated off to a subsystem (assuming that the use case is for things like setting up paths to find libraries, etc)
as opposed to anything that is necessarily specific to that python_distribution
a

ancient-vegetable-10556

09/23/2022, 8:03 PM
the vast majority of subsystems already have such options in their subsystems; AIUI, these are all for specific targets
w

witty-crayon-22786

09/23/2022, 8:03 PM
@ancient-vegetable-10556:
test
has both: part of the reason for that is some options are endemic to the machine you’re on, and some are for a particular test
a

ancient-vegetable-10556

09/23/2022, 8:04 PM
Right, and
experimental_shell_command
needs it because subsystems would make absolutely no sense there
w

witty-crayon-22786

09/23/2022, 8:05 PM
yea, that one is more interesting. we don’t really have any data on how that one is being used.
one bit of prior art here though is bazel’s
select
builtin:
Copy code
compiler = select({
        ":on_linux": "//bar_tools:barc_linux",
        ":on_windows": "//bar_tools:barc_windows",
    }),
a

ancient-vegetable-10556

09/23/2022, 8:06 PM
yup
w

witty-crayon-22786

09/23/2022, 8:06 PM
would involve evaluating the entire BUILD file in the relevant environment though, which is not ideal
a

ancient-vegetable-10556

09/23/2022, 8:06 PM
we probably don’t need to do something like that, since we already have environment matching primitives
either way, seems like we don’t need an answer presently
w

witty-crayon-22786

09/23/2022, 8:07 PM
agreed.
a

ancient-vegetable-10556

09/23/2022, 8:08 PM
New question thread coming up 🙂