Make `plugins` sandbox-agnostic

[Xingyao Wang]

What problem or use case are you trying to solve?

Right now, CodeActAgent relies on installing some pip packages on the fly (e.g., jupyter) when the sandbox is initialized to work properly. But potentially, it could cause issues with, e.g., containers without Python and containers with different Python versions. Especially considering #1387

Describe the UX of the solution you'd like

We should make all the plugins or anything opendevin util-related (e.g., agentskills library #1941) that runs inside the sandbox to be sandbox-agnostic.

Do you have thoughts on the technical implementation?

• We could potentially compile these python packages / dependencies into single binary that does not need installation and can be quite stable.
• @Shimada666 suggests that we can create a OpenDevin-specific Python interpreter (and environment) inside each sandbox - and this is the interpreter that ALL plugins and agentskills uses and should be transparent to the user. We can initially pre-build sandboxes for most programming languages. Later we can provide a streamlined script that would install these plugins and agentskills in an arbitrary given docker images (on the fly, or adds a docker layer).

Describe alternatives you've considered

Additional context

[Shimada666]

Compiling dependencies into binary files may not be Python's strong suit. A better approach is to use a specific Python environment.

In fact, in the real world, I have done many similar things before. In one instance, I had to deal with a complex environment with different versions of CentOS 6, CentOS 7, and other systems. The Python environments on the machines are also diverse and difficult to standardize, and some Python environments are even damaged. We needed to run Ansible using Python 3, so we directly installed Python 3 on a specific path on all hosts as the Python runtime for Ansible, solving the issue.

Returning to this issue, in the short term, I believe we can use the current sandbox as the base image and then build different versions of language images on top of it, such as Node 18 sandbox, Go 1.20 sandbox, etc., to address most users' needs.

If we need OpenDevin to run on different operating systems, even on older systems like CentOS 6, at a lower cost, we would need to isolate a separate set of runtimes specifically for OpenDevin. I'm not very familiar with Miniforge, but I've heard it might be a good choice. We could consider using Miniforge to build our OpenDevin runtime, install Python 3 in Miniforge, most C library dependencies, and all pip dependencies to address issues with low versions of dependency libraries (glibc, gcc, etc.) in older operating systems, thereby improving the portability of OpenDevin. Essentially, it's similar to what Docker does - isolating a separate runtime environment.

Miniforge also provides us with the possibility to freely combine language runtimes. We can easily use Miniforge to install different language runtimes simultaneously, such as installing Python 3.11 and Node.js 18 at the same time. If this approach works out, I think this could be an ideal choice. We will be able to freely specify any runtime we need in the sandbox.