And validation of the transitive constraints, right? Even for Flake8 where it doesn’t consider deps, we need to validate your ICs were not mucked up when considering deps, iiuc?

i think that it’s sufficient to only validate the portion of the graph that you actually expand. so pytest/mypy would validate the full graph that they were about to invoke, other tools would only validate the portion that they loaded. for example, after partitioning, mypy would compute transitive (which it needs to do to run), and then explode if it found something incompatible.

I am not seeing the big deal of having to do this. We already had the backend, and if you’re using mixed ICs you really should be activating it so that you have the 

py-constraints

 goal. I suspect the majority of (at least new) users already have it activated.

it’s not enabled in example-python. and i don’t know why new users would enable it… it’s not required for usage currently.

There’s also benefits beyond performance: you don’t clutter 

./pants help

 with a field that you don’t want your teammates using because your repo should be using uniform ICs

but you are paying the cost of an administrator needing to know the trick to actually enable that field, and for new users to have to discover in order to gain one of the benefits of pants. as an example: would we need a helper in core to suggest enabling that field when someone uses it and is confused about why it doesn’t exist?

because there is no end to the stuff that we could classify as “unnecessary” and put behind options.

…

this might be slippery slope fallacy

i’m instead pointing out that you’re saying it’s black and white and that “unnecessary” features should be behind flags, regardless of their relative cost. i’m suggesting instead that it is a spectrum: each feature has a cost to weigh