Merge pull request #283 from dmgav/pre-commit

Pre commit

.codecov.yml

@@ -1,4 +1,4 @@
-# show coverage in CI status, not as a comment. 
+# show coverage in CI status, not as a comment.
 comment: off
 coverage:
   status:

.github/CONTRIBUTING.md

@@ -38,10 +38,10 @@ characters.  If the commit is related to a ticket, indicate that with
 "See #3456", "See ticket 3456", "Closes #3456" or similar.
 ```
 
-Describing the motivation for a change, the nature of a bug for bug fixes 
-or some details on what an enhancement does are also good to include in a 
-commit message. Messages should be understandable without looking at the code 
-changes. 
+Describing the motivation for a change, the nature of a bug for bug fixes
+or some details on what an enhancement does are also good to include in a
+commit message. Messages should be understandable without looking at the code
+changes.
 
 Standard acronyms to start the commit message with are:
 ```
@@ -64,7 +64,7 @@ REL: related to releases
 * Now push to your fork
 * Submit a [pull request](https://help.github.com/articles/using-pull-requests) to this branch. This is a start to the conversation.
 
-At this point you're waiting on us. We like to at least comment on pull requests within three business days 
+At this point you're waiting on us. We like to at least comment on pull requests within three business days
 (and, typically, one business day). We may suggest some changes or improvements or alternatives.
 
 Hints to make the integration of your changes easy (and happen faster):

.github/workflows/black.yml

@@ -18,4 +18,4 @@ jobs:
           pip install black
       - name: Run black
         run: |
-          black . --check
+          black . --check

.github/workflows/flake8.yml

@@ -18,4 +18,4 @@ jobs:
           pip install flake8
       - name: Run flake8
         run: |
-          flake8
+          flake8

.github/workflows/isort.yml

@@ -18,4 +18,4 @@ jobs:
           pip install isort
       - name: Run ISort
         run: |
-          isort . -c
+          isort . -c

.github/workflows/pre-commit.yml

@@ -0,0 +1,33 @@
+name: pre-commit
+
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  lint:
+    # pull requests are a duplicate of a branch push if within the same repo.
+    if: github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name != github.repository
+
+    name: Check code style
+    runs-on: ubuntu-latest
+    strategy:
+      fail-fast: false
+    defaults:
+      run:
+        shell: bash -l {0}
+
+    steps:
+      - uses: actions/checkout@v3
+
+      - uses: actions/setup-python@v4
+
+      - name: Install dev dependencies
+        run: |
+          set -vxeuo pipefail
+          pip install -r requirements-dev.txt
+          python -m pip list
+
+      - name: Run pre-commit
+        run: pre-commit run --all-files

.isort.cfg

@@ -2,4 +2,4 @@
 line_length = 115
 multi_line_output = 3
 include_trailing_comma = True
-profile = black
+profile = black

.pre-commit-config.yaml

@@ -0,0 +1,25 @@
+default_language_version:
+    python: python3
+repos:
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.4.0
+    hooks:
+      - id: check-yaml
+      - id: end-of-file-fixer
+      - id: trailing-whitespace
+  - repo: https://github.com/ambv/black
+    rev: 23.3.0
+    hooks:
+      - id: black
+  - repo: https://github.com/pycqa/flake8
+    rev: 6.0.0
+    hooks:
+      - id: flake8
+  - repo: https://github.com/pycqa/isort
+    rev: 5.12.0
+    hooks:
+      - id: isort
+  - repo: https://github.com/kynan/nbstripout
+    rev: 0.6.1
+    hooks:
+      - id: nbstripout

.test_durations

@@ -2056,4 +2056,4 @@
     "bluesky_queueserver/manager/tests/test_zmq_api.py::test_zmq_api_task_status_3_fail[params3-API request contains unsupported parameters: 'some_param']": 0.9561252879793756,
     "bluesky_queueserver/manager/tests/test_zmq_api.py::test_zmq_api_thread_based": 9.077404906973243,
     "bluesky_queueserver/manager/tests/test_zmq_api.py::test_zmq_api_unsupported_parameters": 1.2429159249877557
-}
+}

bluesky_queueserver/profile_collection_sim/user_group_permissions.yaml

@@ -23,7 +23,7 @@ user_groups:
       - null  # Nothing is forbidden
     allowed_functions:
       - "function_sleep"  # Explicitly listed name
-      - ":^func_for_test"  
+      - ":^func_for_test"
   test_user:  # Another group used for unit tests.
     allowed_plans:
       - ":^count"  # Use regular expression patterns

docs/source/cli_tools.rst

@@ -190,7 +190,7 @@ Other Configuration Parameters
     $ start-re-manager -h
     usage: start-re-manager [-h] [--config CONFIG_PATH] [--zmq-control-addr ZMQ_CONTROL_ADDR]
                             [--zmq-addr ZMQ_ADDR] [--startup-profile STARTUP_PROFILE]
-                            [--startup-module STARTUP_MODULE | --startup-script STARTUP_SCRIPT | 
+                            [--startup-module STARTUP_MODULE | --startup-script STARTUP_SCRIPT |
                              --startup-dir STARTUP_DIR]
                             [--ignore-invalid-plans {ON,OFF}]
                             [--device-max-depth DEVICE_MAX_DEPTH]
@@ -631,7 +631,7 @@ the path to the directory with startup files, the path to a startup script or mo
     $ qserver-list-plans-devices -h
     usage: qserver-list-plans-devices [-h] [--file-dir FILE_DIR] [--file-name FILE_NAME]
                                       [--startup-profile STARTUP_PROFILE]
-                                      [--startup-dir STARTUP_DIR | --startup-module STARTUP_MODULE_NAME | 
+                                      [--startup-dir STARTUP_DIR | --startup-module STARTUP_MODULE_NAME |
                                       --startup-script STARTUP_SCRIPT_PATH]
                                       [--ipython-dir IPYTHON_DIR]
                                       [--use-ipython-kernel {ON,OFF}]
@@ -861,4 +861,4 @@ qserver-qtconsole
 
 Starts Jupyter Qt Console connected to the IPython kernel running in the worker process.
 Jupyter Qt Console is extended Qt-based version of Jupyter Console. The command behaves similarly
-to :ref:`qserver_console_cli`.
+to :ref:`qserver_console_cli`.

docs/source/features_and_config.rst

@@ -163,4 +163,4 @@ tutorial.
 
 ``bluesky_queueserver`` package provides ``ReceiveConsoleOutput`` and ``ReceiveConsoleOutputAsync``
 class, which can be helpful in implementing remote monitoring features in client applications. See
-:ref:`subscribing_to_console_output` for more details.
+:ref:`subscribing_to_console_output` for more details.

docs/source/introduction_for_users.rst

@@ -8,8 +8,8 @@ What is Bluesky Queue Server?
 Bluesky Queue Server is a set of tools that provide alternative method for executing
 `Bluesky <https://blueskyproject.io/bluesky>`_ plans. The Queue Server includes the core
 `bluesky-queueserver <https://github.com/bluesky/bluesky-queueserver>`_ package and
-`bluesky-queueserver-api <https://github.com/bluesky/bluesky-queueserver-api>`_, 
-`bluesky-httpserver <https://github.com/bluesky/bluesky-httpserver>`_ and 
+`bluesky-queueserver-api <https://github.com/bluesky/bluesky-queueserver-api>`_,
+`bluesky-httpserver <https://github.com/bluesky/bluesky-httpserver>`_ and
 `bluesky-widgets <https://github.com/bluesky/bluesky-widgets>`_ packages that implement
 additional functionality. Traditionally Bluesky was used interactively
 from IPython environment as demonstrated in
@@ -67,8 +67,8 @@ for controlling RE Manager over 0MQ. The application may be useful for testing
 RE Manager, troubleshooting issues and simple demos. The :ref:`tutorials <tutorials_queue_server>`
 explore the features of the Queue Server using *qserver* CLI tool.
 
-The *bluesky-widgets* package contains implementations of reusable Qt widgets for controlling RE Manager and 
-manipulating the queue and ready to use *queue-monitor* GUI application based on the widgets.  
+The *bluesky-widgets* package contains implementations of reusable Qt widgets for controlling RE Manager and
+manipulating the queue and ready to use *queue-monitor* GUI application based on the widgets.
 
 Features of Bluesky Queue Server
 --------------------------------
@@ -78,14 +78,14 @@ The core component of the Queue Server is Run Engine (RE) Manager, which support
 - Run Engine (RE) Worker environment, which could be opened/closed/destroyed via API requests. The Bluesky startup code
   is loaded as the environment is opened. The RE Worker process is closed/killed as the environment is closed/destroyed.
 
-- Support for startup code represented in IPython format (a startup directory with alphabetically ordered code files), 
+- Support for startup code represented in IPython format (a startup directory with alphabetically ordered code files),
   as a Python script or a module.
 
-- Fully editable queue of plans and instructions. The API support for adding/replacing/moving/removing individual 
-  queue items and batches of items. The instructions are executed by RE Manager and control execution of the queue. 
+- Fully editable queue of plans and instructions. The API support for adding/replacing/moving/removing individual
+  queue items and batches of items. The instructions are executed by RE Manager and control execution of the queue.
   Only one instruction (`queue_stop`) is currently supported.
 
-- API for controlling execution of the queue (:ref:`start <method_queue_start>`/:ref:`stop <method_queue_stop>` 
+- API for controlling execution of the queue (:ref:`start <method_queue_start>`/:ref:`stop <method_queue_stop>`
   the queue) and the plans (:ref:`pause <method_re_pause>`/:ref:`resume/stop/abort/halt <method_re_resume_stop_abort_halt>`).
 
 - API for monitoring of status of RE Manager, Worker and Run Engine (see :ref:`method_status`)
@@ -96,11 +96,11 @@ The core component of the Queue Server is Run Engine (RE) Manager, which support
 
 - Execute a function defined in RE Worker namespace (see :ref:`method_function_execute`).
 
-- Uploading and executing Python scripts, which may define new or modify existing devices, plans or functions 
+- Uploading and executing Python scripts, which may define new or modify existing devices, plans or functions
   (see :ref:`method_script_upload`).
 
 - Restricting user access to plans and devices. Users may be assigned to groups and each group may restricted in which plans
-  users may submit to the queue and which devices users may pass with plan parameters (see :ref:`managing_user_group_permissions` 
+  users may submit to the queue and which devices users may pass with plan parameters (see :ref:`managing_user_group_permissions`
   and :ref:`configuring_user_group_permissions`).
 
 - Annotations for Bluesky plans (see :ref:`annotating_bluesky_plans`).
@@ -111,7 +111,7 @@ The core component of the Queue Server is Run Engine (RE) Manager, which support
 
 - Encryption of 0MQ control communication channel (fixed public-private key pair).
 
-- Functions for writing startup code compatible with interactive IPython workflow 
+- Functions for writing startup code compatible with interactive IPython workflow
   (see :ref:`organizing_bluesky_startup_code`).
 
 - *qserver* CLI tool for controlling RE Manager (intended for simple operations, system evaluation and demos, see
@@ -130,11 +130,11 @@ from detectors to the File Store. Data acquistion is controlled by local and/or
     :alt: Diagram of Bluesky Queue Server
 
 The Queue Server (started as Run Engine Manager application or service) is running two processes: RE Manager process
-and RE Worker process. RE Manager process is responsible for maintaining and controlling the plan queue and 
+and RE Worker process. RE Manager process is responsible for maintaining and controlling the plan queue and
 0MQ communication with clients. The process is expected to be running for the duration of the session, but it
-can be restarted without closing the application or disrupting queue execution in case of failure. 
-RE Worker process is created as the worker environment is opened and closed/killed when the environment is 
-closed/destroyed. Operations of opening, closing and destroying the environment are controlled using the API 
+can be restarted without closing the application or disrupting queue execution in case of failure.
+RE Worker process is created as the worker environment is opened and closed/killed when the environment is
+closed/destroyed. Operations of opening, closing and destroying the environment are controlled using the API
 and may be performed as often as necessary for the workflow. The Worker process is used to run the Bluesky code.
 
 The queue is stored outside RE Manager (in Redis) and persists between restarts. The local clients (with access to
@@ -144,6 +144,6 @@ All the clients are able to subscribe and remotely monitor the console output of
 
 The Bluesky stack, including Bluesky and Ophyd, is running in RE Worker process. The startup code is loaded into RE Worker
 namespace as the environment is opened, beamline-specific set of devices, plans and functions become available in
-RE Worker namespace and could be started by clients using control API. As the plans are executed, the Ophyd code 
-communicates with EPICS IOCs (to control hardware) over the network and Bluesky code generates documents that are 
+RE Worker namespace and could be started by clients using control API. As the plans are executed, the Ophyd code
+communicates with EPICS IOCs (to control hardware) over the network and Bluesky code generates documents that are
 saved into MongoDB and/or published to Kafka depending on the Run Engine subscriptions.

docs/source/re_manager_api.rst

@@ -779,16 +779,16 @@ Execution     The request initiates the sequence of destroying the environment.
 ============  =========================================================================================
 Method        **'environment_update'**
 ------------  -----------------------------------------------------------------------------------------
-Description   Update the state and cached parameters of the worker environment based on contents of the 
+Description   Update the state and cached parameters of the worker environment based on contents of the
               worker namespace. The updated parameters include the reference to the Run Engine and lists of
-              existing and available plans and devices. The API is intended for using in cases when 
-              users bypass RE Manager to modify contents of the namespace, for example by connecting 
+              existing and available plans and devices. The API is intended for using in cases when
+              users bypass RE Manager to modify contents of the namespace, for example by connecting
               directly to IPython kernel (IPython mode) and executing commands via Jupyter Console.
 ------------  -----------------------------------------------------------------------------------------
 Parameters    **run_in_background**: *boolean* (optional, default *False*)
-                  Set this parameter *True* to execute the update in the background thread (while a plan or 
-                  another foreground task is running). Generally, it is recommended to run the update 
-                  in the main thread. **Developers of data acquisition workflows and/or user specific code 
+                  Set this parameter *True* to execute the update in the background thread (while a plan or
+                  another foreground task is running). Generally, it is recommended to run the update
+                  in the main thread. **Developers of data acquisition workflows and/or user specific code
                   are responsible for thread safety.**
 
               **lock_key**: *str* (optional)
@@ -806,7 +806,7 @@ Returns       **success**: *boolean*
                   is completed (see *task_result* API).
 ------------  -----------------------------------------------------------------------------------------
 Execution     The request initiates the update. The update is not instant, especially if the namespace
-              is large. Monitor 'manager_state' (foreground task) or use 'task_uid' to check if 
+              is large. Monitor 'manager_state' (foreground task) or use 'task_uid' to check if
               the task execution is completed or the update is successful.
 ============  =========================================================================================
 
@@ -2126,13 +2126,13 @@ Description   Send interrupt request (Ctrl-C) to the running IPython kernel. The
               executing a plan or a task. Set the **interrupt_task** and/or **interrupt_plan**
               parameters *True* in order to be able to interrupt a running foreground task or a plan
               (single interrupt initiates deferred pause, two consecutive interrupts initiate immediate
-              pause). Note, that :ref:`method_re_pause` API is more reliable method of pausing the plan. 
+              pause). Note, that :ref:`method_re_pause` API is more reliable method of pausing the plan.
 ------------  -----------------------------------------------------------------------------------------
 Parameters    **interrupt_task**: *boolean* (optional, default: *False*)
                   Allow interrupting a foreground task (e.g. a function or a script) started by RE Manager.
-            
+
               **interrupt_plan**: *boolean* (optional, default: *False*)
-                  Allow interrupting a running plan. By default the API fails if a plan is running in 
+                  Allow interrupting a running plan. By default the API fails if a plan is running in
                   the worker environment (Run Engine is in the *'running'* state), whether the plan
                   was started by RE Manager or by connecting directly to the kernel (e.g. using Jupyter Console).
                   Note, that using :ref:`method_re_pause` API is the preferred way of pausing a running plan