Add codespell via pre-commit and fix findings

.codespellrc

@@ -0,0 +1,4 @@
+# See: https://github.com/codespell-project/codespell#using-a-config-file
+[codespell]
+# In case of a false positive, add the problematic word, in all lowercase, to a comma-separated list here:
+ignore-words-list = lief

.pre-commit-config.yaml

@@ -0,0 +1,28 @@
+# Apply to all files locally without commiting:
+#   pre-commit run --all-files
+# disable autofixing PRs, commenting "pre-commit.ci autofix" on a pull request triggers a autofix
+ci:
+  autofix_prs: false
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.5.0
+    hooks:
+      - id: check-yaml
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.2.6
+    hooks:
+      - id: codespell
+        args: [--write]
+  - repo: https://github.com/jumanjihouse/pre-commit-hook-yamlfmt
+    rev: 0.2.3
+    hooks:
+      - id: yamlfmt
+        args: [--mapping, '2', --offset, '2', --sequence, '4', --implicit_start]
+  - repo: https://github.com/python-jsonschema/check-jsonschema
+    rev: 0.28.0
+    hooks:
+      - id: check-github-workflows
+  - repo: meta
+    hooks:
+      - id: check-hooks-apply
+      - id: check-useless-excludes

cep-0.md

@@ -5,7 +5,7 @@
 <tr><td> Created </td><td> Aug 30, 2016</td></tr>
 <tr><td> Updated </td><td> Aug 30, 2016</td></tr>
 <tr><td> Discussion </td><td> link to the PR where the CEP is being discussed, NA is circulated initially </td></tr>
-<tr><td> Implementation </td><td> link to the PR for the implementation, NA if not availble </td></tr>
+<tr><td> Implementation </td><td> link to the PR for the implementation, NA if not available </td></tr>
 </table>
 
 ## Abstract

cep-11.md

@@ -18,16 +18,16 @@
 `conda` packages. It operates by discovering certain JSON files located in `$PREFIX/Menu` after
 linking the package to the environment.
 
-This library has primarily targetted Windows. The original project supported Linux and MacOS, but
+This library has primarily targeted Windows. The original project supported Linux and MacOS, but
 `menuinst` was never used in practice on those platforms. As a result, the required JSON metadata
 diverged significantly in each platform, and the implementations were not kept up to date.
 
 This CEP will attempt to standardize the `menuinst` interface by:
 
 1. Providing a unified metadata schema for all platforms so a single document contains all the
-   metadata required to create shorcuts in all platforms.
+   metadata required to create shortcuts in all platforms.
 2. Enumerating the expected behavior for different configurations.
-3. Defining a programmatic interface for implementors (CLI / API).
+3. Defining a programmatic interface for implementers (CLI / API).
 
 ## Menu metadata schema
 
@@ -106,7 +106,7 @@ simplified overview of all possible keys and their default values:
           "desktop": true, # create desktop location
           "quicklaunch": true, # create quick launch shortcut too
           "file_extensions": None, # file extensions to associate with shortcut in registry
-          "url_protocols": None, # URI protocols to associate with shorcut in registry
+          "url_protocols": None, # URI protocols to associate with shortcut in registry
           "app_user_model_id": None, # Identifier used to associate processes with a taskbar icon
         }
       }
@@ -171,45 +171,45 @@ macOS            | `.app` directory | `~/Applications` | `/Applications` |
 Windows          | `.lnk` file | `{{ menu_name }}` directory inside Start Menu, Desktop, and/or Quick Launch | Start Menu | These locations are customizable and configured in the Windows registry.
 
 - On Linux, little needs to be done because XDG delegates the responsibility to the desktop
-  manager. The implementor only needs to create the `.desktop` file and adjust/add the menu XML
+  manager. The implementer only needs to create the `.desktop` file and adjust/add the menu XML
   file(s).
 - On macOS, we had to come up with some ideas. The shortcut is actually an `.app` directory.
-  Implementors must follow Apple's guidelines. See Addendum B for implementation details.
+  Implementers must follow Apple's guidelines. See Addendum B for implementation details.
 - On Windows, `.lnk` files are created with the Windows API. File type and URL protocol association
   is done in the [Windows
   registry](https://learn.microsoft.com/en-us/windows/win32/shell/fa-file-types).
 
 Some installations might provide two modes: "Current user only", and "All users". This option is
 not surfaced in the JSON metadata, but might be requested at creation time in the CLI or API. This
-means that implementors MUST be able to handle both user locations and system locations, as
+means that implementers MUST be able to handle both user locations and system locations, as
 detailed above. In particular, in-process permission elevation needs to be considered.
 
 When a package is removed, the file artifacts MUST be deleted too. If changes were done in other
 resources (XML files on Linux, Registry on Windows), these MUST be undone too.
 
 ## CLI interface
 
-The implementor CLI is _not_ defined in this document. However, the integrations with `constructor`
+The implementer CLI is _not_ defined in this document. However, the integrations with `constructor`
 SHOULD be standardized if they are going to be kept in use. 
 
 The proposed CLI (inspired by what's already in use to introduce minimal changes) is:
 
 ```shell
-${IMPLEMENTOR} constructor --prefix ${PREFIX} [--base-prefix ${BASE_PREFIX}] [--mode user|system] [--make-menus | --rm-menus] [pkg-name ...] 
+${IMPLEMENTER} constructor --prefix ${PREFIX} [--base-prefix ${BASE_PREFIX}] [--mode user|system] [--make-menus | --rm-menus] [pkg-name ...] 
 ```
 
 - `--make-menus` will create the menu items for the JSON files found in `$PREFIX/Menu`.
 - `--rm-menus` will uninstall the corresponding menu items from the system.
 - If values are passed next to these two flags, only the JSON files that match those package names
   will be handled. Others will be ignored.
 - `--base-prefix` is optional and defaults to the value passed to `--prefix`. It is only needed
-  when `IMPLEMENTOR` is running from a location other than `--prefix` (e.g. `base` vs a custom
+  when `IMPLEMENTER` is running from a location other than `--prefix` (e.g. `base` vs a custom
   environment, or system Python and a virtual environment).
 - `--mode` is optional and defaults to the mark provided by the `--base-prefix` location. If a
   `.nonadmin` file is present there, `mode=user` will be assumed. Otherwise, `mode=system` will be
   assumed, with a fallback to `mode=user` if necessary.
 
-Alternatively, the `constructor` subcommand needs for menus can be dropped if `IMPLEMENTOR`
+Alternatively, the `constructor` subcommand needs for menus can be dropped if `IMPLEMENTER`
 supports new settings and/or CLI flags in the `create | install` commands. Namely:
 
 - `base_prefix`: override the assumed `base` environment location. This is nowadays available as
@@ -219,7 +219,7 @@ supports new settings and/or CLI flags in the `create | install` commands. Namel
   - `--shortcuts` would set `shortcuts=True`, which is the default otherwise.
   - `--no-shorcuts` would set `shortcuts=False`.
   - `--shortcuts pkg1 pkg2 ...` would set `shortcuts=[pkg1, pkg2, ...]`, which would instruct
-    `IMPLEMENTOR` to handle menu item creation or removal for those packages only.
+    `IMPLEMENTER` to handle menu item creation or removal for those packages only.
 
 ## Backwards compatibility
 
@@ -252,7 +252,7 @@ All CEPs are explicitly [CC0 1.0 Universal](https://creativecommons.org/publicdo
 ### `menuinst 1.x` pre-standard
 
 The required metadata for each platform is documented in [the `menuinst` wiki][wiki]. However, only
-Windows is really supported by the tool. This assymmetrical growth has allowed Windows to grow an
+Windows is really supported by the tool. This asymmetrical growth has allowed Windows to grow an
 ad-hoc specification that doesn't really translate well to other platforms.
 
 The overall schema seems to be:
@@ -369,7 +369,7 @@ implemented. Per-platform options are allowed but only when strictly necessary.
 - In some cases, if an external binary is required, it needs to be symlinked into the `.app`
   directory to ensure keyboard integrations work (see
   [`conda/menuinst#122`](https://github.com/conda/menuinst/issues/122)).
-- URL protocol association requires special support in the binary launcher. Implementors can choose
+- URL protocol association requires special support in the binary launcher. Implementers can choose
   how to implement it. [See this issue](https://github.com/conda/menuinst/issues/118) and
   [this PR](https://github.com/conda/menuinst/pull/119) for ideas.
 

cep-13.md

@@ -38,7 +38,7 @@ The reason for a new spec are:
 - iron out some inconsistencies around multiple outputs (build vs. build/script
   and more)
 - remove any need for recursive parsing & solving
-- cater to needs for automation and dependency tree analysis via a determinstic
+- cater to needs for automation and dependency tree analysis via a deterministic
   format
 
 ## Major differences with conda-build

cep-14.md

@@ -115,7 +115,7 @@ build:
   # What is valid in an `if:` condition is valid
   skip: [list of expressions]
 
-  # wether the package is a noarch package, and if yes, wether it is "generic" or "python"
+  # whether the package is a noarch package, and if yes, whether it is "generic" or "python"
   # defaults to null ("arch" package)
   noarch: Option<OneOf<"generic" | "python">>
 
@@ -177,7 +177,7 @@ build:
     # was `ignore_prefix_files`
     ignore: bool | [path] (defaults to false)
 
-    # wether to detect binary files with prefix or not
+    # whether to detect binary files with prefix or not
     # was `detect_binary_files_with_prefix`
     ignore_binary_files: bool (defaults to true on Unix and (always) false on Windows)
 
@@ -186,7 +186,7 @@ build:
     # linux only, list of rpaths (was rpath)
     rpaths: [path] (defaults to ['lib/'])
 
-    # wether to relocate binaries or not. If this is a list of paths, then
+    # whether to relocate binaries or not. If this is a list of paths, then
     # only the listed paths are relocated
     binary_relocation: bool (defaults to true) | [glob]