[BUG] Unable to install with only wheels due to py-ubjson dependency

[norrisjeremy]

Bug Description

Summary: Unable to install with only wheels due to py-ubjson dependency

Expected Behavior:
Be able to download wheels for autobahn and all it's declared dependencies, and thus be able to install without any source code based installation requirements.

Actual Behavior:
Unable to accomplish this due to unconditional dependency on py-ubjson that was added in 25.12.1 (since py-ubjson does not provide a wheel).

Reproduction Steps

Execute:

pip download autobahn==25.12.2 -d /wheels --platform manylinux_2_34_aarch64 --platform manylinux_2_28_aarch64 --platform manylinux_2_17_aarch64 --platform manylinux2014_aarch64 --only-binary :all:

Minimal Reproducible Example:
Execute:

pip download autobahn==25.12.2 -d /wheels --platform manylinux_2_34_aarch64 --platform manylinux_2_28_aarch64 --platform manylinux_2_17_aarch64 --platform manylinux2014_aarch64 --only-binary :all:

Environment

• Package: autobahn-python
• Version: 25.12.2
• Python Version: CPython 3.13
• Operating System: Ubuntu 25.10 & 26.04 on aarch64 (arm64)
• Framework: n/a

Additional Context

Error Messages:

ERROR: Could not find a version that satisfies the requirement py-ubjson>=0.16.1 (from autobahn) (from versions: none)
ERROR: No matching distribution found for py-ubjson>=0.16.1

Relevant Logs:

n/a

Screenshots:

Related Issues:
Seems related to b063660?

Checklist

• I have searched existing issues to avoid duplicates
• I have provided a minimal reproducible example
• I have included version information
• I have included error messages/logs

[norrisjeremy]

FYI, this also applies to x86_64 in addition to aarch64 (arm64):

pip download autobahn==25.12.2 -d /wheels --platform manylinux_2_34_x86_64 --platform manylinux_2_28_x86_64 --platform manylinux_2_17_x86_64 --platform manylinux2014_x86_64 --only-binary :all:

ERROR: Could not find a version that satisfies the requirement py-ubjson>=0.16.1 (from autobahn) (from versions: none)
ERROR: No matching distribution found for py-ubjson>=0.16.1

[norrisjeremy]

Also, the py-ubjson project appears to be dormant/abandoned, so it seems questionable to include it as a mandatory dependency.

[norrisjeremy]

Also, the py-ubjson project appears to be dormant/abandoned, so it seems questionable to include it as a mandatory dependency.

As evidence, Iotics-Labs (the organization responsible for py-ubjson) appears to be abandoned: their domain (iotics.com) is no longer registered (see https://www.afternic.com/forsale/iotics.com), and no updates appear to have been made to any of the organization's Github repos since 2024.

Additionally, a former developer for py-ubjson seems to intimate in an open PR for the project (Iotic-Labs/py-ubjson#21 (comment)) that they no longer have write access to the Github repo, and seems to be encouraging folks to make their own forks of the project.

[oberstet]

Hi @norrisjeremy, thanks again for the detailed report. This is a valid issue — good catch.

Root Cause

In v24.4.2 and earlier, py-ubjson was an optional dependency under the [serialization] extra — users had to explicitly install autobahn[serialization] to get UBJSON support.

During the v25.x modernization (migration from setup.py to pyproject.toml with hatchling), all WAMP serializers were moved into core dependencies as part of a "batteries included" strategy. This inadvertently made py-ubjson a hard/mandatory dependency.

The problem is that py-ubjson has never published any wheel in any version — it only provides a source distribution with a C extension. Combined with the project being abandoned (as you've correctly identified), this creates the installation failure you're seeing.

Impact on Testing

This is worth noting: autobahn has comprehensive WAMP serialization testing that includes UBJSON across all dimensions:

• Serializer availability checks (just check-serializers) that verify all 5 serializers (json, msgpack, cbor, ubjson, flatbuffers) are available
• Single-serializer roundtrip tests that verify construct → serialize → deserialize → validate for each serializer
• Cross-serializer preservation tests that verify message fidelity when deserializing with one serializer and re-serializing with another (all N×N pairs including ubjson ↔ cbor, ubjson ↔ msgpack, etc.)
• Conformance test vectors from the WAMP protocol specification that include UBJSON byte representations

So we can't simply drop UBJSON support without adjusting the test infrastructure — but we can make it optional again.

On py-ubjson Being Abandoned

You're right that py-ubjson (Iotic Labs) appears abandoned (last PyPI upload: April 2020, domain expired, maintainers lost repo access).

There is one potential successor: bjdata (PyPI: bjdata, latest release: v0.6.6, January 2026). It's a fork of py-ubjson that:

• Was forked from py-ubjson and preserves the same Apache 2.0 license
• Has the same API pattern (dumpb()/loadb()/dump()/load())
• Extends UBJSON Draft-12 with BJData Draft-4 (adds uint16/uint32/uint64/float16/byte types)
• Is actively maintained (funded by NIH grant U24-NS124027)
• Supports Python 3.2+ through 3.13
• Has optional C extension (can be disabled with PYBJDATA_NO_EXTENSION=1)

However, bjdata also only publishes sdist (no wheels), and it imports as bjdata not ubjson, so it wouldn't be a drop-in replacement without a code change in autobahn's serializer.

Proposed Fix

The immediate fix is to move py-ubjson from core dependencies back to an optional extra, restoring the pre-v25.x behavior:

# pyproject.toml
dependencies = [
    ...
    # py-ubjson removed from core deps
]

[project.optional-dependencies]
serialization = [
    "py-ubjson>=0.16.1",
]

The serializer code in autobahn/wamp/serializer.py already handles this gracefully — it uses try: import ubjson / except ImportError: pass and simply doesn't register the UBJSON serializer if the package isn't installed. All other serializers (JSON, MessagePack, CBOR, FlatBuffers) have proper wheel support and will remain as core dependencies.

The CI/CD checks (check-serializers) and cross-serializer tests will continue to test UBJSON in CI where it's installed from source, but end-users doing pip install autobahn won't be blocked by it.

As a longer-term consideration, we may evaluate switching to bjdata or simply deprecating UBJSON in favor of CBOR (which has excellent wheel coverage via cbor2) and FlatBuffers (which is vendored with zero external dependency). But that's a separate discussion.

We'll address the immediate dependency issue in the next release.

[norrisjeremy]

Hi @oberstet,

Thanks for the detailed response!

Thanks,
Jeremy

[oberstet]

great! fwiw, couple more comments, as I'm at my keys:

However, bjdata also only publishes sdist (no wheels), ...

IMO, this should be fixed upstream. Plus: the C extension should then be CFFI based not CPyExt, to make PyPy happy. But that's upstream's decision, and I am not going to vendor it (like I did for LMDB and Flatbuffers;)

In the meantime, if we move to bjdata, we should recommend/assume PYBJDATA_NO_EXTENSION=1. On PyPy, it'll be faster via JIT'ting than good-old gcc likely anyways.

But on the other hand / generally: WAMP users should use JSON, CBOR or Flatbuffers anyways;) I don't care much about UBJSON.

[norrisjeremy]

Hi @oberstet,

The only other comment I would have about keep py-ubjson, but as an optional dependency:
I'm unsure what PyPI's standards are for somebody gaining control of Iotic Labs defunct domain and then using that to gain control of their PyPI project and then being able to publish potentially malicious or trojan'd versions of py-ubjson.
I just wanted to point that out in case their could be security ramifications with maintaining it even as an optional dependency.

Thanks!
Jeremy

[jbsilva]

As can be seen in PioneersHub/pyconde-talks@0400805, my temporary solution was to add override-dependencies = ["py-ubjson>=0.16.1; sys_platform == 'nowhere'"] in pyproject.toml.

This was the only dependency without wheels in my project.
Removing it simplified things and increased security (use uv --no-build, no build-base in Docker, etc.)