https://pantsbuild.org/ logo
Join Slack
Powered by
Re execution environment options: trying to work o...
# development
a
Re execution environment options: trying to work out what to call the flag on 
_OptionBase
(thread to come)
Currently the flag is called 
environment_sensitive
, which is apparently a bit ambiguous compared to environment variables. I didn’t like the proposed alternative of 
environment_specific
for similar reasons. Options I could like are: • 
overridable_by_environment
• 
from_environment_target
• 
supports_environment_target
• 
environment_target_field
<--- (my preference) 
environment_target_field
makes it clear-ish that there’s relevance to 
environment_target
, and that it would generate a 
Field
. Thought, @hundreds-father-404 @witty-crayon-22786?
w
i still think 
environment_specific
is sufficient. anything that mentions targets is too implementation specific. i expect that we are mostly not going to “teach” environments via the targets… end users of environments will set 
python_tests(..., environment=..)
, and not worry about whether it’s a target or not.
likewise, our docs should link* to a page that explains environments, of which environment targets will be one component
a
I think that 
environment_specific
makes it seem like the only choice for setting the option is through the 
environment
, which is potentially confusing
which is why I swapped to using 
sensitive
. I realised I was confusing myself as I was documenting the thing
w
i would invert that explanation and say that “they are always specific to an environment, but when no environments are defined, the default environment consumes options”
👍 1
“sensitive” / “specific” is a nit though. i* don’t care too much.
a
OK, I think I’m going to leave it as is then
h
I continue to prefer 
environment_target_field
or 
supports_environment_target
, but I'm not blocking
Open in Slack
PreviousNext
Powered by