Bug Report

Current Behavior

The User Guide currently gives the following example code:

from blazingmq

def on_ack_callback(ack):
    if ack.status != blazingmq.AckStatus.SUCCESS:
        print("Post failed")
    print("Post success")

session.post(queue_uri, b"Some message here", on_ack=on_ack_callback)

The first line is syntactically invalid.

Expected behavior/code

The first line should be an import, import blazingmq.

We cannot automatically build and host this package's documentation on release, because the documentation is currently hosted on the main bloomberg/blazingmq repository. This means that every time we update the documentation for this package, we have to manually file a PR against that repository, have it reviewed, and have it merged into the main repo. The process would be much simpler if we instead build and deploy the documentation within our GitHub Actions workflow on each release, publishing to our own repo's GitHub pages.

libbmq provides bmqa::MessageEventBuilder to batch multiple messages into a single message event. However, pybmq_session does not expose any API for batching messages, creating a new bmqa::MessageEventBuilder for each posted message. For parity with libbmq, we should expose the ability to batch messages somehow.

Since the initial creation of the BlazingMQ Python SDK, the C++ libbmq has gained a few additional SessionOptions that users can configure. We should expose these through in the Python bindings, allowing users of the Python SDK to configure them.

Our Python SDK makes use of type annotations throughout, but currently we do not check that these annotations are correct. Using mypy, we can check these type annotations statically. This is a good candidate for our CI checks, along with our other linters.

We have some minor typechecking errors in the codebase, especially relating to covariance, which should be fixed along with this.

We still support Python 3.7, which Cython 3 does not support, but for all interpreters later than this, we should support Cython 3 in our builds.

This repository's CI checks perform extensive linting, documentation checks, and testing, much of which can be done locally. It can be tricky to remember what of these must be done before opening the PR. We can document these steps in CONTRIBUTING.md, which also discusses the DCO checks.

Bug Report

In this section of the docs/BUILD.md file
https://github.com/bloomberg/blazingmq-sdk-python/blob/main/docs/BUILD.md#local-development-with-docker
there's a description of a Dockerfile and a docker/docker-compose.yaml file but neither exist in the repo.

Expected behavior/code

Either the files should exist, or that section of the documentation should be removed.

When running the build-wheels.yml GitHub Action, we see warnings about using out-of-date steps, which use Node.js 16. We should instead use later versions of these GitHub Actions steps, which use the newer Node.js version 20, where possible.

Bug Report

I performed the following search in the Blazing MQ documentation: https://bloomberg.github.io/blazingmq/docs/apidocs/python_apidocs/search.html?q=thread&check_keywords=yes&area=default

The synopsis for each match is a file not found error message. But the link to the document works. Below is sample text from the search results.

Search Results

Search finished, found 3 page(s) matching the search query.

Examples
...Page not foundThe page you requested could not be found. Try using the navigation or search to find what you're looking for or go to this site's home page.Back to topCopyright © 2023 Bloomberg

blazingmq
...Page not foundThe page you requested could not be found. Try using the navigation or search to find what you're looking for or go to this site's home page.Back to topCopyright © 2023 Bloomberg

This should be reproducible with the link above.

Expected behavior/code

To only display the error if there's an actual error.

While users of the package can use pre-built wheels, anyone who wants to develop this package needs to have an intricate (and poorly documented) setup with each of the third-party dependencies this package requires.

One way around this would be to provide a Docker setup that builds the third-party dependencies and which sets up a local broker for testing.