[Bug]: Building runtime images fails with an opaque error when OpenHands is installed as a library

[neubig]

Is there an existing issue for the same bug?

• [X] I have checked the troubleshooting document at https://docs.all-hands.dev/modules/usage/troubleshooting
• [X] I have checked the existing issues.

Describe the bug

When OpenHands is installed as a library, this line in runtime_build.py will fail, because the pyproject.toml file of OpenHands is not installed in the Python libraries directory (and it shouldn't be): https://github.com/All-Hands-AI/OpenHands/blob/36d1745b5e7efd46865160f3e34e6242fc5b828d/openhands/runtime/utils/runtime_build.py#L41

The resulting error is this:

07:00:30 - openhands:INFO: runtime_build.py:41 - Using project root: /Users/gneubig/miniconda3/envs/github-resolver/lib/python3.11/site-packages
ERROR Source /Users/gneubig/miniconda3/envs/github-resolver/lib/python3.11/site-packages does not appear to be a Python project: no pyproject.toml or setup.py

In order to fix this, we probably should just prevent building runtimes when OpenHands is installed as a library, and make the error more comprehensible, suggesting that the specify a runtime like ghcr.io/all-hands-ai/runtime:{VERSION_NO}.

Or maybe we need some way to get the source distribution that corresponds to that version of OpenHands for use in that line above?

I'm not exactly sure the best method here so any feedback would be helpful (maybe cc @xingyaoww ?)

Current OpenHands version

main

Installation and Configuration

pip install openhands-ai

Model and Agent

No response

Operating System

No response

Reproduction Steps

No response

Logs, Errors, Screenshots, and Additional Context

No response

[xingyaoww]

Yeah i think we can include pyproject.toml and poetry.lock into the MANEFEST.in? If the library code's hash matches existing runtime, it will automatically download corresponding runtime image too.

I'm a bit concerned about removing this, because user might modify code from the installed pypi library and could experienced unexpected behavior (e.g., modified code is not compatible w/ existing images) if this code hash check is not inplace.

[neubig]

I think adding pyproject.toml and poetry.lock into the source distribution might cause problems because, they would be placed in the top directory of the virtual environment, and could potentially be overwritten by any other project that also chooses to do that.

Probably the best solution is to only allow use of existing runtime images when installed through pypi -- when people install as a library we also usually expect that they won't be directly modifying the source code.