build: add devconfig file

[opentechexpert]

No need to install package on local enviroment. Docker in docker to run BACKEND docker container. Ready to go for end user. Runs "make build" after container is create from the makefile in the root of the project. Ready to go development environment. This pull request adds a devconfig file to the repository. The devconfig file is used to configure the development container and includes settings for the container image, features, post-create commands.

[rbren]

How do you run this?

[opentechexpert]

How do you run this?

Have you had the chance to try it out?

[rbren]

I have not. Totally unfamiliar with devconfig--if this is legit useful for other devs I'm game to merge it, but if it's just something @opentechexpert would use, probably not worth maintaining.

I'll ask in slack if anyone is familiar

[thomas-gale]

Hey folks, I'm also a fan of devcontainers. I personally use them extensively in my day to day work (bringing sanity to my devops deployments of various languages stacks on my local dev machines and on remote machines (you can combine SSH remote connection and devcontainers!). For those unfamiliar, see this devcontainer overview!

I tested your devcontainer.json @opentechexpert, however, I get this error on make start-backend

make start-backend
Starting backend...
Traceback (most recent call last):
  File "/home/vscode/.local/share/virtualenvs/OpenDevin-AC_rBlDp/lib/python3.11/site-packages/torch/__init__.py", line 176, in _load_global_deps
    ctypes.CDLL(lib_path, mode=ctypes.RTLD_GLOBAL)
  File "/usr/local/lib/python3.11/ctypes/__init__.py", line 376, in __init__
    self._handle = _dlopen(self._name, mode)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^
OSError: libcudart.so.12: cannot open shared object file: No such file or directory
...

My system:

• Windows 11
• Nvidia RTX 3070
• Docker Desktop 4.28.0

I think, unfortunately, the torch package dependency is defaulting to using cuda within a Linux environment. I spent a little time chasing down the issues, here is my attempt at a working devcontainer.json

https://github.com/thomas-gale/OpenDevin/blob/tgale/devcontainer/.devcontainer/devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/debian
{
	"name": "Ubuntu 22.04 - CUDA 12.2 - cuDNN 8",
	"image": "nvidia/cuda:12.2.2-cudnn8-devel-ubuntu22.04",
	"runArgs": [
		"--gpus",
		"all"
	],
	"features": {
		"ghcr.io/devcontainers/features/python:1": {
			"installTools": true,
			"version": "3.11"
		},
		"ghcr.io/devcontainers/features/docker-in-docker:2": {
			"moby": true,
			"azureDnsAutoDetection": true,
			"installDockerBuildx": true,
			"installDockerComposeSwitch": true,
			"version": "latest",
			"dockerDashComposeVersion": "latest"
		},
		"ghcr.io/devcontainers/features/node:1": {
			"nodeGypDependencies": true,
			"version": "lts",
			"nvmVersion": "latest"
		}
	}
	// Features to add to the dev container. More info: https://containers.dev/features.
	// "features": {},
	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],
	// Configure tool-specific properties.
	// "customizations": {},
	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
	// "remoteUser": "root"
}

In terms of testing, I've run make start-backend and make start-frontend and successfully interacted with OpenDevin.

I have some concerns that docker-in-docker might be problematic when it comes to communicating with servers/apps which OpenDevin creates and runs. Forwarding ports from nested Dockers is likely tricky. Curious if we instead use docker-outside-of-docker possibly with network=host as an alternative for running OpenDevin's sandbox container. Also, we probably want to try lighter distro than Ubuntu if possible!

Anyway, I hope this is helpful to the discussion/PR.

[rbren]

Two votes for devcontainers is enough for me!

@opentechexpert if you're able to get it working for @thomas-gale we'll get this merged

[rbren]

Also--I'm leaning towards DOOD as well now.

[lowlyocean]

+1 for dev container. Any update here? Should reduce effort wasted trying to accommodate different developer environments.

Examples of environment-specific issues that (without a unified devcontainer) limit dev toolset selection (see https://github.com/OpenDevin/OpenDevin/discussions/820#discussioncomment-9029900):

• PNPM leverages symbolic links by default, which aren't well supported on WSL
• Until only recently, there was no workaround on certain host architectures for Poetry to download dependencies (because of issues building wheels for some package + arch combos, and no way to just tell Poetry to download a pre-built binary)

[rbren]

I'm going to close this one due to lack of activity, and a guess that it's outdated given how much work has happened in the last 2 weeks.

But I'd happily accept a new PR here!