https://pantsbuild.org/ logo
#development
Title
# development
h

hundreds-father-404

08/05/2021, 10:18 PM
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