Okay, glad we're on the same page with what this change would entail. I feel strongly from my experience w/ Py3 migrations that it's imperative you are able to set your ICs only based on the code itself's compatibility, rather than needing to consider all transitive deps—and then Pants will ensure the result is valid by merging the ICs From the Py3 blog:

A key ingredient to a large-scale, incremental migration is maintaining a real-time status of your project. Ideally, this information would be:

- decentralized to change, so that teams can work independently

- readable through a centralized view, so that migration leaders can track progress

- aware of how dependencies impact compatibility

- used at runtime to avoid becoming stale

- as precise as a file, which lowers the activation energy needed to port code

I've found there's lots of value in empowering individual contributors/teams to make progress on their portion of the code w/o being blocked by others Concrete example: • your org has a common util that is still Py2 and is blocked upgrading • your team's code is currently Py2 only, but you'd love to update it • with the current setup, you can migrate your code to be Py2 OR Py3, and then Pants will see the dep and merge to be Py2 at runtime • with the proposed setup, saying your own code is Py2 or Py3 is a lie, b/c a dep is still Py2 only

you can migrate your code

Of course you could still migrate your code and not update the ICs, but then you lose the abilitity for Pants to do fine-grained tracking of your migration -- FYI that entire idea of "fine grained tracking" and the blog's wishlist comes from the approach I took for Foursquare, Pants, and parts of Twitter: I used a Google sheet for file level tracking I realized how much more powerful it would be for Pants to do that