https://pantsbuild.org/ logo
Join Slack
Powered by
is dependency inference environment-aware?
# development
f
is dependency inference environment-aware?
c
…yes ..?
https://github.com/pantsbuild/pants/blob/main/src/python/pants/engine/target.py#L2635-L2637
Copy code
@union(in_scope_types=[EnvironmentName])
@dataclass(frozen=True)
class InferDependenciesRequest(Generic[FS], EngineAwareParameter):
based on the 
in_scope_types=[EnvironmentName]
..
f
but if a set of targets had to be seen differently in one environment versus another, would those targets have to be parametrized on 
environment
?
context: I'm trying to solve https://github.com/pantsbuild/pants/issues/18114 re dealing with conditional compilation per environment affecting deps for Go SDK packages
and certain packages are only in use on Linux and not macOS and so target generation does not even see those packages when running 
go list
which makes me wonder if I should go ahead and introduce an explicit 
go_sdk
target type with an 
environment
field
I guess my question is really about target generation and environments
c
heh… yea my mind 🤯 a bit through all of that 😅
w
no, inference is not environment aware: see the yellow note in https://www.pantsbuild.org/v2.15/docs/environments#consuming-environments
essentially, we punted on the problem of determining which environments are compatible with which other environments (unlike resolves, where it is equality), and so users are on their own for now with regard to mixing environments in a graph
f
for clarity, the goal is not to mix environments in the same build graph but make sure that Go SDK lookups for target generation happen in the environment that builds will also occur in
so seems like the original idea of a single 
_go_sdk
synthetic target is too naive and that it will need to be a 
go_sdk
per environment
and so making the target type explicit and visible to the user is probably the better approach for now
w
hm, not sure about that. does the 
_go_sdk
target consume the environment while it is generated?
…oh. hm. yes, it would, wouldn’t it. because that is not a private/downloaded toolchain, but rather one sourced from environment variables.
yea, this steps in https://github.com/pantsbuild/pants/issues/17354 , unfortunately.
f
the issue is more that 
_go_sdk
synthetic target is a target generator and consumes the local environment (say, macOS local env) and makes certain 
_go_sdk_package
targets appropriate to that macOS local env
w
yea.
f
then user specifies that want to build in a docker env linux
and certain SDK packages only exist on Linux due to conditional compilation
but the target generator wouldn't have known about them so boom
w
yea, this is tricky. part of the thinking on that issue is that we don’t want to generate different targets on different machines
but… it’s also just non-obvious what to do in this case, so.
f
eventually I could see Pants supporting multiple 
go_sdk
targets
(especially if Pants managed downloads of Go SDK so they could be different versions)
and they would be specific in an environment so would carry an 
environment
field
w
maybe. if we downloaded them, the targets themselves would be environment agnostic, i would think. or wouldn’t need to be modeled as targets at all.
f
yeah not modellng as targets could be alternative
which we already do that with the "naive" package build rules used to build the helper binaries
👍 1
3 Views
Open in Slack
PreviousNext
Powered by