liboqs-python automaticaly installs liboqs v14 but v15 is available

[Raphael2b3]

Hello there,

Since i need SLH-DSA in my python projekt (which was added in v15 in liboqs).

Let liboqs-python install liboqs automatically
If liboqs is not detected at runtime by liboqs-python, it will be downloaded, configured and installed automatically (as a shared library). This process will be performed only once, at runtime, i.e., when loading the liboqs-python wrapper. The liboqs source directory will be automatically removed at the end of the process.

This is convenient in case you want to avoid installing liboqs manually, as described in the subsection above.

I wanted to let liboqs-python install liboqs automaticly, to reduce complexitiy in my project.

[wock9000]

Hit this on macOS today. The concrete failure mode for anyone searching: liboqs-python==0.14.1's auto-installer tries git clone --branch 0.14.1 https://github.com/open-quantum-safe/liboqs and fails with

fatal: Remote branch 0.14.1 not found in upstream origin
Error installing liboqs.
RuntimeError: No oqs shared libraries found

The upstream liboqs repo only has 0.14.0, 0.15.0, 0.15.0-rc1, 0.15.0-rc2 tags — no 0.14.1. Looks like OQS_VERSION = oqs_python_version() in oqs/oqs.py derives the C-library tag from the Python package's own version, which has drifted from the C library's release cadence.

macOS-specific gotcha while we're here: brew install liboqs ships static-only (liboqs.a, no .dylib), so the brew path doesn't help. Manual source build is the only option until a Python-side 0.15.x release lands:

git clone --depth 1 --branch 0.15.0 https://github.com/open-quantum-safe/liboqs /tmp/liboqs
cmake -S /tmp/liboqs -B /tmp/liboqs/build -DBUILD_SHARED_LIBS=ON \
    -DCMAKE_INSTALL_PREFIX=$HOME/_oqs -DOQS_BUILD_ONLY_LIB=ON
cmake --build /tmp/liboqs/build -j && cmake --install /tmp/liboqs/build
export OQS_INSTALL_PATH=$HOME/_oqs

Verified: liboqs-python 0.14.1 runs cleanly against liboqs 0.15.0 for ML-DSA-65 keygen/sign/verify — only a non-fatal UserWarning about the (0.14.1 vs 0.15.0) mismatch prints. Suggests pinning the Python-side OQS_VERSION to the latest known-existing upstream tag (0.15.0) rather than the Python package's own version would fix this for everyone until the release cycles re-sync. Happy to send a PR if it'd be useful.

[dstebila]

I'm working to prepare the repository for a new release, to match the forthcoming liboqs 0.16.0 due hopefully by the end of the month. In preparation for that I've been making a variety of updates, including pulling code from an old PR, #132, that would introduce an environment variable to allow for overriding the liboqs version; see #140.

[dstebila]

Resolved. As of #140 (merged), you can override the auto-installed liboqs version via the PYOQS_VERSION env var — e.g. PYOQS_VERSION=0.15.0 (or latest) — so you can pull in SLH-DSA without waiting. The upcoming 0.16.0 release will also bump the default to liboqs 0.16.0. Thanks for the report!

[wock9000]

Appreciated @dstebila, have a great day