quaint-telephone-89068
10/26/2022, 5:23 PMBUILD
file evaluation are pinned to the __local__
environment (see #17129), meaning that it will not run in a docker
, or remote
environment. This is accomplished by "masking" the environment at graph and BUILD
file evaluation boundaries, and then explicit injecting the ChosenLocalEnvironmentName
as the current EnvironmentName
.
While that process is enforced (by the masked_type
annotations) and fairly safe, it is not type safe for @rule
authors who might think that they can use the Platform
or EnvironmentVars
during BUILD
file evaluation time or dependency inference. Because they can access those types in those locations, but they will not get the appropriate values to use at runtime: they will instead get the values for the __local__
environment.
If you know that, then you can manually avoid consuming environment-specific types in those @rules
, and defer the work to, say, codegen (as @thejcannon demonstrates here), but making this type safe instead would definitely be preferable.
* * *
One way to help guide users would be to overload all of the environment-aware intrinsics (Process
running, Platform
calculation, EnvironmentVars
calculation, etc) to consume _either_:
• an EnvironmentName
(as they do today in 2.15.x
), representing the runtime environment of a target
• a type specific to build graph evaluation, or explicitly for the local environment, maybe called LocalEnvironmentName
or BuildGraphEnvironmentName
.
The latter type would be available to @rules
which were part of BUILD
file evaluation and dependency calculation, while the former type would be available to codegen and etc. This would bifurcate @rules
by type, and maybe help to guide @rule authors to avoid consuming the "wrong" Platform
. But because dependency inference still needs to be able to run processes, it would not represent true type safety.
pantsbuild/pants