Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

probably easier to just detect if there’s a tty and then conditionally emit directly to the std descriptors tho, at least initially

<@U054MQUPL>: <@U06A03HV1> do you have any thoughts about the root subject type restriction problem?
naively I could just change the condition in the root generator to do isinstance checks rather than   exact type matches. But it feels a little icky to me to depend on subclassing for this.

We could make the root type restrictions configurable, but I’m not sure that’s necessary at this point. It would make certain types of tests easier though, because it would allow testing the scheduler without having addresses backing the subjects

this is BuildFileAddress vs Address, yea?

<@U066LC126>: a few times i've just worked around it quickly by switching to an `isinstance` check. but i think that `changed` uses BuildFileAddress at a deeper level

Yeah, I worked around it by commenting out the else

as in, it might expect to get them back as well

so, it might be good to look holistically at the changed impl, and see why it is that it is using BFA

how does the legacy engine interface with the address mapper?

I think that’s the important bit. Changed uses the address mapper to override the target roots

my guess is that that causes it to bypass something

my understanding is that since it doesn't take targets to start with, it doesn't initially parse any BUILD files

so no parsing will happen in the daemon (EDIT: daemon) with changed

./pants changed doesn’t use the ChangedTargetTask base class

that’s probably going to be interesting too

<@U066LC126>: hm, weird. seems like it could probably...

So, I think the underlying issue is that the new build graph assumes it is responsible for all parsing, but the change file task mixin goes behind its back and parses BUILD files itself

via the SourceMapper, which uses the address mapper

Can we make a facade of the context.address_mapper that hits the engine?

<@U066LC126>: i think the important consideration is: how _should_ the changed tasks accomplish their work in the context of the engine and daemon