forked from pantsbuild/pants
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Change
Target
to have a similar interface to dict[t]
and `dict.ge…
…t(t)` (pantsbuild#9340) ### Problem As described in pantsbuild#9337, we need a mechanism to express that some rules optionally may use Fields when registered on the target type, but don't actually need them to operate. For example, with `./v2 test`, the only Field we absolutely need for Pytest is `PythonTestsSources`. It's an added bonus if the target type has `Timeout` and `Coverage`. Even if they don't have those fields registered, we can still meaningfully return a `TestResult`. We simply can't use the added features of `--run-coverage` and `--pytest-timeouts`. When these rules are using targets without those optional fields, we typically will want to use a default value for the `Field` when not registered. Typically, we will want that default to be the same as `Field(raw_value=None)`. Sometimes, we will want to be able to override that default value. ### Solution Align `Target` with how you access a dictionary: 1. `tgt[Timeout]` will get the field instance if registered on the target type, else raise `KeyError`. 2. `tgt.get(Timeout)` will get the field instance if registered on the target type, else return `Timeout(raw_value=None)`. 3. `tgt.get(Timeout, default_raw_value=100)` will get the field instance if registered on the target type, else return `Timeout(raw_value=100)`. Conceptually, it makes sense to think of `Target` similarly to a dictionary. We define a `Target` as *a unique combination of fields that are valid together*. Tangibly, the dictionary maps `Type[Field] -> Field`. ### Result Accessing fields on `Target` aligns more with Python conventions. -- We can now more accurately reflect in rules what fields we actually must have vs. would like to have. A crucial benefit of this is that it makes it much easier for core Pants devs to add new `Fields` to pre-existing target types and to consume those fields in core Pants without forcing all plugin authors to implement that field. For example, we may want to add the field `RequirementsConstraints` to `PythonBinary` one day and use that in `python_create_binary.py` if we have that field registered, but still be able to operate on target types without it. This PR provides a mechanism for us to not only add that new field, but express in `python_create_binary.py` that we would like to use that field if it's available, without breaking any plugin authors.
- Loading branch information
1 parent
cdf5f94
commit 9b883c8
Showing
3 changed files
with
134 additions
and
95 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters