#17776 Unifying tool lockfiles and user lockfiles? New discussion created by benjyw Kicking off a thread to discuss how Python tool lockfiles are different from user lockfiles, and why, and whether we can simplify and unify these mechanisms. This is particularly in relation to

export

, which currently requires a lot of jumping through hoops in order to support the

--resolve=

flag uniformly for user and tool lockfiles. Basically, for a user lockfile it is easy to go from resolve name to lockfile content. But for a tool lockfile, we have to go via ExportPythonToolSentinel -> ExportPythonTool -> PexRequest As far as I can tell, this is so that tools can tinker with the interpreter constraints in various ways. E.g., pants/src/python/pants/backend/python/lint/black/subsystem.py Line 151 in </pantsbuild/pants/commit/7251de9bb8aef692b4ffcfc62c36943983a51145|7251de9> . But I'm wondering if this is strictly necessary? There are already interpreter constraints baked into the lockfile, and if the repo has custom interpreter constraints on the tool's subsystem then they must regenerate the lockfile anyway. So a lot of complexity seems to exist only to support the feature of automatically adopting python3.8 interpreter constraints for black and mypy (and maybe there are other examples?) without forcing you to regenerate the 3.7+ lockfile we ship with. And I'm wondering if it's worth it. We could, for example, ship a python3.8+ tool lockfile, and if you must run on 3.7 then you must generate a tool lockfile? But, I'm also wondering if I'm fully understanding this, and if I am missing more reasons why this complexity is needed. I have a feeling I'm not seeing the full picture. pantsbuild/pants