[internal] DRY rule to generate a lockfile #12378
Conversation
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
| req: PythonLockfileRequest, pip_tools_subsystem: PipToolsSubsystem | ||
| ) -> PythonLockfile: | ||
| input_requirements = await Get( | ||
| Digest, CreateDigest([FileContent("reqs.txt", "\n".join(req.requirements).encode())]) |
There was a problem hiding this comment.
Note that this file name will be included in the generated lockfile like this:
pants/src/python/pants/backend/python/lint/black/lockfile.txt
Lines 11 to 14 in b5781b5
This is somewhat of a UX regression to always use reqs.txt, but I figure it might in some ways be less confusing than the old naming schemes we were using? Thoughts on an optimal UX? I'd rather prioritize good UX than simpler code here.
Note that we'll be changing the lockfile header already to share information about how the lockfile can be regenerated, along w/ maybe things like which ICs were used.
pants/src/python/pants/backend/python/lint/black/lockfile.txt
Lines 1 to 6 in b5781b5
| logger.info(f"Wrote lockfile for {result.tool_name} to {result.path}") | ||
| logger.info(f"Wrote lockfile to {result.path}") |
There was a problem hiding this comment.
This is a UX regression imo. I couldn't figure out a good, generic way to store this info on PythonLockfile because a tool_name property no longer makes sense.
Thoughts if this is worth trying to fix? It might be clear enough already what's happening.
There was a problem hiding this comment.
I think that this is the slot for the "resolve name" that I've been referring to.
User resolves will need to be identified by something when specified on pex_binary, etc, and identifying them by the full lockfile name seems a bit boilerplatey. Since we're not going with targets for resolves, that probably leaves us with choosing a slug for the resolve and allowing its path to be configured in pants.toml, with a default "default" resolve in the list automatically. See previous comment on this.
There was a problem hiding this comment.
Okay, cool. I'll add a TODO in a followup to restore this once we have multiple user lockfiles.
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
| logger.info(f"Wrote lockfile for {result.tool_name} to {result.path}") | ||
| logger.info(f"Wrote lockfile to {result.path}") |
There was a problem hiding this comment.
I think that this is the slot for the "resolve name" that I've been referring to.
User resolves will need to be identified by something when specified on pex_binary, etc, and identifying them by the full lockfile name seems a bit boilerplatey. Since we're not going with targets for resolves, that probably leaves us with choosing a slug for the resolve and allowing its path to be configured in pants.toml, with a default "default" resolve in the list automatically. See previous comment on this.
Soon, our lockfile generation will get much fancier to generate one lockfile per valid Python interpreter version, then merge into a single lockfile.
This is prework to use a consistent rule to generate a lockfile.
[ci skip-rust]
[ci skip-build-wheels]