it’s not enabled in example-python

Because example-python uses a single constraint for the whole repo. It used to show Py2 vs Py3 partitioning, but we decided it was too niche of a feature and was distracting w/ how much we already have in the repo

and i don’t know why new users would enable it…

Because they read https://www.pantsbuild.org/docs/python-interpreter-compatibility, saw the section "Using multiple Python versions in the same project" and decided it's relevant to them, so followed the instructions to activate the backend That flow feels pretty similar to how one decides to activate Protobuf, a particular linter, etc. It sounds like those backends feel different than this functionality though. I'm trying to understand your thinking - what makes mixed ICs (e.g. partitioning) seem more core than these other things?

it’s not required for usage currently.

Right, but my points are a) most people don't use or need it, and b) this is why we have the deprecation

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.

I don't totally follow that: this is how all of Pants v2 is. Everything is opt-in minus project introspection and

count-loc

(Ack that we should continue to improve discovery of backends, like a

./pants help backends

, for sure)

i’m instead pointing out that you’re saying it’s black and white and that “unnecessary” features should be behind flags

Ah, to try to clarify: by "unnecessary" I am strictly talking about the performance impact being unnecessary, regardless of how much we optimize. Ik I brought up downsides of

./pants help

being cluttered: I do think that's true and valuable, but yeah, probably that alone is not sufficient to justify the change We have a lot of features that folks might not use thanks to sensible defaults, like pex's

zip_safe

field. Of course, I agree that should not be feature gated. But also evaluating that field is so trivial performance wise it's irrelevant In contrast, mixed ICs will always have some fundamental perf cost. I mostly buy your idea about how we can make partitioning a lot faster by only looking at roots. (I have questions on how to perform the validation statically and that perf hit, but can punt.) Perhaps it optimizes to the point that the perf hit is close to negligible Even if we solve partitioning enough, there still is a fundamental perf hit to determining the ICs for tool lockfiles like Flake8. Rather than looking at as single option, we must consult the entire repo to look at ICs. That's unnecessary invalidation and scanning of the repo, done every time you use Flake8 because of the upcoming lockfile invalidation