just opened <https://github.com/pantsbuild/pants/i...
# development
w
just opened https://github.com/pantsbuild/pants/issues/17354 to help describe a pitfall around where
EnvironmentNames
are consumed that will likely need to be present in 2.15.x at this point, but that we could maybe fix in 2.16.x.
@ancient-vegetable-10556: this maybe helps to crystallize the very valid concern you had with introducing the
EnvironmentName
in more places.
@curved-television-6568: relates to the
EnvironmentName
question you had above… this wouldn’t do anything about rule graph errors: sigh, sorry. but it might help to explain which
@unions
should be able to consume an
EnvironmentName
, and which shouldn’t.
🙏 1
@bitter-ability-32190: relates to https://github.com/pantsbuild/pants/pull/17334, as mentioned there
a
@witty-crayon-22786 glad you could join me, the water’s wonderful 😉
b
drowning
😂 1
☝️ 1
a
@witty-crayon-22786 I think this may be where we need to start formalising the phases that Pants goes through and explain that all a bit better
1
w
yea. although it is a bit funky because rather than “phases”, per-se, it’s more like “chunks of the rule graph”. for example, it would be totally fine for codegen (running in a
remote
or
docker
environment) to call back to the BUILD file parsing rules (which would switch back to a local environment to run)
c
Stu: My only concern with that exact syntax is that
per_platform
looks like it can be used in other positions
This had me thinking if it would be possible/desirable to have platform specific BUILD files (or “sections” within i build file) so you define the whole target per platform (possibly with a common version and only the platform specific overrides in another…). maybe crazy idea..
w
so still not exactly like bazel’s phases, where the phase ends and you’re done
c
So, perhaps have different rule decorators for the various roles,
@local_rule
@runtime_rule
etc…
w
This had me thinking if it would be possible/desirable to have platform specific BUILD files (or “sections” within i build file) so you define the whole target per platform (possibly with a common version and only the platform specific overrides in another…). maybe crazy idea.
possibly… but as it stands, that would mean different build graphs / dependencies per platform, which pinning the graph to a single platform prevents currently… somewhat/mostly intentionally.
b
I had that idea too, but thought better of it so I can sleep at night 🙂
😅 1
w
@curved-television-6568: it also gets into the domain of https://github.com/pantsbuild/pants/issues/11206 … because these “manually declared `dependencies`” which the
graph
@rules
compute are still manual, and are unlikely to be the fully accurate final dependencies of running a process
👍 1
which pinning the graph to a single platform prevents currently… somewhat/mostly intentionally.
…oh my… this isn’t actually true. you could still have different dependencies on linux vs macOS because the
__local__
environment changes. that’s … annoying.
🫢 1
the “type safety” of https://github.com/pantsbuild/pants/issues/17354 could still only really act as a reminder to avoid doing platform-specific things … oof. because dependency inference needs to be able to run processes.
2
whelp. not sure if that ended up clarifying things… this will definitely need to be an area of exploration before stabilizing
environments
!
b
Glad I could muddy the water 🙂
1