RAI declares version 1.0.0 in pyproject while its releases are tagged 2.12.4

pyproject declares 1.0.0 while the release tags read 2.12.4

The packaging metadata and the release history do not agree about what version this project is. The project file names the distribution rai_framework and carries the single line `version = "1.0.0"`. The repository's release tags are 2.12.4, 2.12.3 and 2.12.2. Two other details sharpen the gap. The classifier block calls the project Beta, which a 1.0.0 number and a 2.12.x tag can both sit next to without explaining which is meant to be authoritative. And the same file sets package = false under tool.uv, so uv is told not to build the root project itself at all. That makes the version string close to decorative: it is not what a user installs, because there is nothing here to install, and it is not what the release history calls the same artifact. All three tags also carry the same date, 2026-09-08, with the last two published 33 minutes apart, so the 2.12.x numbering reads as a rapid patch cycle against a project whose own metadata still says 1.0.0.

The runtime dependency list carries pre-commit, pytest and coverage

The dependencies block mixes what the framework needs to run with what the project needs to develop it. Seven entries are pinned with a ceiling on the next major version: `rai_core`, `rai_whoami`, `pre-commit>=3.7.0,<4.0.0`, `tabulate>=0.9.0,<0.10.0`, `pytest>=8.2.0,<9.0.0`, `pytest-timeout>=2.3.1,<3.0.0` and `pytest-cov>=7.0.0,<8.0.0`. Only two of them, rai_core and rai_whoami, are packages the framework uses at runtime, and tabulate is a formatting helper. The other four are development machinery: a hook runner, the test framework, its timeout plugin and the coverage plugin. Anyone installing rai_framework onto a robot or a container therefore pulls a test runner and a pre-commit runner into the production dependency closure, whether or not they ever run the project's own suite. The bounds are narrow and deliberate, each capped below its next major, which is the discipline you would expect from a project that ships a pre-commit configuration, and it is applied to the tooling rather than to the two packages the framework actually needs.

The nomad group installs a dependency from the main branch of a git URL

Optional functionality is grouped by name in the dependency groups table, with docs, s2s, semap, simbench, perception and nomad as the choices. The nomad group is the one to look at twice. Its first entry is `visualnav_transformer @ git+https://github.com/RobotecAI/visualnav-transformer-ros2.git@main`, which is not a released version but a git URL pointing at the main branch of the visualnav-transformer-ros2 repository. What resolves therefore depends on whatever that branch holds at the moment you install, and two machines resolving the same group on different days can end up with different navigation code, with no commit recorded anywhere in the file to fall back on. The second entry, `gdown>=5.2.0,<6.0.0`, is a downloader, which means this group also reaches the network at install time for content it fetches rather than code it installs. By contrast the simbench, perception and s2s groups name distributions from the same project, so their versions move with the project's own releases.

Six packages map to local paths, and four named packages have no mapping at all

Under tool.uv.sources, six packages are pointed at editable paths inside the tree: rai_core, rai_whoami, rai_s2s, rai_semap, rai_sim, rai_bench and rai_perception. One of them sits deeper than the rest, since rai_perception resolves to src/rai_extensions/rai_perception while the others resolve to a directory named after the package directly under src/. That single level of nesting is the only structural difference in the list. The gap between the two files is larger than the layout. The README's framework list names nine things: core, whoami, rai_asr, rai_tts, rai_sim, rai_bench, rai_perception, rai_nomad and an unchecked rai_finetune. Of those, rai_asr, rai_tts and rai_finetune appear nowhere in the dependency list, the source mappings or the groups, and rai_nomad has a group but no mapping of its own. Running the other way, rai_s2s and rai_semap are installed from local paths and have no line in the README's list.

Five manipulation demos differ only by suffix, with no statement of which is current

The examples directory holds one agriculture demo, one debugging assistant, one ROSbot XL demo, an embodiments folder, an agents folder and an s2s folder, and then five files for the same manipulation task: manipulation-demo.py, manipulation-demo-v1.py, manipulation-demo.launch.py, manipulation-demo-no-binary.launch.py and manipulation-demo-streamlit.py, alongside a shared manipulation_common.py. Their names imply four different delivery mechanisms for one scenario, a plain script, a versioned variant, a ROS 2 launch file, a launch file that does not need a compiled binary, and a Streamlit front end. Nothing in the file names says which one to start with, and nothing marks the others as deprecated. Two launch files and a Streamlit entry point in one examples folder is a reasonable way to serve several audiences, but a reader arriving at the repository has to infer the current path from the suffixes. The same ambiguity shows up in the simulation demo table, where the same scenario family appears against four different platforms.

Tests are classified as billable and deselected by marker

The pytest configuration defines markers, and the first one reads billable: marks test as billable, with the deselection hint written as -m "not billable". That single marker tells you the suite contains tests that cost something to run, such as compute or hardware time, and that the project expects a cheap subset to be selectable by name. The other marker definition in the visible block is cut off partway through its own description, so the full classification list is not readable from the file. Around the tests, the repository carries the matching automation: codecov.yml at the top level for coverage reporting, a pre-commit configuration, a .licenserc.json for license headers, a .coderabbit.yaml for automated review, and a .clang-format even though the framework itself is Python and the C++ formatting belongs to the ROS 2 packages underneath it. The runtime dependencies discussed earlier are what make that chain run.

Setup lives on a documentation site, and one component is still an open box

There is no install command in the README. The getting started section is a link to a setup page on the project's documentation site, and the developer section points at the same site for creating a configuration specific to one robot. The framework list is the only place the shape of the project is described inline, and it ends with the single unchecked item: rai_finetune, for finetuning language models on your own embodied data. Everything above that box is ticked, including rai_whoami, which extracts and synthesizes robot embodiment information from a structured directory of documentation, images and URDFs. So the announced surface is nine components, eight of them presented as available and one as future work. The simulation table alongside it points at four demos on four different platforms, an autonomous tractor in a virtual orchard, a Franka Panda arm working with Grounded SAM 2, a Husarion ROSbot XL, and an RB-KAIROS mobile manipulator running on board.

Editorial conclusion

Adopt it package by package rather than as one install, and read the uv source paths before you pin anything, because the root project is marked as not a package and one optional group installs a git dependency from a moving branch. Before trusting a version number, compare the tag you are installing against the metadata, since the two disagree here. Anyone who needs speech components should confirm the asr and tts packages exist for their distribution first, because the README names them and the packaging file does not.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. RobotecAI/rai on GitHub