[TomCC7]

Thanks for the awesome project! Here is a fully vibed but working solution that makes the project pip installable (related to #101 ). Can try and test directly:

uv pip install 'roboplan @ git+https://github.com/TomCC7/roboplan'

which will pull and build the python binding from source.

Hope this can be a good reference!

[sea-bass]

Thank you for sharing this! I will try find some time in the next few days to try this out.

BTW the ROS Rolling job is known to be failing because the official ROS Docker image hasn't cut over to Ubuntu 26.04 now.

[sea-bass]

So I just tried the pip install command locally on a fresh environment and got this. Any ideas?

$ pip install --break-system-packages 'roboplan @ git+https://github.com/TomCC7/roboplan'
Defaulting to user installation because normal site-packages is not writeable
WARNING: Skipping /usr/lib/python3/dist-packages/pytest_repeat.egg-info due to invalid metadata entry 'name'
WARNING: Skipping /usr/lib/python3/dist-packages/pytest_repeat.egg-info due to invalid metadata entry 'name'
Collecting roboplan@ git+https://github.com/TomCC7/roboplan
  Cloning https://github.com/TomCC7/roboplan to /tmp/pip-install-itp7gt2_/roboplan_decece5e15e44c989be32c9117eedf36
  Running command git clone --filter=blob:none --quiet https://github.com/TomCC7/roboplan /tmp/pip-install-itp7gt2_/roboplan_decece5e15e44c989be32c9117eedf36
  Resolved https://github.com/TomCC7/roboplan to commit 10e01c34fd3e187b285fa1a0d0699b0ee44dff80
  Running command git submodule update --init --recursive -q
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
  WARNING: Generating metadata for package roboplan produced metadata for project name roboplan-dimos. Fix your #egg=roboplan fragments.
Discarding git+https://github.com/TomCC7/roboplan: Requested roboplan-dimos from git+https://github.com/TomCC7/roboplan has inconsistent name: expected 'roboplan', but metadata has 'roboplan-dimos'
ERROR: Could not find a version that satisfies the requirement roboplan (unavailable) (from versions: none)
ERROR: No matching distribution found for roboplan (unavailable)

---

same with uv in a fresh env

(.test_venv) sebastian@rev07:~$ uv pip install 'roboplan @ git+https://github.com/TomCC7/roboplan'
Using Python 3.12.3 environment at: .test_venv
    Updated https://github.com/TomCC7/roboplan (10e01c34fd3e187b285fa1a0d0699b0ee44dff80)
  × Failed to download and build `roboplan @ git+https://github.com/TomCC7/roboplan`
  ╰─▶ Package metadata name `roboplan-dimos` does not match given name `roboplan`

[TomCC7]

Oops sorry I made a couple of changes after opening the PR so that I can publish to pypi with a different name. You can either try to install from a previous commit (05db7d4), or just remove the "roboplan" package name in the install command since the package name on my branch was renamed to roboplan-dimos.

[sea-bass]

oh wow, yes -- confirming that removing the roboplan @ worked and I could run a few examples. Very, very cool.

[sea-bass]

Review-wise, I think I'm a little terrified to put so many custom shell scripts and pyproject.toml files in the main repo.

What I'm thinking right now is: what if we make a separate repository in the open-planning organization that pulls in the code, adds the necessary patches/modifications, and has a CI job we can kick off to grab the latest roboplan version and publish it to PyPi?

It seems complicated, but it's one way we can explore not sticking a ton of files into here... thoughts?

[TomCC7]

Review-wise, I think I'm a little terrified to put so many custom shell scripts and pyproject.toml files in the main repo.

What I'm thinking right now is: what if we make a separate repository in the open-planning organization that pulls in the code, adds the necessary patches/modifications, and has a CI job we can kick off to grab the latest roboplan version and publish it to PyPi?

It seems complicated, but it's one way we can explore not sticking a ton of files into here... thoughts?

Hey tried to cleanup a bit so patches don't spam up original cmake files. I think it's better to just keep everything together to make release easier. With the current release ci file, new pypi packages will be built and published automatically whenever you create a new release on github. If you still prefer using a separate repo I'm also happy to help :)

[sea-bass]

It does make sense to keep it all together if possible! Will take another look when I can.

[TomCC7]

hi @sea-bass , addressed your concerns. also updated package names to target roboplan. here's the instruction on pypi.org registration:

1. Go to https://pypi.org/manage/account/publishing/
2. add a new pending publisher.
   Use these values for upstream:
   PyPI project name: roboplan
   Owner: open-planning
   Repository name: roboplan
   Workflow name: release.yml
   Environment name: pypi

after this and the branch is merged. whenever you create a new release on github the release flow will run and publish automatically.

[scastro-nasa]

Thanks, you're right that this is trending in a good direction where we can have the packaging in here. I left some small comments throughout, but have 3 major ones to look at:

1. We don't use vX.Y.Z tagging, it's just X.Y.Z, so these rules will have to change.
2. Should we be continuously testing that the PyPi packaging doesn't get broken? I think it will be very easy to break with changes. I'm thinking maybe the packaging CI job runs with every PR, but then it doesn't publish to testpypi or pypi; it just stops at running the tests.
3. Are some of these variables like BUILD_STANDALONE_PYTHON_BINDINGS and BUILD_CMEEL ever turned off in these scripts? If not, can we just remove them?

[sea-bass]

ugh I accidentally used my work account. sorry

[sea-bass]

it might be the case that macOS x86 doesn't really have any github active runners. Probably pretty OK to remove that since all modern macs use M series chips (which are ARM)

[sea-bass]

@TomCC7 I just went through the local testing and made a few changes, and this seems good to go. Local build and test worked, and I added a few more README instructions to get an example running.

Also added a PyPi trusted publisher re: your instructions, so that should be set once we queue up a 0.5.0 release. Though I may tag a dummy version for now just to test it.

Finally, THANK YOU for doing this very unglamorous task. This is great. I'd be happy to hear how you guys are using this library for dimensionalOS some time.

[TomCC7]

Glad to help! We've done some benchmarking and get a very positive result on roboplan. Can share more thoughts once we use roboplan extensively for a while!

[sea-bass]

ok I got an example version of RoboPlan on here: https://pypi.org/project/roboplan/

I installed it and had to clear 2 issues.

First, I had issues with my host's tinyxml2 version when importing pinocchio:

Python 3.12.3 (main, Mar 23 2026, 19:04:32) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pinocchio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/sebastian/.local/lib/python3.12/site-packages/cmeel.prefix/lib/python3.12/site-packages/pinocchio/__init__.py", line 19, in <module>
    from .pinocchio_pywrap_default import *
ImportError: libtinyxml2.so.11: cannot open shared object file: No such file or directory

I was able to resolve this by creating a symlink:

sudo ln -s /usr/lib/x86_64-linux-gnu/libtinyxml2.so.10 /usr/lib/x86_64-linux-gnu/libtinyxml2.so.11

Secondly, I got errors again importing Pinocchio due to my having NumPy 2.5.0 installed. But when I downgraded to NumPy 1.2.6, I was able to run an example!

EDIT: If I install it in a clean uv venv it all works perfectly out of the box... so yeah, will be recommending that to people :)