I’ve changed the comment header format now, and I’m now getting to the consumption side of things. I currently still calculate the invalidation digest with the requirements strings and the interpreter constraints. That means the invalidation digest becomes incorrect if the requirements change OR [new] if the interpreter constraints in the file change. The lockfile is invalid for a given user if the invalidation digest is incorrect OR [new] if the interpreter constraints are not a subset of the interpreter constraints defined in the header. Is that a correct understanding?

not certain how exactly you want to serialize/deserialize those constarints, but we want to preserve what they were exactly and not lose information by hashing it That will allow at consumption-time reading them back in to

InterpreterConstraints

, then doing

lockfile_interpreter_constraints.is_compatible(context_ics)

(Completion of this task is blocked on merging #12448)

Perhaps add the

InterpreterConstraints

method as a prework PR? I was hoping to wait a little longer before merging #12448 because it's going to hurt performance for Pants devs and result in annoying warnings for you and me w/ our M1s that we override

[python-setup].interpreter_constraints

, until #12542 lands that is (Another option is to add

ignore

to the enum, which we may want to do anyways. Even if we end up deleting that before 2.7 stable goes out.)