Merge pull request #336 from yarikoptic/enh-codespell

Fix some typos detected by codespell + provide codespell workflow to catch possible future typos

Author: hategan

.github/workflows/codespell.yml

@@ -0,0 +1,17 @@
+---
+name: Codespell
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+jobs:
+  codespell:
+    name: Check for spelling errors
+    runs-on: ubuntu-latest
+
+    steps:
+      - uses: actions/checkout@v2
+      - uses: codespell-project/actions-codespell@master

docs/README-selectors.md

@@ -21,7 +21,7 @@ substitute the value selected in the selector. For example:
     x = f("<&executor-type>")
 
 When rendered, the `<&executor-type>` string will be replaced by the
-lower case version of the selected value in the immediately preceeding
+lower case version of the selected value in the immediately preceding
 selector. The string `"<&executor-type>"` must be a standalone token as
 far as the syntax highlighter is concerned. That is, it probably won't
 work if it's in a comment.
@@ -41,7 +41,7 @@ To add alternative code blocks, use:
 ```
 
 Alternate code blocks as well as value substitutions bind to the closest
-preceeding selector. However, selectors are synchronized, in that
+preceding selector. However, selectors are synchronized, in that
 selecting "Local" in one selector, will also select "Local" in all other
 selectors of the same type (i.e. "executor-type-*") that have "Local" as
 a listed value. If a selector does not have that value, the values and

docs/development/programming.rst

@@ -99,7 +99,7 @@ The general workflow used by the batch scheduler executor to submit a job is as
 follows:
 
     1. Generate a submit script in the *work directory*, which is obtained
-    from the `config` object at executor intialization, and which defaults to
+    from the `config` object at executor initialization, and which defaults to
     `~/.psij/work/<executor.name>`, where `<executor.name>` is the value of
     the `name` of the implementing class. The submit script is generated using
     the
@@ -112,7 +112,7 @@ follows:
 
     3. Invoke
     :meth:`~psij.executors.batch.batch_scheduler_executor.BatchSchedulerExecutor.job_id_from_submit_output`
-    to obtain the job's native ID from the outut of the submit command executed
+    to obtain the job's native ID from the output of the submit command executed
     in step (2).
 
     4. Register the job with the *status polling thread*.

scripts/WORKFLOW-EXAMPLES.md

@@ -100,7 +100,7 @@ RUN pip install wordcloud
 
 ## Executing a singularity container
 
-We will run the PDF2Wordcloud example in a container. We will use the docker container described above and execute it with singularity. In this case the spec defines the execution of a container with singularity. The actual command line tool is passed as an optional argument after all requiered singularity options.
+We will run the PDF2Wordcloud example in a container. We will use the docker container described above and execute it with singularity. In this case the spec defines the execution of a container with singularity. The actual command line tool is passed as an optional argument after all required singularity options.
 
 ```
 ...
@@ -165,7 +165,7 @@ for j in [make_job(pdf2textSingularitySpec, None), make_job(text2wordcloudSingul
 
 In this example we demonstrate how to wrap and execute an mpi hello world job with PSI/J. The base mpi command is `mpiexec -n 36 -ppn 36 echo Hello world`. This example is introducing the concept of a [job launcher](https://exaworks.org/psij-python/docs/programming.html#launchers), in this case **mpi**, e.g. `job.spec.launcher = "mpirun"`. The complete example script can be found [here](./).
 
-1. Load psij module and instanciate job executer, e.g. local or slurm
+1. Load psij module and instantiate job executer, e.g. local or slurm
 
 ```
 import psij

scripts/pdf2wc4singularity.py

@@ -43,7 +43,7 @@ def make_singularity_spec(image=None,
     '''
     :param image: path to image file
     :param bind_input: List of input paths
-    :param bind_output: :ist of output paths
+    :param bind_output: List of output paths
     :param command: name of script/command to be executed
     :param options: command line options for command
     '''

src/psij/executors/batch/batch_scheduler_executor.py

@@ -163,7 +163,7 @@ class BatchSchedulerExecutor(JobExecutor):
     strongly encouraged to restrict the query of job states to the specified jobs in order to reduce
     the load on the queuing system. The output of the status command is then parsed using
     :func:`~parse_status_output` and the status of each job is updated accordingly. If the status
-    of a registered job is not found in the ouput of the queue status command, it is assumed
+    of a registered job is not found in the output of the queue status command, it is assumed
     completed (or failed, depending on its exit code), since most queuing systems automatically
     purge completed jobs from their databases after a short period of time. The exit code is read
     from the exit code file, as described above. If the exit code value is not zero, the job is
@@ -206,7 +206,7 @@ def submit(self, job: Job) -> None:
         try:
             logger.debug('Job %s: running submit command', job.id)
             out = self._run_command(self.get_submit_command(job, submit_file_path))
-            logger.debug('Job %s: submit command ouput: %s', job.id, out)
+            logger.debug('Job %s: submit command output: %s', job.id, out)
             job._native_id = self.job_id_from_submit_output(out)
             logger.info('Job %s: native id: %s', job.id, job.native_id)
             self._set_job_status(job, JobStatus(JobState.QUEUED,

src/psij/executors/batch/pbspro.py

@@ -90,7 +90,7 @@ def get_cancel_command(self, native_id: str) -> List[str]:
         # the slurm cancel command had a -Q parameter
         # which does not report an error if the job is already
         # completed.
-        # TODO: whats the pbs equivalent of that?
+        # TODO: what's the pbs equivalent of that?
         # there is -x which also removes job history (so would need to
         # check that this doesn't cause implicit COMPLETED states when
         # maybe it should be cancelled states?)

src/psij/job_executor.py

@@ -136,15 +136,15 @@ def cancel(self, job: Job) -> None:
         """
         Cancels a job that has been submitted to underlying executor implementation.
 
-        A successful return of this method only indicates that the request for cancelation has been
+        A successful return of this method only indicates that the request for cancellation has been
         communicated to the underlying implementation. The job will then be canceled at the
         discretion of the implementation, which may be at some later time. A successful
-        cancelation is reflected in a change of status of the respective job to
+        cancellation is reflected in a change of status of the respective job to
         :attr:`~psij.JobState.CANCELED`. User code can synchronously wait until the
         :attr:`~psij.JobState.CANCELED` state is reached using `job.wait(JobState.CANCELED)` or
         even `job.wait()`, since the latter would wait for all final states, including
         `JobState.CANCELED`. In fact, it is recommended that `job.wait()` be used because it is
-        entirely possible for the job to complete before the cancelation is communicated to the
+        entirely possible for the job to complete before the cancellation is communicated to the
         underlying implementation and before the client code receives the completion notification.
         In such a case, the job will never enter the `CANCELED` state and
         `job.wait(JobState.CANCELED)` would hang indefinitely.