Improve export goal to handle multiple Python resolves
#14436
Conversation
This allows us to partition, e.g. one venv per resolve. # 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]
# 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]
# 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]
# 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]
# 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]
# 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]
| @@ -51,7 +52,7 @@ class Symlink: | |||
|
|
|||
| @frozen_after_init | |||
| @dataclass(unsafe_hash=True) | |||
| class ExportableData: | |||
| class ExportResult: | |||
There was a problem hiding this comment.
Why the renaming? It makes this harder to review, and it doesn't seem to achieve any purpose beyond preference. If anything, the new naming is less coherent, since "ExportRequest" sounds like a request to perform exporting, whereas it really is a request for data that the caller then actually exports.
There was a problem hiding this comment.
Because Data is awkward with plural. I didn't want to say Datas, nor Datum.
There was a problem hiding this comment.
Open to other suggestions. I thought about Entity and Thing...Data doesn't seem it tho
There was a problem hiding this comment.
Note that ExportResult(s) aligns with FmtResult(s), LintResult(s), and CheckResult(s).
| exportables = await MultiGet( | ||
| Get(ExportableData, ExportableDataRequest, request) for request in requests | ||
| ) | ||
| all_results = await MultiGet(Get(ExportResults, ExportRequest, request) for request in requests) |
There was a problem hiding this comment.
Same comment re renaming throughout, it just makes the salient changes harder to review.
| @dataclass(frozen=True) | ||
| class _ExportVenvRequest(EngineAwareParameter): | ||
| resolve: str | None | ||
| root_python_targets: tuple[Target, ...] |
There was a problem hiding this comment.
The word "root" here seems to be more confusing than useful? AFAICT there is nothing here that requires these to be "root targets" in the usual sense?
There was a problem hiding this comment.
They're the input targets that you specified to run on, as compared to their dependencies. This change is in line with #14323
…14436) We generate a distinct virtualenv for each resolve, using the path `dist/python/virtualenvs/<resolve>`. From there, the user can load in their IDE which one to use. If users want to only generate for one IDE, they can use the `peek` snippet from pantsbuild#14327. -- If `enable_resolves = false`, we stick with the old behavior. This is convenient because it would be a misnomer to write the path to `[python].default_resolve`, which doesn't make sense to use if resolves aren't enabled. We log a warning when you do migrate to `enable-resolves` that the old path will no longer be valid. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
… of #14436) (#14454) We generate a distinct virtualenv for each resolve, using the path `dist/python/virtualenvs/<resolve>`. From there, the user can load in their IDE which one to use. If users want to only generate for one IDE, they can use the `peek` snippet from #14327. -- If `enable_resolves = false`, we stick with the old behavior. This is convenient because it would be a misnomer to write the path to `[python].default_resolve`, which doesn't make sense to use if resolves aren't enabled. We log a warning when you do migrate to `enable-resolves` that the old path will no longer be valid. [ci skip-rust] [ci skip-build-wheels]
We generate a distinct virtualenv for each resolve, using the path
dist/python/virtualenvs/<resolve>. From there, the user can load in their IDE which one to use.If users want to only generate for one IDE, they can use the
peeksnippet from #14327.--
If
enable_resolves = false, we stick with the old behavior. This is convenient because it would be a misnomer to write the path to[python].default_resolve, which doesn't make sense to use if resolves aren't enabled.We log a warning when you do migrate to
enable-resolvesthat the old path will no longer be valid.