Misc grammar/typo fixes (#20518)

Fix various typos and grammar issues (like repeated words) found by the
PyCharm grammar/spelling inspections.

Most of these are in docs or code comments. A few isolated instances
change some variable names, but they seem local enough that refactoring
them shouldn't cause issues. I will highlight them in comments.

build-support/bin/terraform_tool_versions.py

@@ -189,7 +189,7 @@ def fetch_platforms_for_version(
 ) -> Optional[List[ExternalToolVersion]]:
     """Fetch platform binary information for a particular Terraform version."""
     logging.info(
-        f"processiong version {version_slug} with {len(version_links.binary_links)} binaries"
+        f"processing version {version_slug} with {len(version_links.binary_links)} binaries"
     )
 
     if is_prerelease(version_slug):

docs/docs/ad-hoc-tools/integrating-new-tools-without-plugins.mdx

@@ -11,7 +11,7 @@ The `adhoc_tool` target allows you to execute "runnable" targets inside the Pant
 
 `adhoc_tool` provides you with the building blocks needed to put together a custom build process without needing to develop and maintain a plugin. The level of initial effort involved in using `adhoc_tool` is significantly lower than that of [writing a plugin](../writing-plugins/overview.mdx), so it's well-suited to consuming one-off scripts, or for rapidly prototyping a process before actually writing a plugin. The tradeoff is that there is more manual work involved in defining build processes that reflect your codebase's structure, and that the targets that define the tools you consume are less easy to reuse.
 
-The `antlr` demo in the [`example-adhoc` respository](https://github.com/pantsbuild/example-adhoc) shows an example of running a JVM-based tool to transparently generate Python code that can be used in another language:
+The `antlr` demo in the [`example-adhoc` repository](https://github.com/pantsbuild/example-adhoc) shows an example of running a JVM-based tool to transparently generate Python code that can be used in another language:
 
 ```
 adhoc_tool(

docs/docs/contributions/development/debugging-and-benchmarking.mdx

@@ -121,6 +121,6 @@ Dumping thread stacks:
    - Run: `gdb /path/to/python/binary PROCESS_ID`
 3. Enable logging to write the thread dump to `gdb.txt`: `set logging on`
 4. Dump all thread backtraces: `thread apply all bt`
-5. If you use pyenv to mange your Python install, a gdb script will exist in the same directory as the Python binary. Source it into gdb:
+5. If you use pyenv to manage your Python install, a gdb script will exist in the same directory as the Python binary. Source it into gdb:
    - `source ~/.pyenv/versions/3.8.5/bin/python3.8-gdb.py` (if using version 3.8.5)
 6. Dump all Python stacks: `thread apply all py-bt`

docs/docs/contributions/development/internal-architecture.mdx

@@ -66,9 +66,9 @@ But both of the goals are important because together they allow for an API that
 There are a few constraints that decide which `Rule`s are able to provide dependencies for one another:
 
 - `param_consumption` - When a `Rule` directly uses a `Param` as a positional argument, that `Param` is removed from scope for any of that `Rule`'s dependencies.
-  - For example, for a `Rule` `y` with a positional argument `A` and a `Get(B, C)`: if there is a `Param` `A` in scope at `y` and it is used to satisfy the positional argument, it cannot also be used to (transitively) to satisfy the `Get(B, C)` (i.e., a hyptothetical rule that consumes both `A` and `C` would not be eligible in that position).
+  - For example, for a `Rule` `y` with a positional argument `A` and a `Get(B, C)`: if there is a `Param` `A` in scope at `y` and it is used to satisfy the positional argument, it cannot also be used to (transitively) to satisfy the `Get(B, C)` (i.e., a hypothetical rule that consumes both `A` and `C` would not be eligible in that position).
   - On the other hand, for a `Rule` `w` with `Get(B, C)` and `Get(D, E)`, if there is a `Param` `A` in scope at `w`, two dependency `Rule`s that consume `A` (transitively) _can_ be used to satisfy those `Get`s. Only consuming a `Param` as a positional argument removes it from scope.
-- `provided_params` - When deciding whether one `Rule` can use another `Rule` to provide the output type of a `Get`, a constraint is applied that the candidate depedency must (transitively) consume the `Param` that is provided by the `Get`.
+- `provided_params` - When deciding whether one `Rule` can use another `Rule` to provide the output type of a `Get`, a constraint is applied that the candidate dependency must (transitively) consume the `Param` that is provided by the `Get`.
   - For example: if a `Rule` `z` has a `Get(A, B)`, only `Rule`s that compute an `A` and (transitively) consume a `B` are eligible to be used. This also means that a `Param` `A` which is already in scope for `Rule` `z` is not eligible to be used, because it would trivially not consume `B`.
 
 ### Implementation
@@ -83,7 +83,7 @@ The construction algorithm is broken up into phases:
    - If we were to stop `RuleGraph` construction at this phase, it would be necessary to do a form of [dynamic dispatch](https://en.wikipedia.org/wiki/Dynamic_dispatch) at runtime to decide which source of a dependency to use based on the `Param`s that were currently in scope. And the sets of `Param`s used in the memoization key for each `Rule` would still be overly large, causing excess invalidation.
 3. [monomorphize](https://github.com/pantsbuild/pants/blob/3a188a1e06d8c27ff86d8c311ff1b2bdea0d39ff/src/rust/engine/rule_graph/src/builder.rs#L325-L353) - "Monomorphize" the polymorphic graph by using the out-set of available `Param`s (initialized during `initial_polymorphic`) and the in-set of consumed `Param`s (computed during `live_param_labeled`) to partition nodes (and their dependents) for each valid combination of their dependencies. Combinations of dependencies that would be invalid (see the Constraints section) are not generated, which causes some pruning of the graph to happen during this phase.
    - Continuing the example from above: the goal of monomorphize is to create one copy of `Rule` `x` per legal combination of its `DependencyKey`. Assuming that both of `x`'s dependencies remain legal (i.e. that all of `{A,B,C}` are still in scope in the dependents of `x`, etc), then two copies of `x` will be created: one that uses the first dependency and has an in-set of `{A,B}`, and another that uses the second dependency and has an in-set of `{B,C}`.
-4. [prune_edges](https://github.com/pantsbuild/pants/blob/3a188a1e06d8c27ff86d8c311ff1b2bdea0d39ff/src/rust/engine/rule_graph/src/builder.rs#L836-L845) - Once the monomorphic graph has [converged](https://en.wikipedia.org/wiki/Data-flow_analysis#Convergence), each node in the graph will ideally have exactly one source of each `DependencyKey` (with the exception of `Query`s, which are not monomorphized). This phase validates that, and chooses the smallest input `Param` set to use for each `Query`. In cases where a node has more that one dependency per `DependencyKey`, it is because given a particular set of input `Params` there was more than one valid way to compute a dependency. This can happen either because there were too many `Param`s in scope, or because there were multiple `Rule`s with the same `Param` requirements.
+4. [prune_edges](https://github.com/pantsbuild/pants/blob/3a188a1e06d8c27ff86d8c311ff1b2bdea0d39ff/src/rust/engine/rule_graph/src/builder.rs#L836-L845) - Once the monomorphic graph has [converged](https://en.wikipedia.org/wiki/Data-flow_analysis#Convergence), each node in the graph will ideally have exactly one source of each `DependencyKey` (except for `Query`s, which are not monomorphized). This phase validates that, and chooses the smallest input `Param` set to use for each `Query`. In cases where a node has more than one dependency per `DependencyKey`, it is because given a particular set of input `Params` there was more than one valid way to compute a dependency. This can happen either because there were too many `Param`s in scope, or because there were multiple `Rule`s with the same `Param` requirements.
    - This phase is the only phase that renders errors: all of the other phases mark nodes and edges "deleted" for particular reasons, and this phase consumes that record. A node that has been deleted indicates that that node is unsatisfiable for some reason, while an edge that has been deleted indicates that the source node was not able to consume the target node for some reason.
    - If a node has too many sources of a `DependencyKey`, this phase will recurse to attempt to locate the node in the `Rule` graph where the ambiguity was introduced. Likewise, if a node has no source of a `DependencyKey`, this phase will recurse on deleted nodes (which are preserved by the other phases) to attempt to locate the bottom-most `Rule` that was missing a `DependencyKey`.
 5. [finalize](https://github.com/pantsbuild/pants/blob/3a188a1e06d8c27ff86d8c311ff1b2bdea0d39ff/src/rust/engine/rule_graph/src/builder.rs#L1064-L1068) - After `prune_edges` the graph is known to be valid, and this phase generates the final static `RuleGraph` for all `Rule`s reachable from `Query`s.

docs/docs/contributions/development/style-guide.mdx

@@ -97,7 +97,7 @@ class OrderedSet:
 
 ### TODOs
 
-When creating a TODO, first [create an issue](https://github.com/pantsbuild/pants/issues/new) in GitHub. Then, link to the issue # in parantheses and add a brief description.
+When creating a TODO, first [create an issue](https://github.com/pantsbuild/pants/issues/new) in GitHub. Then, link to the issue # in parentheses and add a brief description.
 
 For example:
 

docs/docs/docker/tagging-docker-images.mdx

@@ -148,7 +148,7 @@ See [String interpolation using placeholder values](./tagging-docker-images.mdx#
 
 When Docker builds images, it can tag them with a set of tags. Pants will apply the tags listed in
 the `image_tags` field of `docker_image`, and any additional tags if defined from the registry
-configuration (see [Configuring registries](./tagging-docker-images.mdx#configuring-registries).
+configuration (see [Configuring registries](./tagging-docker-images.mdx#configuring-registries)).
 
 (Note that the field is named `image_tags` and not just `tags`, because Pants has [its own tags
 concept](doc:reference-target#tags), which is unrelated.)
@@ -307,7 +307,7 @@ See [Setting a repository name](./tagging-docker-images.mdx#setting-a-repository
 The calculated hash value _may_ change between stable versions of Pants for the otherwise same input sources.
 :::
 
-## Retrieving the tags of an packaged image
+## Retrieving the tags of a packaged image
 
 When a docker image is packaged, metadata about the resulting image is output to a JSON file artefact. This includes the image ID, as well as the full names that the image was tagged with. This file is written in the same manner as outputs of other packageable targets and available for later steps (for example, a test with `runtime_package_dependencies` including the docker image target) or in `dist/` after `pants package`. By default, this is available at `path.to.target/target_name.docker-info.json`.
 

docs/docs/getting-started/incremental-adoption.mdx

@@ -11,7 +11,7 @@ How to incrementally add Pants to an existing repository.
 
 If you have an existing repository, we recommend incrementally adopting to reduce the surface area of change, which reduces risk.
 
-Incremental adoption also allows you to immediately start benefitting from Pants, then deepen adoption at your own pace, instead of postponing benefit until you are ready to make dramatic change all at once.
+Incremental adoption also allows you to immediately start benefiting from Pants, then deepen adoption at your own pace, instead of postponing benefit until you are ready to make dramatic change all at once.
 
 :::note Joining Slack
 We would love to help you with adopting Pants. Please reach out through [Slack](/community/getting-help).

docs/docs/go/index.mdx

@@ -175,7 +175,7 @@ You can pass through arguments with `--`, e.g. `pants test pkg/deploy: -- -v -ru
 
 ### Loose files in tests (`testdata`)
 
-To open files in your tests, use [`file` / `files` targets](../using-pants/assets-and-archives.mdx) targets and add them as `dependencies` to your `go_package`.
+To open files in your tests, use [`file` / `files`](../using-pants/assets-and-archives.mdx) targets and add them as `dependencies` to your `go_package`.
 
 ```python title="pkg/runner/BUILD"
 go_package(dependencies=[":testdata"])

docs/docs/helm/deployments.mdx

@@ -15,13 +15,13 @@ Please share feedback for what you need to use Pants with your Helm deployments
 
 Helm's ultimate purpose is to simplify the deployment of Kubernetes resources and help in making these reproducible. However it is quite common to deploy the same software application into different kind of environments using slightly different configuration overrides.
 
-This hinders reproducibility since operators end up having a set of configuration files and additional shell scripts that ensure that the Helm command line usued to deploy a piece of software into a given environment is always the same.
+This hinders reproducibility since operators end up having a set of configuration files and additional shell scripts that ensure that the Helm command line used to deploy a piece of software into a given environment is always the same.
 
 Pants solves this problem by providing with the ability to manage the configuration files and the different parameters of a deployment as single unit such that a simple command line as `pants experimental-deploy ::` will always have the same effect on each of the deployments previously defined.
 
 ## Defining Helm deployments
 
-Helm deployments are defined using the `helm_deployment` target which has a series of fields that can be used to guarantee the reproducibility of the given deployment. `helm_deployment` targets need to be added by hand as there is no deterministic way of instrospecting your repository to find sources that are specific to Helm:
+Helm deployments are defined using the `helm_deployment` target which has a series of fields that can be used to guarantee the reproducibility of the given deployment. `helm_deployment` targets need to be added by hand as there is no deterministic way of introspecting your repository to find sources that are specific to Helm:
 
 ```python tab={"label":"src/chart/BUILD"}
 helm_chart()
@@ -85,7 +85,7 @@ There are quite a few things to notice in the previous example:
 - One of those value files (`common-values.yaml`) provides with default values that are common to all deployments.
 - Each deployment uses an additional `xxx-override.yaml` file with values that are specific to the given deployment.
 
-The `helm_deployment` target has many additional fields including the target kubernetes namespace, adding inline override values (similar to using helm's `--set` arg) and many others. Please run `pants help helm_deployment` to see all the posibilities.
+The `helm_deployment` target has many additional fields including the target kubernetes namespace, adding inline override values (similar to using helm's `--set` arg) and many others. Please run `pants help helm_deployment` to see all the possibilities.
 
 ## Dependencies with `docker_image` targets
 
@@ -253,7 +253,7 @@ helm_deployment(
 As shown above, now the `release` and `namespace` fields are calculated at deploy-time by Pants and, as in the previous example, they will be forwarded to the Helm chart accordingly.
 
 :::caution Ensuring repeatable deployments
-You should always favor using static values (or value files) VS dynamic values in your deployments. Using interpolated environment variables in your deployments can render your deployments non-repetable anymore if those values can affect the behaviour of the system deployed, or what gets deployed (i.e. Docker image addresses).
+You should always favor using static values (or value files) VS dynamic values in your deployments. Using interpolated environment variables in your deployments can render your deployments non-repeatable anymore if those values can affect the behaviour of the system deployed, or what gets deployed (i.e. Docker image addresses).
 Be careful when chossing the values that are going to be calculated dynamically.
 :::
 

docs/docs/helm/index.mdx

@@ -111,7 +111,7 @@ pants package ::
 Built Helm chart artifact: testprojects.src.helm.example/example/example-0.2.0.tgz
 ```
 
-The final output folder can customised using the `output_path` field in the `helm_chart` target. Run `pants help helm_chart` for more information.
+The final output folder can be customised using the `output_path` field in the `helm_chart` target. Run `pants help helm_chart` for more information.
 
 #### Helm chart version
 
@@ -356,7 +356,7 @@ Use the option `pants test --no-timeouts` to temporarily disable timeouts, e.g.
 
 Pants only supports publishing Helm charts to OCI registries, a feature that was made generally available in Helm 3.8.
 
-The publishing is done with Pants' `publish` goal but first you will need to tell Pants what are the possible destination registries where to upload your charts.
+The publishing is done with Pants' `publish` goal, but first you will need to tell Pants what are the possible destination registries where to upload your charts.
 
 ### Configuring OCI registries
 

docs/docs/introduction/how-does-pants-work.mdx

@@ -27,7 +27,7 @@ This means, for example, that you can run all of your linters at the same time,
 
 ### Caching
 
-The engine caches processes precisely based on their inputs, and sandboxes execution to minimize side-effects and to make builds consistent and repeatable.
+The engine caches processes precisely based on their inputs, and sandboxes execution to minimize side effects and to make builds consistent and repeatable.
 
 <CaptionedImg src={require("/img/pants-caching.gif").default}>
   We run both tests, then add a syntax error to one test and rerun; the

docs/docs/java-and-scala/index.mdx

@@ -321,7 +321,7 @@ Pants supports loading Java and Scala projects in IntelliJ via the [BSP protocol
 After Setup (see below), and after IntelliJ has finished indexing your code, you should be able to:
 
 - Use goto definition and other symbol-index-using operations.
-- Run test classes, which will first compile them will Pants (and render compile failures if not), and then run them in the foreground with IntelliJ's test runner.
+- Run test classes, which will first compile them with Pants (and render compile failures if not), and then run them in the foreground with IntelliJ's test runner.
 
 ### Setup
 

docs/docs/python/goals/check.mdx

@@ -94,7 +94,7 @@ You can use [`.pyi` files](https://mypy.readthedocs.io/en/stable/stubs.html) for
 
 Pants's dependency inference knows to infer a dependency both on the implementation and the type stub. You can verify this by running `pants dependencies path/to/file.py`.
 
-When writing stubs for third-party libraries, you may need the set up the `[source].root_patterns` option so that [source roots](../../using-pants/key-concepts/source-roots.mdx) are properly stripped. For example:
+When writing stubs for third-party libraries, you may need to set up the `[source].root_patterns` option so that [source roots](../../using-pants/key-concepts/source-roots.mdx) are properly stripped. For example:
 
 ```toml tab={"label":"pants.toml"}
 [source]

docs/docs/python/goals/package.mdx

@@ -25,8 +25,8 @@ This allows you to test your packaging pipeline by simply running `pants test ::
 See [test](./test.mdx) for more information.
 :::
 
-:::tip Streamling Docker builds
-Check out our blog [Streamling Docker Builds](https://blog.pantsbuild.org/pants-pex-and-docker/) to read about how you can combine these `package` formats with Pants's Docker support. Also see our [Docker docs](../../docker/index.mdx)
+:::tip Streamline Docker builds
+Check out our blog [Streamline Docker Builds](https://blog.pantsbuild.org/pants-pex-and-docker/) to read about how you can combine these `package` formats with Pants's Docker support. Also see our [Docker docs](../../docker/index.mdx)
 :::
 
 ## Creating a PEX file from a `pex_binary` target

docs/docs/python/goals/publish.mdx

@@ -57,7 +57,7 @@ It is better to provide the required secrets using environment variables when ru
 
 ## Environment variables
 
-Pants will pass certain configuration [environment variables](https://twine.readthedocs.io/en/latest/#environment-variables), through to Twine. If multiple repositories are involved in a single `publish` goal, you can distinguish them by adding an undersore and the repository name (upper-cased, and with hyphens replaced with underscores) as a suffix on the environment variable names:
+Pants will pass certain configuration [environment variables](https://twine.readthedocs.io/en/latest/#environment-variables), through to Twine. If multiple repositories are involved in a single `publish` goal, you can distinguish them by adding an underscore and the repository name (upper-cased, and with hyphens replaced with underscores) as a suffix on the environment variable names:
 
 - `TWINE_USERNAME`
 - `TWINE_USERNAME_<repository>`