mx-bluesky 1.5.1__tar.gz → 1.5.3__tar.gz

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/.github/workflows/_container.yml

@@ -42,18 +42,39 @@ jobs:
           file: Dockerfile.blueapi
           load: true
 
-      - name: Create tags for publishing image
-        id: meta
+      - name: Create tags for publishing Hyperion image
+        id: meta-hyperion
         uses: docker/metadata-action@v5
         with:
           images: |
             ghcr.io/${{ github.repository }}
+          labels: |
+            org.opencontainers.image.title=mx-bluesky
+            org.opencontainers.image.description=Hyperion service for MX Unattended Data Collection
+          annotations: |
+            org.opencontainers.image.title=mx-bluesky
+            org.opencontainers.image.description=Hyperion service for MX Unattended Data Collection
+          tags: |
+            type=ref,event=tag
+            type=raw,value=latest
+
+      - name: Create tags for publishing BlueAPI image
+        id: meta-blueapi
+        uses: docker/metadata-action@v5
+        with:
+          images: |
             ghcr.io/${{ github.repository }}-blueapi
+          labels: |
+            org.opencontainers.image.title=mx-bluesky-blueapi
+            org.opencontainers.image.description=BlueAPI plans, stubs and utilities for MX beamlines
+          annotations: |
+            org.opencontainers.image.title=mx-bluesky-blueapi
+            org.opencontainers.image.description=BlueAPI plans, stubs and utilities for MX beamlines
           tags: |
             type=ref,event=tag
             type=raw,value=latest
 
-      - name: Push cached image to container registry
+      - name: Push cached Hyperion image to container registry
         if: github.ref_type == 'tag'
         uses: docker/build-push-action@v6
         env:
@@ -64,10 +85,12 @@ jobs:
           context: .
           file: Dockerfile.hyperion
           push: true
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}
+          tags: ${{ steps.meta-hyperion.outputs.tags }}
+          labels: ${{ steps.meta-hyperion.outputs.labels }}
+          # Set the annotations to make the description appear in the GH repo page
+          annotations: ${{ steps.meta-hyperion.outputs.annotations }}
 
-      - name: Push Dockerfile.blueapi image to container registry
+      - name: Push cached BlueAPI image to container registry
         if: github.ref_type == 'tag'
         uses: docker/build-push-action@v6
         env:
@@ -76,5 +99,7 @@ jobs:
           context: .
           file: Dockerfile.blueapi
           push: true
-          tags: ${{ steps.meta.outputs.tags }}
-          labels: ${{ steps.meta.outputs.labels }}
+          tags: ${{ steps.meta-blueapi.outputs.tags }}
+          labels: ${{ steps.meta-blueapi.outputs.labels }}
+          # Set the annotations to make the description appear in the GH repo page
+          annotations: ${{ steps.meta-blueapi.outputs.annotations }}

mx_bluesky-1.5.3/.github/workflows/_helm.yml

@@ -0,0 +1,23 @@
+on:
+  workflow_call:
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Install Helm
+        uses: Azure/setup-helm@v4.3.0
+        id: install
+
+      - name: Helm login to GHCR
+        if: ${{ github.event_name == 'push' && github.ref_type == 'tag' }}
+        run: |
+          echo ${{ secrets.GITHUB_TOKEN }} | helm registry login ghcr.io/${{ github.repository }} --username ${{ github.repository_owner }} --password-stdin
+
+      - name: Package and push chart
+        if: ${{ github.event_name == 'push' && github.ref_type == 'tag' }}
+        run: |
+          helm dependencies update helm/mx-bluesky-blueapi
+          helm package helm/mx-bluesky-blueapi --version ${{ steps.meta.outputs.version }} --app-version ${{ steps.meta.outputs.version }} -d /tmp/
+          helm push /tmp/mx-bluesky-blueapi-${{ steps.meta.outputs.version }}.tgz oci://ghcr.io/diamondlightsource/charts

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/.github/workflows/ci.yml

@@ -38,6 +38,14 @@ jobs:
       contents: read
       packages: write
 
+  helm:
+    needs: container
+    if: needs.check.outputs.branch-pr == ''
+    uses: ./.github/workflows/_helm.yml
+    permissions:
+      contents: read
+      packages: write
+
   docs:
     needs: check
     if: needs.check.outputs.branch-pr == ''

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/.pre-commit-config.yaml

@@ -6,7 +6,7 @@ repos:
         args: ["--maxkb=500"]
       - id: check-yaml
         args: ["--allow-multiple-documents"]
-        exclude: ^helmcharts/
+        exclude: ^helm/
       - id: check-merge-conflict
       - id: end-of-file-fixer
 

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/.vscode/mx-bluesky.code-workspace

@@ -13,6 +13,8 @@
             "editor.defaultFormatter": "ms-python.black-formatter"
         },
         "python.defaultInterpreterPath": ".venv/bin/python",
+        "python.analysis.extraPaths": ["../dodal"],
+        "python.analysis.autoImportCompletions": true,
         "terminal.integrated.gpuAcceleration": "off",
         "esbonio.sphinx.confDir": ""
     }

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/Dockerfile.blueapi

@@ -1,5 +1,7 @@
- # See https://github.com/DiamondLightSource/mx-bluesky/issues/1004
-FROM ghcr.io/diamondlightsource/blueapi:0.10.1
+# Before changing this BlueAPI version number, you should check that 
+# the BlueAPI pin in pyproject.toml is compatible, else the version will
+# be overridden
+FROM ghcr.io/diamondlightsource/blueapi:1.0.0-rc.2
 
 ARG DEBIAN_FRONTEND=noninteractive
 

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mx-bluesky
-Version: 1.5.1
+Version: 1.5.3
 Summary: Bluesky tools for MX Beamlines at DLS
 Author-email: Dominic Oram <dominic.oram@diamond.ac.uk>
 License:                                  Apache License
@@ -235,12 +235,13 @@ Requires-Dist: scipy
 Requires-Dist: semver
 Requires-Dist: deepdiff
 Requires-Dist: matplotlib
-Requires-Dist: blueapi>=0.11.1
-Requires-Dist: daq-config-server==0.1.1
+Requires-Dist: cachetools
+Requires-Dist: daq-config-server>=v1.0.0-rc.2
+Requires-Dist: blueapi>=0.15.0
 Requires-Dist: ophyd>=1.10.5
 Requires-Dist: ophyd-async>=0.10.0a2
 Requires-Dist: bluesky>=1.13.1
-Requires-Dist: dls-dodal==1.51.0
+Requires-Dist: dls-dodal>=1.55.0
 Provides-Extra: dev
 Requires-Dist: black; extra == "dev"
 Requires-Dist: build; extra == "dev"

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/conftest.py

@@ -19,5 +19,5 @@ def pytest_addoption(parser):
 @pytest.fixture(scope="session", autouse=True)
 def default_session_fixture() -> Iterator[None]:
     print("Patching bluesky 0MQ Publisher in __main__ for the whole session")
-    with patch("mx_bluesky.hyperion.__main__.Publisher"):
+    with patch("mx_bluesky.hyperion.runner.Publisher"):
         yield

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/docs/developer/hyperion/deploying-hyperion.rst

@@ -80,6 +80,16 @@ are not already present:
 * ``rmq-creds``
 * ``rmq-api-reader``
 
+In addition, an ispyb credentials secret must be created with the following name:
+* ``ispyb-hyperion-cfg``
+
+
+For creating the secrets, use ``kubectl create secret``:
+
+::
+
+    kubectl create secret -n i03-beamline generic ispyb-hyperion-cfg --from-file=ispyb.cfg=<path-to-ispyb-hyperion-ixx.cfg>
+
 Production deployment
 ~~~~~~~~~~~~~~~~~~~~~
 

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/docs/developer/hyperion/reference/coordinate-systems.rst

@@ -20,7 +20,7 @@ defined by ``rotation_direction`` which can be ``POSITIVE`` or ``NEGATIVE``
 
 The coordinate systems of the underlying hardware may differ from the request. At Diamond traditionally the omega 
 axis is implemented to be in the opposite direction, therefore the commands sent to the hardware are transformed and 
-the ``omega_flip`` feature flag controls this behaviour, which by default is set to ``True`` as this is 
+the ``omega_flip`` flag controls this behaviour, which by default is set to ``True`` as this is 
 generally expected to be required for the beamlines here.
 
 In the Nexus output file, there is provision for describing the choice of axis orientations in the nexus file, and 

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/docs/index.rst

@@ -16,7 +16,14 @@ The documentation consists of a Developer Guide for MX-Bluesky, which also inclu
 
         The Developer Guide contains documentation on how to install, develop and contribute changes to MX-Bluesky; explanations about the purpose of the software and some of the technical concepts; as well as how-to guides and tutorials.
 
+    .. grid-item-card:: :material-regular:`code;4em`
+        :link: user/hyperion/index
+        :link-type: doc
+
+        The User Guide for the Hyperion UDC Service
+
 .. toctree::
     :hidden:
 
     developer/index
+    user/hyperion/index

mx_bluesky-1.5.3/docs/user/hyperion/alerts.rst

@@ -0,0 +1,68 @@
+Alerts
+------
+
+Hyperion can be configured to raise  in order to notify staff of issues with data collections or with Hyperion 
+itself.
+
+The currently supported alerting backend uses graylog alerting to send email alert notifications.
+
+Graylog Alert Configuration
+===========================
+
+When hyperion generates an alert it will generate the alert in the form of a log message that will be logged to graylog
+in the normal way.
+
+The log message will have the message ``***ALERT*** summary=<summary> content=<content>`` and will have the following 
+metadata as fields in the log message.
+
+.. csv-table:: Log message fields
+    :widths: auto
+    :header: "Field", "Description"
+
+    "alert_summary", "A single line summary of the alert, that could e.g. be used in an email summary"
+    "alert_content", "The plain text body of the alert message"
+    "beamline", "Beamline on which the alert was raised"
+    "container", "Container ID that was being processed"
+    "ispyb_url", "Link to the ISPyB page of the affected sample"
+    "graylog_url", "Link to the graylog stream in the minutes up to the event"
+    "proposal", "Proposal that was being processed"
+    "sample_id", "Sample ID that was being processed"
+    "visit", "Visit that was being processed"
+
+
+In order to configure alerts in Graylog you will need appropriate Graylog permissions to edit Event Definitions and 
+Notifications.
+
+Event Definitions define which log messages will trigger a Graylog Event, and the information that is contained in 
+the event.
+
+Notifications are triggered by a Graylog Event and define how the information in the event is dispatched to the 
+recipient(s).
+
+For the authoritative Graylog documentation, please see https://go2docs.graylog.org/current/interacting_with_your_log_data/alerts.html
+
+Notification Configuration
+--------------------------
+
+Go to the Alerts->Notifications tab in Graylog, you should see a searchable list of notifications, clicking on the 
+notification you want to edit and click the "Edit Notification" button.
+
+For an email notification, you can edit the subject, recipients, and the plain-text and HTML body.
+
+Inside the subject and body fields, you can include metadata from the event, for example ``${event.timestamp}`` will 
+expand to the event timestamp. 
+
+All the fields that are available in the event are available under the ``event.fields`` object, e.g. ``${event.fields.alert_summary}``
+
+Event Definitions
+-----------------
+
+In order to access fields from the log message, including the ones explicitly added by Hyperion and also any other 
+ones that graylog appends to the message, you must configure the Event Definition.
+
+To configure the Event Definition, go to the Alerts->Event Definitions tab and click on the notification definition, 
+then click "Edit Event Definition".
+
+Under Filter & Aggregation you can configure the conditions under which an event will be generated.
+Under Fields you can add custom fields to the event, for each additional field that you want to use in the 
+notification, you should click Add Custom Field, then populate the fields, see the existing definitions as a guide.

mx_bluesky-1.5.3/docs/user/hyperion/configuration.rst

@@ -0,0 +1,25 @@
+Configuration
+-------------
+
+Configuration of several properties that control Hyperion execution are available. These can be edited in the 
+``domain.properties`` file typically found in
+
+::
+
+    /dls_sw/<beamline>/software/daq_configuration/domain.properties
+
+
+.. csv-table:: Configuration properties
+    :widths: auto
+    :header: "Property Name", "Type", "Description"
+
+    "gda.gridscan.hyperion.flaskServerAddress", "host:port", "Configures the Hyperion server address that GDA connects to."
+    "gda.gridscan.hyperion.multipin", "boolean", "Controls whether multipin collection is enabled."
+    "gda.hyperion.use_grid_snapshots_for_rotation", "boolean", "If true, then rotation snapshots are generated from the grid snapshots instead of directly capturing them"
+    "gda.mx.hyperion.enabled",  "boolean",  "Controls whether GDA invokes Hyperion or performs collection itself"
+    "gda.mx.hyperion.panda.runnup_distance_mm", "double", "Controls the panda runup distance."
+    "gda.mx.hyperion.xrc.box_size", "double", "Configures the grid scan box size in microns."
+    "gda.mx.hyperion.use_panda_for_gridscans", "boolean", "If true then the Panda is used instead of the Zebra for XRC gridscans" 
+    "gda.mx.hyperion.xrc.use_gpu_results", "boolean", "If true, then zocalo gridscan processing uses the GPU results"
+    "gda.mx.hyperion.xrc.use_roi_mode", "boolean", "If true then ROI mode is used."
+    "gda.mx.udc.hyperion.enable", "boolean",  "Enables baton passing to Hyperion."

mx_bluesky-1.5.3/docs/user/hyperion/index.rst

@@ -0,0 +1,25 @@
+Hyperion User Guide
+===================
+
+The Hyperion User Guide describes how to run, configure and troubleshoot Hyperion. For installation instructions, see
+the Developer Guide.
+
+What is Hyperion?
+-----------------
+
+Hyperion is a service for running high throughput unattended data collection (UDC). It does not provide a user 
+interface, instead instructions are pulled from Agamemnon which is controlled by information obtained in ISPyB.
+
+Running Hyperion
+----------------
+
+When installed, Hyperion should be running automatically. If it is not running, it can be (re)started from GDA by 
+invoking ``hyperion_restart()`` from the Jython console.
+
+
+.. toctree::
+    :caption: Topics
+    :maxdepth: 1
+    :glob:
+
+    *

mx_bluesky-1.5.3/docs/user/hyperion/logging.rst

@@ -0,0 +1,41 @@
+Logging
+-------
+
+Hyperion logs to a number of different locations. The sections below describe the locations that are configured via 
+environment variables for a standard server install; for kubernetes deployments please check the deployment 
+``values.yaml`` for the configured locations. 
+
+Graylog
+~~~~~~~
+
+Graylog is the recommended way to view logs. It is used for more centralised logging which is also more easily 
+searched and archived. Log messages are sent to the `Hyperion graylog stream <https://graylog.diamond.ac.uk/streams/66264f5519ccca6d1c9e4e03/search>`_.
+
+
+Startup Log
+~~~~~~~~~~~
+
+When ``hyperion_restart()`` is called by GDA, it will log the initial console output to a log file. This log file 
+location is 
+controlled by the ``gda.logs.dir`` property and is typically ``/dls_sw/<beamline>/logs/bluesky``.
+
+On kubernetes deployments, the initial startup is sent to standard IO and is captured as part of the standard 
+kubernetes logging facility.
+
+Log files
+~~~~~~~~~
+
+By default, Hyperion logs to the filesystem.
+
+The log file location is controlled by the ``LOG_DIR`` environment value. Typically this can be found in 
+``/dls_sw/<beamline>/logs/bluesky``
+
+Debug Log
+~~~~~~~~~
+
+The standard logs files do not record all messages, only those at INFO level or higher, in order to keep storage 
+requirements to a minimum. 
+In the event of an error occurring, then trace-level logging for the most recent events (by default 5000) is flushed 
+to a separate set of log files. Due to the size of these files, they are stored separately from the main log files
+. These logs are located in ``/dls/tmp/<beamline>/logs/bluesky`` by default, or 
+otherwise as specified by the ``DEBUG_LOG_DIR`` environment variable.  

mx_bluesky-1.5.3/docs/user/hyperion/pvs.rst

@@ -0,0 +1,12 @@
+Special PVs
+-----------
+
+Baton
+~~~~~
+
+In order to arbitrate access to the beamline between Hyperion and GDA there are two baton string PVs REQUESTED_USER and 
+CURRENT_USER.
+
+Hyperion will only start operating once REQUESTED_USER has been set to Hyperion, at which point it will set 
+CURRENT_USER. To request the baton from Hyperion, set REQUESTED_USER to some other value, when Hyperion completes the
+current action, it will relinquish CURRENT_USER.

{mx_bluesky-1.5.1/helmcharts → mx_bluesky-1.5.3/helm}/hyperion/templates/deployment.yaml

@@ -68,48 +68,13 @@ spec:
                 name: {{ .secretName }}
             {{- end -}} {{/* range */}}
             {{- end -}} {{/* if */}}
+        - name: ispyb-secrets
+          secret:
+            type: secret
+            secretName: ispyb-hyperion-cfg
       containers:
       - name: hyperion
-        image: {{ .Values.application.imageRepository}}/mx-bluesky:{{ .Values.application.appVersion }}
-        securityContext:
-          capabilities:
-            # Required for hostNetwork 
-            drop:
-              - AUDIT_WRITE
-              - CHOWN
-              - DAC_OVERRIDE
-              - FOWNER
-              - FSETID
-              - KILL
-              - MKNOD
-              - NET_BIND_SERVICE
-              - NET_RAW
-              - SETFCAP
-              - SETGID
-              - SETPCAP
-              - SETUID
-              - SYS_CHROOT
-              - AUDIT_CONTROL
-              - BLOCK_SUSPEND
-              - DAC_READ_SEARCH
-              - IPC_LOCK
-              - IPC_OWNER
-              - LEASE
-              - LINUX_IMMUTABLE
-              - MAC_ADMIN
-              - MAC_OVERRIDE
-              - SYS_ADMIN
-              - SYS_BOOT
-              - SYS_MODULE
-              - SYS_NICE
-              - SYS_PACCT
-              - SYS_MODULE
-              - SYS_PTRACE
-              - SYS_RESOURCE
-              - SYS_TIME
-              - SYS_TTY_CONFIG
-              - SYSLOG
-              - WAKE_ALARM            
+        image: {{ .Values.application.imageRepository}}/mx-bluesky:{{ .Values.application.appVersion }}    
         resources:
           limits:
             cpu: "1"
@@ -133,7 +98,7 @@ spec:
           - name: ZOCALO_CONFIG
             value: "/zocalo/config/configuration.yaml"
           - name: ISPYB_CONFIG_PATH
-            value: "/dls_sw/dasc/mariadb/credentials/ispyb-hyperion-{{ .Values.application.beamline }}.cfg"
+            value: "/ispyb/secrets/ispyb.cfg"
           {{- end }}
         readinessProbe:
           exec:
@@ -166,4 +131,6 @@ spec:
             name: zocalo-config
           - mountPath: "/zocalo/secrets"
             name: zocalo-secrets
+          - mountPath: "/ispyb/secrets"
+            name: ispyb-secrets
       hostNetwork: true

{mx_bluesky-1.5.1/helmcharts → mx_bluesky-1.5.3/helm}/hyperion/values.yaml

@@ -9,7 +9,7 @@ application:
   beamline: i03
   dev: false
   logDir: "/dls_sw/i03/logs/bluesky/hyperion-k8s"
-  debugLogDir: "/dls/tmp/i03/logs/bluesky"
+  debugLogDir: "/dls/tmp/i03/logs/bluesky-k8s"
   dataDir: "/dls/i03/data"
   # These should be overridden at install time
   projectDir: SET_ON_INSTALL

mx_bluesky-1.5.3/helm/mx-bluesky-blueapi/Chart.yaml

@@ -0,0 +1,16 @@
+apiVersion: v2
+name: mx-bluesky-blueapi
+description: A helm chart deploying a worker pod that runs Bluesky plans
+
+# This chart provides extra configuration to a BlueAPI application which is generic to all MX beamlines,
+# and does not startup an application by itself. A BlueAPI service in ixx-services should add this chart
+# as a dependency. It currently mounts zocalo and ispyb credentials as config maps, with the assumption 
+# that the beamline cluster have these secrets available. In the future, this helmchart may change to a 
+# library type
+type: application
+
+# This is the chart version. This version number should be incremented each time you make changes
+# to the chart and its templates, including the app version.
+# Versions are expected to follow Semantic Versioning (https://semver.org/)
+# This is updated automatically by CI, the appVersion is automatically inserted by CI
+version: 0.1.1

mx_bluesky-1.5.3/helm/mx-bluesky-blueapi/templates/zocalo-config.yaml

@@ -0,0 +1,38 @@
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: "zocalo-config"
+  namespace: "{{ .Release.Namespace }}"
+  labels:
+    app.kubernetes.io/name: zocalo-config
+    app.kubernetes.io/instance: "{{ .Release.Name }}-zocalo-config"
+    app.kubernetes.io/version: "{{ .Chart.Version }}"
+    app.kubernetes.io/part-of: mx-bluesky-blueapi 
+data:
+  configuration.yaml: |-
+    version: 1
+    graylog:
+      plugin: graylog
+      {{- .Values.zocalo.graylog | toYaml | nindent 6 }}
+  {{- if .Values.zocalo.secrets }}
+  {{- range .Values.zocalo.secrets }}
+    {{ .name }}: "/zocalo/secrets/{{ .fileName }}"
+  {{- end -}} {{/* range */}}
+  {{- end -}} {{/* if */}}
+
+
+    default-transport:
+      plugin: transport
+      default: {{ .Values.zocalo.defaultTransport }}
+
+    environments:
+
+      bluesky:
+        logging: graylog
+        plugins:
+          - default-transport
+        {{- if .Values.zocalo.secrets }}
+        {{- range .Values.zocalo.secrets }}
+          - {{ .name }}
+        {{- end -}} {{/* range */}}
+        {{- end -}} {{/* if */}}

mx_bluesky-1.5.3/helm/mx-bluesky-blueapi/values.yaml

@@ -0,0 +1,13 @@
+zocalo:
+  defaultTransport: "PikaTransport"
+  graylog:
+    host: graylog-log-target.diamond.ac.uk
+    port: 12208
+    protocol: UDP
+  secrets:
+    - name: rabbitmq
+      secretName: rmq-creds
+      fileName: rabbitmq-credentials.yml
+    - name: rabbitmq-api-reader
+      secretName: rmq-api-reader
+      fileName: rabbitmq-api-reader.yml

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/pyproject.toml

@@ -38,16 +38,17 @@ dependencies = [
     "semver",
     "deepdiff",
     "matplotlib",
+    "cachetools",
     #
     # These dependencies may be issued as pre-release versions and should have a pin constraint
     # as by default pip-install will not upgrade to a pre-release.
     #
-    "blueapi >= 0.11.1",
-    "daq-config-server == 0.1.1",
+    "daq-config-server>=v1.0.0-rc.2",
+    "blueapi >= 0.15.0",
     "ophyd >= 1.10.5",
     "ophyd-async >= 0.10.0a2",
     "bluesky >= 1.13.1",
-    "dls-dodal == 1.51.0",
+    "dls-dodal >= 1.55.0",
 ]
 
 
@@ -94,8 +95,6 @@ run_extruder = "mx_bluesky.beamlines.i24.serial.run_serial:run_extruder"
 run_fixed_target = "mx_bluesky.beamlines.i24.serial.run_serial:run_fixed_target"
 hyperion = "mx_bluesky.hyperion.__main__:main"
 hyperion-callbacks = "mx_bluesky.hyperion.external_interaction.callbacks.__main__:main"
-hyperion-generate-test-nexus = "mx_bluesky.hyperion.utils.validation:generate_test_nexus"
-hyperion-populate-test-and-meta-files = "mx_bluesky.hyperion.utils.validation:copy_test_meta_data_files"
 redis_to_murko = "mx_bluesky.beamlines.i04.redis_to_murko_forwarder:main"
 
 [project.urls]
@@ -122,6 +121,7 @@ markers = [
     "skip_log_setup: marks tests so that loggers are not setup before the test.",
     "skip_in_pycharm: marks test as not working in pycharm testrunner",
     "system_test: marks tests as a system test",
+    "requires: marks a test as having an external dependency such as a service or hardware",
 ]
 addopts = """
     --tb=native -vv --doctest-modules --doctest-glob="*.rst" --durations=10
@@ -142,6 +142,8 @@ filterwarnings = [
     # Ignore warning about deprecations in python-workflows encountered during system tests
     # https://github.com/DiamondLightSource/python-workflows/issues/188
     "ignore:.*`Field` should not be instantiated.*:marshmallow.warnings.ChangedInMarshmallow4Warning",
+    #Remove when we drop python 3.11
+    "ignore:.*__contains__ will no longer raise TypeError.*:DeprecationWarning",
 ]
 # Doctest python code in docs, python code in src docstrings, test functions in tests
 testpaths = "docs src tests/unit_tests"
@@ -248,5 +250,15 @@ modules = "mx_bluesky.beamlines.*"
 [[tool.importlinter.contracts]]
 name = "Beamlines do not import from hyperion"
 type = "forbidden"
-source_modules = "mx_bluesky.beamlines.*"
-forbidden_modules = "mx_bluesky.hyperion"
+source_modules = "mx_bluesky.beamlines.**"
+forbidden_modules = "mx_bluesky.hyperion.**"
+
+[[tool.importlinter.contracts]]
+name = "Only Hyperion and i04 can import from phase1_zebra"
+type = "forbidden"
+source_modules = ["mx_bluesky.beamlines.**", "mx_bluesky.common.**"]
+forbidden_modules = ["mx_bluesky.phase1_zebra.**"]
+ignore_imports = [
+    "mx_bluesky.beamlines.i04.** -> mx_bluesky.phase1_zebra.**",
+    "mx_bluesky.hyperion.** -> mx_bluesky.phase1_zebra.**",
+]

{mx_bluesky-1.5.1 → mx_bluesky-1.5.3}/src/mx_bluesky/_version.py

@@ -1,7 +1,14 @@
 # file generated by setuptools-scm
 # don't change, don't track in version control
 
-__all__ = ["__version__", "__version_tuple__", "version", "version_tuple"]
+__all__ = [
+    "__version__",
+    "__version_tuple__",
+    "version",
+    "version_tuple",
+    "__commit_id__",
+    "commit_id",
+]
 
 TYPE_CHECKING = False
 if TYPE_CHECKING:
@@ -9,13 +16,19 @@ if TYPE_CHECKING:
     from typing import Union
 
     VERSION_TUPLE = Tuple[Union[int, str], ...]
+    COMMIT_ID = Union[str, None]
 else:
     VERSION_TUPLE = object
+    COMMIT_ID = object
 
 version: str
 __version__: str
 __version_tuple__: VERSION_TUPLE
 version_tuple: VERSION_TUPLE
+commit_id: COMMIT_ID
+__commit_id__: COMMIT_ID
 
-__version__ = version = '1.5.1'
-__version_tuple__ = version_tuple = (1, 5, 1)
+__version__ = version = '1.5.3'
+__version_tuple__ = version_tuple = (1, 5, 3)
+
+__commit_id__ = commit_id = 'gd31a95a33'

mx_bluesky-1.5.3/src/mx_bluesky/beamlines/i04/__init__.py

@@ -0,0 +1,10 @@
+from mx_bluesky.beamlines.i04.experiment_plans.i04_grid_detect_then_xray_centre_plan import (
+    i04_grid_detect_then_xray_centre,
+)
+from mx_bluesky.beamlines.i04.thawing_plan import thaw, thaw_and_stream_to_redis
+
+__all__ = [
+    "thaw",
+    "thaw_and_stream_to_redis",
+    "i04_grid_detect_then_xray_centre",
+]