https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> <@UB2J9BQA0> In the Environment Redes...
# development
a
@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
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
test_env_vars
is one of them, there’s also 
experimental_shell_command
and 
python_distribution
which both have 
env_vars
settings
h
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
Yeah, the latter of the two designs, where you define based on environment matchers made a lot of sense to me
👍 1
w
“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
the vast majority of subsystems already have such options in their subsystems; AIUI, these are all for specific targets
w
@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
Right, and 
experimental_shell_command
needs it because subsystems would make absolutely no sense there
w
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
yup
w
would involve evaluating the entire BUILD file in the relevant environment though, which is not ideal
a
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
agreed.
a
New question thread coming up 🙂
Open in Slack
PreviousNext
Powered by