Good question, interesting! If we made our invalidation logic much more nuanced, then that could work. R/n it's a hash that combines all the input requirements + the ICs used to generate the lockfile for the whole repo. Concretely, the call sites use

await Get

to get the

PythonLockfileRequest

, access its

invalidation_digest

, and compare to what is written on disk in the lockfile (https://github.com/pantsbuild/pants/pull/12448) We could instead store what the ICs are directly in the lockfile. Then the only thing we are missing afaict is being able to statically determine if two IC ranges are compatible are not which gets to the comment I punted on above. Every time I have attempted to do clever things w/ ICs—like simplifying

['==3.7,==2.7', '==2.7']

to be

['==2.7']

b/c the first is impossible to satisfy—I have not been able to figure it out. All our

interpreter_constraints.py

code r/n that checks for "validitity" works by iterating over every anticipated version in our Python "universe". It feels like it shouldn't be hard: as a human, I can very quickly deduce it's unsatisfiable. But I haven't been able to figure out how to automate the static analysis