well, dang. it looks like converting `Platform`/`E...
# development
w
well, dang. it looks like converting `Platform`/`EnvironmentMatcher` into a parameter in https://github.com/pantsbuild/pants/pull/16682 runs smack into https://github.com/pantsbuild/pants/issues/12934#issuecomment-1049203868: basically, almost all real world
@union
usage now requires an
EnvironmentMatcher
to be part of its interface.
h
basically, almost all real world @union usage now requires an EnvironmentMatcher to be part of its interface.
How come?
w
thinking out loud, but: i’ll either need to adjust the definition of unions to make that explicit, or … hack around it in some way.
h
make what explicit though? I'm not following why unions are a problem
w
the implementation of https://github.com/pantsbuild/pants/pull/12966 was to convert all
@union
usage into queries: so
Get(X, Y(..))
became
QueryRule(X, [Y])
in that example, that means that nothing other than
Y
is in scope for the plugin
h
ahhhh
w
and https://github.com/pantsbuild/pants/pull/16682 wants a new thing to be in scope
…so actually, yea: two options then. 1. adjust all plugin callsites to explicitly re-pass the EnvironmentMatcher like
await Get(Output, {input: Input, env_matcher: EnvironmentMatcher})
2. adjust how
@unions
are declared so that those callsites don’t need to be adjusted
h
We're in sprint mode right now, and #12934 is something we want to design carefully. So I would bias towards the first solution
w
depends which is more expedient probably… both are interface changes to how unions are declared/used… but neither is likely to affect plugin authors, since they don’t declare their own
@unions
(generally)
👍 1