Describe the bug
The Linux (manylinux) wheel for bsk 2.10.2 on PyPI does not include the MuJoCo runtime libraries or Python bindings, whereas the macOS (arm64) wheel of the same version does. As a result, MuJoCo-based functionality is available out of the box on macOS but missing on Linux when installing the same package version via pip.
Inspecting the wheel contents, the macOS wheel ships the full MuJoCo runtime:
Basilisk/libmujocoDynamicsLib.dylib
Basilisk/simulation/_mujoco.so
Basilisk/simulation/mujoco.py
Basilisk/.dylibs/libmujocoDynamicsLib.dylib
Basilisk/.dylibs/libmujoco.3.2.6.dylib
Basilisk/utilities/mujocoUtils/conanfile.py
Basilisk/utilities/mujocoUtils/init.py
while the Linux wheel ships only the empty helper folder, with no _mujoco.so bindings, no libmujocoDynamicsLib, and no libmujoco runtime:
Basilisk/utilities/mujocoUtils/init.py
Basilisk/utilities/mujocoUtils/conanfile.py
To reproduce
Steps to reproduce the behavior:
- On a Linux x86_64 system with Python 3.12, create a virtual environment and run pip install bsk (resolves to bsk-2.10.2).
- Inspect the installed wheel contents, e.g. unzip -l .whl | grep -i mujoco, or attempt to import Basilisk.simulation.mujoco.
- The MuJoCo bindings/runtime are absent on Linux but present when repeating the same steps on macOS arm64.
A quick way to confirm without installing, comparing both wheels side by side:
pip download bsk --no-deps --platform manylinux_2_28_x86_64 --python-version 3.12 --only-binary=:all:
pip download bsk --no-deps --platform macosx_11_0_arm64 --python-version 3.12 --only-binary=:all:
unzip -l bsk-2.10.2-manylinux.whl | grep -i mujoco
unzip -l bsk-2.10.2-macosx.whl | grep -i mujoco
Expected behavior
The Linux wheel should bundle the MuJoCo runtime and bindings (_mujoco.so, libmujocoDynamicsLib, libmujoco) so that MuJoCo functionality is available on the same package version across platforms, or, if Linux MuJoCo support is intentionally not bundled, this should be documented and ideally exposed via an optional extra (e.g. pip install bsk[mujoco]) with a clear error message on import.
Screenshots
N/A, wheel listings included above.
Desktop:
- OS: Linux; compared against MacOS (on Apple Silicon)
- Version Ubuntu 24.04.4; compared against macOS Tahoe 26.3.1
- Python version 3.12.3 (Linux) / 3.12.2 (MacOS)
Additional context
Both installs otherwise resolve to an identical dependency tree and identical package versions; the only meaningful difference is the missing MuJoCo payload in the Linux wheel. It's unclear whether this is an oversight in the Linux build/packaging pipeline or an intentional platform limitation. If the latter, an optional extra plus a documented note would prevent silent confusion.
Describe the bug
The Linux (manylinux) wheel for bsk 2.10.2 on PyPI does not include the MuJoCo runtime libraries or Python bindings, whereas the macOS (arm64) wheel of the same version does. As a result, MuJoCo-based functionality is available out of the box on macOS but missing on Linux when installing the same package version via pip.
Inspecting the wheel contents, the macOS wheel ships the full MuJoCo runtime:
while the Linux wheel ships only the empty helper folder, with no _mujoco.so bindings, no libmujocoDynamicsLib, and no libmujoco runtime:
To reproduce
Steps to reproduce the behavior:
A quick way to confirm without installing, comparing both wheels side by side:
Expected behavior
The Linux wheel should bundle the MuJoCo runtime and bindings (_mujoco.so, libmujocoDynamicsLib, libmujoco) so that MuJoCo functionality is available on the same package version across platforms, or, if Linux MuJoCo support is intentionally not bundled, this should be documented and ideally exposed via an optional extra (e.g. pip install bsk[mujoco]) with a clear error message on import.
Screenshots
N/A, wheel listings included above.
Desktop:
Additional context
Both installs otherwise resolve to an identical dependency tree and identical package versions; the only meaningful difference is the missing MuJoCo payload in the Linux wheel. It's unclear whether this is an oversight in the Linux build/packaging pipeline or an intentional platform limitation. If the latter, an optional extra plus a documented note would prevent silent confusion.