* [eval] increase timeout for swebench eval init/complete
* allow CmdRunAction to optionally block when .timeout is setted
* fix unit test for serialization
* fix unit tests for security analyzer
* fix integration tests
* add more timeout
* only check P2P when instances are non-empty;
convert P2P and F2P columns to string instead of list
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* [eval] increase timeout for swebench eval init/complete
* allow CmdRunAction to optionally block when .timeout is setted
* fix unit test for serialization
* fix unit tests for security analyzer
* fix integration tests
* add more timeout
* Fail the Runtime tests check if the previous jobs were cancelled or failed
* Check only for failures
* Add test exit
* Test cancel
* fix conditions
* fix condition again
* Try another way
* Now test success
* move filematching logic into server
* wait until ready before returning
* show loading message instead of empty
* logspam
* delint
* fix type
* add a few more default ignores
* Reduce runtime tests duration by running them across CPUs
* fix hardcoded image name
* test two cpus
* Test folder change
* Up the CPU to 4 again to test
* Change to 3 CPUs
* Down to 2
* Add param to remove all openhands containers
* Add comment
* Add reruns just in case
* Fix ordering of if
* Add Handling of Cache Prompt When Formatting Messages
* Fix Value for Cache Control
* Fix Value for Cache Control
* Update openhands/core/message.py
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* Fix lint error
* Serialize Messages if Propt Caching Is Enabled
* Remove formatting message change
---------
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
Co-authored-by: tobitege <10787084+tobitege@users.noreply.github.com>
* dummy test change
* regen yml: 1st install python 3.11, then poetry
* fix caching for poetry; old entry for python was rather useless
* fix steps order (cache before poetry)
* add poetry caching to ghcr_runtime; fix fork conditions
* ghcr_runtime: more caching actions; condition fixes
* fix interim action error (order of steps)
* cache@v4 instead of v3
* fixed interim typo for 2 fork conditions
* runtime/test_env_vars: compacted multiple tests into one to reduce time
* ugh if fork condition changes again
* (feat) making prompt caching optional instead of enabled default
At present, only the Claude models support prompt caching as a experimental feature, therefore, this feature should be implemented as an optional setting rather than being enabled by default.
Signed-off-by: Yi Lin <teroincn@gmail.com>
* handle the conflict
* fix unittest mock return value
* fix lint error in whitespace
---------
Signed-off-by: Yi Lin <teroincn@gmail.com>
* Update docs on LLM providers for consistency
* Update headless command
* minor tweaks based on feedback
---------
Co-authored-by: Robert Brennan <contact@rbren.io>
Co-authored-by: Robert Brennan <accounts@rbren.io>
* feat: add SWE-bench fullset support
* fix instance image list
* update eval script and documentation
* increase timeout for remote runtime
* add push script
* handle the case when ret push is an generator
* update pbar
* set SWE-Bench default to run SWE-Bench lite
* add script to cleanup remote runtime
* fix the cases when tag is too long
* update README
* update readme for cleanup
* rename od to oh
* Update evaluation/swe_bench/README.md
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Update evaluation/swe_bench/README.md
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Update evaluation/swe_bench/scripts/cleanup_remote_runtime.sh
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Update evaluation/swe_bench/scripts/cleanup_remote_runtime.sh
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Update evaluation/swe_bench/scripts/cleanup_remote_runtime.sh
Co-authored-by: Graham Neubig <neubig@gmail.com>
* gets API key and Runtime from env var
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* update badges
* fix badges
* better badges
* move credits
* more badge work
* add gh logo
* update some copy
* update logo
* fix height
* update text
* emdash
* remove cruft
* move title
* update links
* add hr
* white logo
* move some stuff to getting-started
* revert logo
* more copy changes
* minor tweaks
* fix sidebar
* explicit sidebar
* words
* fix tag
* fix how-to
* more docs work
* update styles
* fix up custom sandbox docs
* change eval title
* fix up getting-started
* fix getting started
* update to 0.9.2
* update screenshot
* add company link
* fix dark mode
* minor fixes
* update image
* update headless and cli docs
* update readme
* fix links
* revert package
* rename links
* fix links
* fix link
* chagne to claude
* Add documentation for CLI mode
Fixes#3703
Add documentation for CLI mode in OpenHands.
* **New Documentation**: Add `docs/modules/usage/how-to/cli-mode.md` to document CLI mode.
- Include instructions on starting an interactive OpenHands session via the command line.
- Explain the difference between CLI mode and headless mode.
- Provide examples of CLI commands and expected outputs.
* **Update Existing Documentation**: Modify `docs/modules/usage/how-to/headless-mode.md`.
- Clarify the difference between headless mode and CLI mode.
- Add a reference to the new CLI mode documentation.
* Update cli-mode.md
* Update headless-mode.md
---------
Co-authored-by: Robert Brennan <accounts@rbren.io>
Co-authored-by: tofarr <tofarr@gmail.com>
* update badges
* fix badges
* better badges
* move credits
* more badge work
* add gh logo
* update some copy
* update logo
* fix height
* update text
* emdash
* remove cruft
* move title
* update links
* add hr
* white logo
* move some stuff to getting-started
* revert logo
* more copy changes
* minor tweaks
* words
* fix getting started
* update to 0.9.2
* update screenshot
* minor fixes
* CodeActAgent: fix message prep if prompt caching is not supported
* fix python version in regen tests workflow
* fix in conftest "mock_completion" method
* add disable_vision to LLMConfig; revert change in message parsing in llm.py
* format messages in several files for completion
* refactored message(s) formatting (llm.py); added vision_is_active()
* fix a unit test
* regenerate: added LOG_TO_FILE and FORCE_REGENERATE env flags
* try to fix path to logs folder in workflow
* llm: prevent index error
* try FORCE_USE_LLM in regenerate
* tweaks everywhere...
* fix 2 random unit test errors :(
* added FORCE_REGENERATE_TESTS=true to regenerate CLI
* fix test_lint_file_fail_typescript again
* double-quotes for env vars in workflow; llm logger set to debug
* fix typo in regenerate
* regenerate iterations now 20; applied iteration counter fix by Li
* regenerate: pass FORCE_REGENERATE flag into env
* fixes for int tests. several mock files updated.
* browsing_agent: fix response_parser.py adding ) to empty response
* test_browse_internet: fix skipif and revert obsolete mock files
* regenerate: fi bracketing for http server start/kill conditions
* disable test_browse_internet for CodeAct*Agents; mock files updated after merge
* missed to include more mock files earlier
* reverts after review feedback from Li
* forgot one
* browsing agent test, partial fixes and updated mock files
* test_browse_internet works in my WSL now!
* adapt unit test test_prompt_caching.py
* add DEBUG to regenerate workflow command
* convert regenerate workflow params to inputs
* more integration test mock files updated
* more files
* test_prompt_caching: restored test_prompt_caching_headers purpose
* file_ops: fix potential exception, like "cross device copy"; fixed mock files accordingly
* reverts/changes wrt feedback from xingyao
* updated docs and config template
* code cleanup wrt review feedback
* Catch exception and return finish action with an exception message in case of exception in llm completion
* Remove exception logs
* Raise llm response error for any exception in llm completion
* Raise LLMResponseError from async completion and async streaming completion as well
* feat: add SWE-bench fullset support
* fix instance image list
* update eval script and documentation
* increase timeout for remote runtime
* add push script
* handle the case when ret push is an generator
* update pbar
* set SWE-Bench default to run SWE-Bench lite
* feat: add SWE-bench fullset support
* fix instance image list
* update eval script and documentation
* add push script
* handle the case when ret push is an generator
* update pbar
Fix a potential issue that might lead to file corruption when edit linting is enabled
#3124 introduces a feature for editing: running linter twice before and after the change and only extract new errors introduced by the agent. This has some potential issues and I am working on #3649 to address them, but I feel like I am not gonna finish it in the next few days, and that PR has become harder and harder to review, thus this PR, which only focuses on a small improvement.
So what's the issue? When we run linters on the original file before our edits, we need to copy the original file and use a temporary file to lint, because linting may have side-effect (e.g. modifying the file in-place). I used the word "may" because:
Flake8 has no side-effect, so not a problem as of now.
We don't enforce this or document this "no side-effect" as a requirement for linter implementation, so side-effect is allowed.
Regardless, the "after-edit-linting" uses the same approach: backup the file before linting to avoid data corruption. We should keep our "before-edit-linting" consistent.
Why no new unittest that reproduces the issue? Well, as I have mentioned earlier, flake8 has no side-effect, so technically it's not a bug but a flaw. Therefore, there's no way to write a test that reproduces the issue.
* improve file editing prompts and unit test
converted most raise calls to a _output_error call in file_ops.py
* tweaks in test_agent_skill.py wrt to SEP separator
* tweaked the separator
* remove server runtime remnants and TEST_RUNTIME references
* restore use of TEST_RUNTIME args and variables
* fix integration tests
* added hint to properly escape docstrings
* revert latest prompt change
---------
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
* change runtime to be synchronous
* fix test runtime with the new interface
* fix arg
* fix eval
* fix missing config attribute
* fix plugins
* fix on_event by revert it back to async
* update upload_file endpoint
* fix argument to upload file
* remove unncessary async for eval;
fix evaluation run in parallel
* use asyncio to run controller for eval
* revert file upload
* truncate eval test result output
* feat: refactor building logic into runtime builder
* return image name
* fix testcases
* use runtime builder for eventstream runtime
* have runtime builder return str
* add api_key to sandbox config
* draft remote runtime
* remove extra if clause
* initialize runtime based on box class
* add build logic
* use base64 for file upload
* get runtime image prefix from API
* replace ___ with _s_ to make it a valid image name
* use /build to start build and /build_status to check the build progress
* update logging
* fix exit code
* always use port
* add remote runtime
* rename runtime
* fix tests import
* make dir first if work_dir does not exists;
* update debug print to remote runtime
* fix exit close_sync
* update logging
* add retry for stop
* use all box class for test keep prompt
* fix test browsing
* add retry stop
* merge init commands to save startup time
* fix await
* remove sandbox url
* support execute through specific runtime url
* fix file ops
* simplify close
* factor out runtime retry code
* fix exception handling
* fix content type error (e.g., bad gateway when runtime is not ready)
* add retry for wait until alive;
add retry for check image exists
* Revert "add retry for wait until alive;"
This reverts commit dd013cd268.
* retry when wait until alive
* clean up msg
* directly save sdist to temp dir for _put_source_code_to_dir
* support running testcases in parallel
* tweak logging;
try to close session
* try to close session even on exception
* update poetry lock
* support remote to run integration tests
* add warning for workspace base on remote runtime
* set default runtime api
* remove server runtime
* update poetry lock
* support running swe-bench (n=1) eval on remoteruntime
* add a timeout of 30 min
* add todo for docker namespace
* update poetry loc
* linter and test_aider_linter extensions for eslint
* linter tweaks
* try enabling verbose output in linter test
* one more option for linter test
* try conftest.py for tests/unit folder
* enable verbose mode in workflow; remove conftest.py again
* debug print statements of linter results
* skip some tests if eslint is not installed at all
* more tweaks
* final test skip setups
* code quality revisions
* fix test again
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* aider-bench: add visualization to summarize script and readme
* added example cost and actions histogram images for readme
* moved dependencies to evaluation section
* added optional START_ID env flag to resume from that instance id
* prepare_dataset: fix comparisons by using instance id's as int
* aider bench complete_runtime: close runtime to close container
* added matrix display of instance id for logging
* fix typo in summarize_results.py saying summarise_results
* changed start_id to skip_num to skip rows from dataset (start_id wasn't supportable)
* doc changes about huggingface spaces to temporarily point back to OD
* Add prompt caching
* remove anthropic-version from extra_headers
* change supports_prompt_caching method to attribute
* change caching strat and log cache statistics
* add reminder as a new message to fix caching
* fix unit test
* append reminder to the end of the last message content
* move token logs to post completion function
* fix unit test failure
* fix reminder and prompt caching
* unit tests for prompt caching
* add test
* clean up tests
* separate reminder, use latest two messages
* fix tests
---------
Co-authored-by: tobitege <10787084+tobitege@users.noreply.github.com>
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* add eval_ids arg to run specific instance id's; fix/extend README
* fix description in parser for --eval-ids
* fix test_arg_parser.py to account for added arg
* fix typo in README to say "summarize" instead of "summarise" for script
* fix conftest.py option (#3573)
* try to fix fixture base_container_image in runtime conftest
* fix integration test mock files due to #3548
* fix test_ipython.py integration test
* Fix pypi build
The package on pypi only included opendevin/* (the poetry default). It also needs to include agenthub/*
* Bumped version so people will actually get it!
* Fix package definition
* Updated poetry lock file
* Update package name to openhands-ai
* Add py.typed to indicate that OpenHands has type annotations
* Replace package name with openhands_ai
* Fix tests to reflect new name
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Create helper functions
* Add map according to litellm docs
* Create ModelSelector
* Extend model selector
* use autocomplete from nextui
* Improve keys without providers
* Handle models without a provider
* Add verified section and some empty handling
* Add support for default or previously set models
* Update tests
* Lint
* Remove modifier
* Fix typescript error
* Functionality for switching to custom model
* Add verified models
* Respond to resetting to default
* Comment
* try to fix pip unavailable
* update test case for pip
* force rebuild in CI
* remove extra symlink
* fix newline
* added semi-colon to line 31
* Dockerfile.j2: activate env at the end
* Revert "Dockerfile.j2: activate env at the end"
This reverts commit cf2f565102.
* cleanup Dockerfile
* switch default python image
* remove image agnostic (no longer used)
* fix tests
* simplify integration tests default image
* add nodejs specific runtime tests
* update tests and workflows
* switch to nikolaik/python-nodejs:python3.11-nodejs22
* update build sh to output image name correctly
* increase custom images to test
* fix test
* fix test
* fix double quote
* try fixing ci
* update ghcr workflow
* fix artifact name
* try to fix ghcr again
* fix workflow
* save built image to correct dir
* remove extra -docker-image
* make last tag to be human readable image tag
* fix hyphen to underscore
* run test runtime on all tags
* revert app build
* separate ghcr workflow
* update dockerfile for eval
* fix tag for test run
* try fix tag
* try fix tag via matrix output
* try workflow again
* update comments
* try fixing test matrix
* fix artifact name
* try fix tag again
* Revert "try fix tag again"
This reverts commit b369badd8c.
* tweak filename
* try different path
* fix filepath
* try fix tag artifact path again
* save json instead of line
* update matrix
* print all tags in workflow
* support only streaming diff logs from the runtime client
* remove strip from log line to fix indentation
* get py interpreter for jupyter
* rstrip to remove newline on the rightside for logging
* fix blocking issue for stream logs
* set python interpreter path in bash ps1
* update testcase for jupyter py interpreter path
* remove accidentally added changes
* remove accidentally added changes
* only print dockerfile when debug
* add docs
* remove extra tests that weren't supposed to be in this pr
* add back missing test
* revert
* make LogBuffer synchronous to fix hang in integration tests
* fix integration tests
* Update opendevin/runtime/client/client.py
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* fix test case
* fix integration tests
* change deque to list
* update integration tests
* rename test runtime
* fix docs
* rename opendevin to openhands in tests
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: tobitege <10787084+tobitege@users.noreply.github.com>
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* tweaks to linter.py to prep for typescript linting (not implemented yet)
* fix 2 linter unit tests
* simpler basic_lint output; updated unit test
* fix default gpt-4o model name in aider default config
* linter.py: use tsc (typescript compiler) for linting; added more tests
* make typescript linting be more forgiving
* use npx instead of npm to install typescript in Dockerfile.j2
* Fix merge mistake
* removed npx call from Dockerfile.j2
* fix run_cmd to use code parameter; replace regex in test
* fix test_lint_file_fail_typescript to ignore leading path characters
* added TODO comment to extract_error_line_from
* fixed bug in ts_lint with wrong line number parsing
* move test_runtime to ghcr_test_runtime; adapt workflows; fix runtime AttributeError
* split test_runtime.py into multiple tests in new tests/runtime folder
* moved common fixtures to tests/runtime/conftest.py
* add anthropic dependency for Vertex to Dockerfile.j2 template
* add anthropic also to pyproject
* revert Dockerfile.j2 change
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
---------
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
* renaming more opendevin occurences
* remove DOCKER_IMAGE variable from Makefile
* Revert rename in evaluation/swe_bench/run_infer.py
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
---------
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
* Fix: Reset iteration count when resuming due to throttling
* Fix inadvertent additions
* WIP
* Changing max_iterations instead of iteration count
* Now adjusting max_iterations or max_budget_per_task as appropriate
* Fix check on iterations
* Fix linter issues
* AgentController: remember initial max_iterations and use it to extend state's iterations
* increase task budget by initial value (not doubling it)
---------
Co-authored-by: Tim O'Farrell <tofarr@gmai.com>
Co-authored-by: tobitege <10787084+tobitege@users.noreply.github.com>
Co-authored-by: mamoodi <mamoodiha@gmail.com>
* try to fix pip unavailable
* update test case for pip
* force rebuild in CI
* remove extra symlink
* fix newline
* added semi-colon to line 31
* Dockerfile.j2: activate env at the end
* Revert "Dockerfile.j2: activate env at the end"
This reverts commit cf2f565102.
* cleanup Dockerfile
* switch default python image
* remove image agnostic (no longer used)
* fix tests
* simplify integration tests default image
* add nodejs specific runtime tests
* update tests and workflows
* switch to nikolaik/python-nodejs:python3.11-nodejs22
* update build sh to output image name correctly
* increase custom images to test
* fix test
* fix test
* fix double quote
* try fixing ci
* update ghcr workflow
* fix artifact name
* try to fix ghcr again
* fix workflow
* save built image to correct dir
* remove extra -docker-image
* make last tag to be human readable image tag
* fix hyphen to underscore
* run test runtime on all tags
* revert app build
* separate ghcr workflow
* update dockerfile for eval
* fix tag for test run
* try fix tag
* try fix tag via matrix output
* try workflow again
* update comments
* try fixing test matrix
* fix artifact name
* try fix tag again
* Revert "try fix tag again"
This reverts commit b369badd8c.
* tweak filename
* try different path
* fix filepath
* try fix tag artifact path again
* save json instead of line
* update matrix
* print all tags in workflow
* fix DOCKER_IMAGE to avoid ghcr.io/opendevin/ghcr.io/opendevin/od_runtime
* fix test matrix to only load unique test image tags
* try fix matrix again!!!!!
* add all runtime tests passed
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: tobitege <10787084+tobitege@users.noreply.github.com>
* refactor agentskills to prepare for agentless
* fix import
* fix typo
* fix imports
* fix globals
* fix import
* fix import
* disable log to file to avoid auto-created log file w/ permission issue when import od in runtime
* import agentskills from OD instead from itself directly
* add back pythonpath
* remove chown since there's no log/folder
* add projects with licenses list
* fix projects
* fix projects
* fix projects
* fix licenses, include full Apache
* move AL 2.0 text to Credits
* Update README.md
Co-authored-by: Graham Neubig <neubig@gmail.com>
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Split Frontend and Python Unit tests
* Extra comment for deploy docs workflow
* Simpler comment
* Add paths and paths-ignore to unit tests
* More specific comment for py unit tests
* Remove paths-ignore because jobs are required
---------
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* fix potential flake8 miss checking
* Add unit test for edit_file_by_replace function with problematic file
* Add unit test for edit_file_by_replace function with problematic file
* Add unit test for edit_file_by_replace function with problematic file
* Add unit test for edit_file_by_replace function with problematic file
* Add unit test for edit_file function with problematic file
* Add unit test for edit_file function with problematic file
* Add unit test for edit_file function with problematic file
* Add unit test for edit_file function with problematic file
* Add unit test for edit_file function with problematic file
* Update opendevin/runtime/plugins/agent_skills/agentskills.py
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
* add test intention description
* fix potential flake8 miss checking
* fix potential flake8 miss checking
* fix potential flake8 miss checking
* fix potential flake8 miss checking
* fix potential flake8 miss checking
---------
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: tobitege <tobitege@gmx.de>
* feat: Initial work on security analyzer
* feat: Add remote invariant client
* chore: improve fault tolerance of client
* feat: Add button to enable Invariant Security Analyzer
* [feat] confirmation mode for bash actions
* feat: Add Invariant Tab with security risk outputs
* feat: Add modal setting for Confirmation Mode
* fix: frontend tests for confirmation mode switch
* fix: add missing CONFIRMATION_MODE value in SettingsModal.test.tsx
* fix: update test to integrate new setting
* feat: Initial work on security analyzer
* feat: Add remote invariant client
* chore: improve fault tolerance of client
* feat: Add button to enable Invariant Security Analyzer
* feat: Add Invariant Tab with security risk outputs
* feat: integrate security analyzer with confirmation mode
* feat: improve invariant analyzer tab
* feat: Implement user confirmation for running bash/python code
* fix: don't display rejected actions
* fix: make confirmation show only on assistant messages
* feat: download traces, update policy, implement settings, auto-approve based on defined risk
* Fix: low risk not being shown because it's 0
* fix: duplicate logs in tab
* fix: log duplication
* chore: prepare for merge, remove logging
* Merge confirmation_mode from OpenDevin main
* test: update tests to pass
* chore: finish merging changes, security analyzer now operational again
* feat: document Security Analyzers
* refactor: api, monitor
* chore: lint, fix risk None, revert policy
* fix: check security_risk for None
* refactor: rename instances of invariant to security analyzer
* feat: add /api/options/security-analyzers endpoint
* Move security analyzer from tab to modal
* Temporary fix lock when security analyzer is not chosen
* feat: don't show lock at all when security analyzer is not enabled
* refactor:
- Frontend:
* change type of SECURITY_ANALYZER from bool to string
* add combobox to select SECURITY_ANALYZER, current options are "invariant and "" (no security analyzer)
* Security is now a modal, lock in bottom right is visible only if there's a security analyzer selected
- Backend:
* add close to SecurityAnalyzer
* instantiate SecurityAnalyzer based on provided string from frontend
* fix: update close to be async, to be consistent with other close on resources
* fix: max height of modal (prevent overflow)
* feat: add logo
* small fixes
* update docs for creating a security analyzer module
* fix linting
* update timeout for http client
* fix: move security_analyzer config from agent to session
* feat: add security_risk to browser actions
* add optional remark on combobox
* fix: asdict not called on dataclass, remove invariant dependency
* fix: exclude None values when serializing
* feat: take default policy from invariant-server instead of being hardcoded
* fix: check if policy is None
* update image name
* test: fix some failing runs
* fix: security analyzer tests
* refactor: merge confirmation_mode and security_analyzer into SecurityConfig. Change invariant error message for docker
* test: add tests for invariant parsing actions / observations
* fix: python linting for test_security.py
* Apply suggestions from code review
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* use ActionSecurityRisk | None intead of Optional
* refactor action parsing
* add extra check
* lint parser.py
* test: add field keep_prompt to test_security
* docs: add information about how to enable the analyzer
* test: Remove trailing whitespace in README.md text
---------
Co-authored-by: Mislav Balunovic <mislav.balunovic@gmail.com>
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
* remove unused plugin mixin
* change the entire jupyter PWD with bash;
print jupyter pwd in obs as well;
* remove unused field
* remove unused comments
* change the entire jupyter PWD with bash;
print jupyter pwd in obs as well;
* fix runtime tests for jupyter
* update intgeration tests
* fix test again
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* try to fix pip unavailable
* update test case for pip
* force rebuild in CI
* remove extra symlink
* fix newline
* added semi-colon to line 31
* Dockerfile.j2: activate env at the end
* Revert "Dockerfile.j2: activate env at the end"
This reverts commit cf2f565102.
* cleanup Dockerfile
* switch default python image
* remove image agnostic (no longer used)
* fix tests
* switch to nikolaik/python-nodejs:python3.11-nodejs22
* fix test
* fix test
* revert docker
* update template
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Fix issue where mouse drag fails on first attempt
* Detach event correctly
* Use old variable names
---------
Co-authored-by: Tim O'Farrell <tofarr@Tims-MacBook-Pro-2.local>
Co-authored-by: tobitege <tobitege@gmx.de>
* also copy over pyproject and poetry lock
* add missing readme
* remove extra git config init since it is already done in client.py
* only chown if the /workspace dir does not exists
* Revert "remove extra git config init since it is already done in client.py"
This reverts commit e8556cd76d.
* remove extra git config init since it is already done in client.py
* fix test runtime
* print container log while reconnecting
* print log in more readable format
* print log in more readable format
* increase lines
* clean up sandbox and ssh related stuff
* remove ssh hostname
* remove ssh hostname
* fix docker app cannot access runtime API issue
* remove ssh password
* API HOSTNAME should be pre-fixed with SANDBOX
* update config
* fix typo that breaks the test
* clean up sandbox and ssh related stuff
* remove ssh hostname
* remove ssh hostname
* remove ssh password
* update config
* fix typo that breaks the test
* Add unit tests for listen.py
* Added new tests
* Improve test coverage for listen.py
* Update tests
---------
Co-authored-by: opendevin <opendevin@all-hands.dev>
* switch default to eventstream runtime
* remove pull docker from makefile
* fix unittest
* fix file store path
* try deprecate server runtime
* remove persist sandbox
* move file utils
* remove server runtime related workflow
* remove unused method
* attempt to remove the reliance on filestore for BE
* fix async for list file
* fix list_files to post
* fix list files
* add suffix to directory
* make sure list file returns abs path;
make sure other backend endpoints accpets abs path
* remove server runtime test workflow
* set git config in runtime
* chown for workspace in client;
use INIT_COMMANDS to maintain all commands that need to be run before bash start;
* fix client issue;
add test case for git;
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* switch default to eventstream runtime
* remove pull docker from makefile
* fix unittest
* fix file store path
* try deprecate server runtime
* remove persist sandbox
* move file utils
* remove server runtime related workflow
* remove unused method
* attempt to remove the reliance on filestore for BE
* fix async for list file
* fix list_files to post
* fix list files
* add suffix to directory
* make sure list file returns abs path;
make sure other backend endpoints accpets abs path
* remove server runtime test workflow
* set git config in runtime
* move multi-line bash tests to test_runtime;
support multi-line bash for esruntime;
* add testcase to handle PS2 prompt
* use bashlex for bash parsing to handle multi-line commands;
add testcases for multi-line commands
* revert ghcr runtime change
* Apply stash
* fix run as other user;
make test async;
* fix test runtime for run as od
* add run-as-devin to all the runtime tests
* handle the case when username is root
* move all run-as-devin tests from sandbox;
only tests a few cases on different user to save time;
* move over multi-line echo related tests to test_runtime
* fix user-specific jupyter by fixing the pypoetry virtualenv folder
* make plugin's init async;
chdir at initialization of jupyter plugin;
move ipy simple testcase to test runtime;
* support agentskills import in
move tests for jupyter pwd tests;
overload `add_env_vars` for EventStreamRuntime to update env var also in Jupyter;
make agentskills read env var lazily, in case env var is updated;
* fix ServerRuntime agentskills issue
* move agnostic image test to test_runtime
* merge runtime tests in CI
* fix enable auto lint as env var
* update warning message
* update warning message
* test for different container images
* change parsing output as debug
* add exception handling for update_pwd_decorator
* fix unit test indentation
* add plugins as default input to Runtime class;
remove init_sandbox_plugins;
implement add_env_var (include jupyter) in the base class;
* fix server runtime auto lint
* Revert "add exception handling for update_pwd_decorator"
This reverts commit 2b668b1506.
* tries to print debugging info for agentskills
* explictly setting uid (try fix permission issue)
* Revert "tries to print debugging info for agentskills"
This reverts commit 8be4c86756.
* set sandbox user id during testing to hopefully fix the permission issue
* add browser tools for server runtime
* try to debug for old pwd
* update debug cmd
* only test agnostic runtime when TEST_RUNTIME is Server
* fix temp dir mkdir
* load TEST_RUNTIME at the beginning
* remove ipython tests
* only log to file when DEBUG
* default logging to project root
* temporarily remove log to file
* fix LLM logger dir
* fix logger
* make set pwd an optional aux action
* fix prev pwd
* fix infinity recursion
* simplify
* do not import the whole od library to avoid logger folder by jupyter
* fix browsing
* increase timeout
* attempt to fix agentskills yet again
* clean up in testcases, since CI maybe run as non-root
* add _cause attribute for event.id
* remove parent
* add a bunch of debugging statement again for CI :(
* fix temp_dir fixture
* change all temp dir to follow pytest's tmp_path_factory
* remove extra bracket
* clean up error printing a bit
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* add typing for tmp dir fixture
* clear the directory before running the test to avoid weird CI temp dir
* remove agnostic test case for server runtime
* Revert "remove agnostic test case for server runtime"
This reverts commit 30e2181c3f.
* disable agnostic tests in CI
* fix test
* make sure plugin arg is not passed when no plugin is specified;
remove redundant on_event function;
* move mock prompt
* rename runtime
* remove extra logging
* refactor run_controller's interface;
support multiple runtime for integration test;
filter out hostname for prompt
* uncomment other tests
* pass the right runtime to controller
* log runtime when start
* uncomment tests
* improve symbol filters
* add intergration test prompts that seemd ok
* add integration test workflow
* add python3 to default ubuntu image
* symlink python and fix permission to jupyter pip
* add retry for jupyter execute server
* fix jupyter pip install;
add post-process for jupyter pip install;
simplify init by add agent_skills path to PYTHONPATH;
add testcase to tests jupyter pip install;
* fix bug
* use ubuntu:22.04 for eventstream integration tests
* add todo
* update testcase
* remove redundant code
* fix unit test
* reduce dependency for runtime
* try making llama-index an optional dependency that's not installed by default
* remove pip install since it seemd not needed
* log ipython execution;
await write message since it returns a future
* update ipy testcase
* do not install llama-index in CI
* do not install llama-index in the app docker as well
* set sandbox container image in the integration test script
* log plugins & env var for runtime
* update conftest for sha256
* add git
* remove all non-alphanumeric chalracters
* add working ipy module tests!
* default to use host network
* remove is_async from browser to make thing a little more reliable;
retry loading browser when error;
* add sleep to wait a bit for http server
* kill http server before regenerate browsing tests
* fix browsing
* only set sandbox container image if undefined
* skip empty config value
* update evaluation to use the latest run_controller
* revert logger in execute_server to be compatible with server runtime
* revert logging level to fix jupyter
* set logger level
* revert the logging
* chmod for workspace to fix permission
* support getting timeout from action
* update test for server runtime
* try to fix file permission
* fix test_cmd_run_action_serialization_deserialization test (added timeout)
* poetry: pip 24.2, torch 2.2.2
* revert adding pip to pyproject.toml
* add build to dependencies in pyproject.toml
* forgot poetry lock --no-update
* fix a DelegatorAgent prompt_002.log (timeout)
* fix a DelegatorAgent prompt_003.log (timeout)
* couple more timeout attribs in prompt files
* some more prompt files
* prompts galore
* add clarification comment for timeout
* default timeout to config
* add assert
* update integraton tests for eventstream
* update integration tests
* fix timeout for action<->dict
* remove redundant on_event
* default to use instance image
* update run_controller interface
* add logging for copy
* refactor swe_bench for the new design
* fix action execution timeout
* updatelock
* remove build sandbox locally
* fix runtime
* use plain for-loop for single process
* remove extra print
* get swebench inference working
* print whole `test_result` dict
* got swebench patch post-process working
* update swe-bench evaluation readme
* refactor using shared reset_logger function
* move messy swebench prompt to a different file
* support the ability to specify whether to keep prompt
* support the ability to specify whether to keep prompt
* fix dockerfile
* fix import and remove unnecessary strip logic
* fix action serialization
* get agentbench running
* remove extra ls for agent bench
* fix agentbench metric
* factor out common documentation for eval
* update biocoder doc
* remove swe_env_box since it is no longer needed
* get biocoder working
* add func timeout for bird
* fix jupyter pwd with ~ as user name
* fix jupyter pwd with ~ as user name
* get bird working
* get browsing evaluation working
* make eda runnable
* fix id column
* fix eda run_infer
* unify eval output using a structured format;
make swebench coompatible with that format;
update client source code for every swebench run;
do not inject testcmd for swebench
* standardize existing benchs for the new eval output
* set update source code = true
* get gaia standardized
* fix gaia
* gorilla refactored but stuck at language.so to test
* refactor and make gpqa work
* refactor humanevalfix and get it working
* refactor logic reasoning and get it working
* refactor browser env so it works with eventstream runtime for eval
* add initial version of miniwob refactor
* fix browsergym environment
* get miniwob working!!
* allowing injecting additional dependency to OD runtime docker image
* allowing injecting additional dependency to OD runtime docker image
* support logic reasoning with pre-injected dependency
* get mint working
* update runtime build
* fix mint docker
* add test for keep_prompt;
add missing await close for some tests
* update integration tests for eventstream runtime
* fix integration tests for server runtime
* refactor ml bench and toolqa
* refactor webarena
* fix default factory
* Update run_infer.py
* add APIError to retry
* increase timeout for swebench
* make sure to hide api key when dump eval output
* update the behavior of put source code to put files instead of tarball
* add dishash to dependency
* sendintr when timeout
* fix dockerfile copy
* reduce timeout
* use dirhash to avoid repeat building for update source
* fix runtime_build testcase
* add dir_hash to docker build pipeline
* revert api error
* update poetry lock
* add retries for swebench run infer
* fix git patch
* update poetry lock
* adjust config order
* fix mount volumns
* enforce all eval to use "instance_id"
* remove file store from runtime
* make file_store public inside eventstream
* move the runtime logic inside `main` out
* support using async function for process_instance_fn
* refactor run_infer with the create_time
* fix file store
* Update evaluation/toolqa/utils.py
Co-authored-by: Graham Neubig <neubig@gmail.com>
* fix typo
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: super-dainiu <78588128+super-dainiu@users.noreply.github.com>
Co-authored-by: Graham Neubig <neubig@gmail.com>
* added workflow clean-up.yml to remove old workflows and artifacts
* dispatch-only run for now
* add retention-days of 14 to upload-artifact in ghcr.yml
* update the behavior of put source code to put files instead of tarball
* add dishash to dependency
* fix dockerfile copy
* use dirhash to avoid repeat building for update source
* fix runtime_build testcase
* add dir_hash to docker build pipeline
* add additional tests for source directory
* add comment
* clear the assertion by explictly check existing files
* also assert od is a dir
* ServerRuntime: config copy in init
* revert #3233 but more logging
* get_box_classes: reset order back to previous version
* 3 logging commands switched to debug (were info)
* runtimes debug output of config on initialization
* removed unneeded logger message from _init_container
* ghcr.yml with paths/paths-ignore conditions for pull_request
* include evaluation folder
* removed paths, just paths-ignore now
* deploy-docs only for docs
* exclude evaluation folder
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
---------
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
* support the ability to specify whether to keep prompt
* fix action serialization
* fix jupyter pwd with ~ as user name
* add test for keep_prompt;
add missing await close for some tests
* update integration tests for eventstream runtime
* fix integration tests for server runtime
* Remove global config from memory
* Remove runtime global config
* Remove from storage
* Remove global config
* Fix event stream tests
* Fix sandbox issue
* Change config
* Removed transferred tests
* Add swe env box
* Fixes on testing
* Fixed some tests
* Merge with stashed changes
* Fix typing
* Fix ipython test
* Revive function
* Make temp_dir fixture
* Remove test to avoid circular import
* fix eventstream filestore for test_runtime
* fix parse arg issue that cause integration test to fail
* support swebench pull from custom namespace
* add back simple tests for runtime
* move multi-line bash tests to test_runtime;
support multi-line bash for esruntime;
* add testcase to handle PS2 prompt
* use bashlex for bash parsing to handle multi-line commands;
add testcases for multi-line commands
* revert ghcr runtime change
* Apply stash
* fix run as other user;
make test async;
* fix test runtime for run as od
* add run-as-devin to all the runtime tests
* handle the case when username is root
* move all run-as-devin tests from sandbox;
only tests a few cases on different user to save time;
* move over multi-line echo related tests to test_runtime
* fix user-specific jupyter by fixing the pypoetry virtualenv folder
* make plugin's init async;
chdir at initialization of jupyter plugin;
move ipy simple testcase to test runtime;
* support agentskills import in
move tests for jupyter pwd tests;
overload `add_env_vars` for EventStreamRuntime to update env var also in Jupyter;
make agentskills read env var lazily, in case env var is updated;
* fix ServerRuntime agentskills issue
* move agnostic image test to test_runtime
* merge runtime tests in CI
* fix enable auto lint as env var
* update warning message
* update warning message
* test for different container images
* change parsing output as debug
* add exception handling for update_pwd_decorator
* fix unit test indentation
* add plugins as default input to Runtime class;
remove init_sandbox_plugins;
implement add_env_var (include jupyter) in the base class;
* fix server runtime auto lint
* Revert "add exception handling for update_pwd_decorator"
This reverts commit 2b668b1506.
* tries to print debugging info for agentskills
* explictly setting uid (try fix permission issue)
* Revert "tries to print debugging info for agentskills"
This reverts commit 8be4c86756.
* set sandbox user id during testing to hopefully fix the permission issue
* add browser tools for server runtime
* try to debug for old pwd
* update debug cmd
* only test agnostic runtime when TEST_RUNTIME is Server
* fix temp dir mkdir
* load TEST_RUNTIME at the beginning
* remove ipython tests
* only log to file when DEBUG
* default logging to project root
* temporarily remove log to file
* fix LLM logger dir
* fix logger
* make set pwd an optional aux action
* fix prev pwd
* fix infinity recursion
* simplify
* do not import the whole od library to avoid logger folder by jupyter
* fix browsing
* increase timeout
* attempt to fix agentskills yet again
* clean up in testcases, since CI maybe run as non-root
* add _cause attribute for event.id
* remove parent
* add a bunch of debugging statement again for CI :(
* fix temp_dir fixture
* change all temp dir to follow pytest's tmp_path_factory
* remove extra bracket
* clean up error printing a bit
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* add typing for tmp dir fixture
* clear the directory before running the test to avoid weird CI temp dir
* remove agnostic test case for server runtime
* Revert "remove agnostic test case for server runtime"
This reverts commit 30e2181c3f.
* disable agnostic tests in CI
* fix test
* make sure plugin arg is not passed when no plugin is specified;
remove redundant on_event function;
* move mock prompt
* rename runtime
* remove extra logging
* refactor run_controller's interface;
support multiple runtime for integration test;
filter out hostname for prompt
* uncomment other tests
* pass the right runtime to controller
* log runtime when start
* uncomment tests
* improve symbol filters
* add intergration test prompts that seemd ok
* add integration test workflow
* add python3 to default ubuntu image
* symlink python and fix permission to jupyter pip
* add retry for jupyter execute server
* fix jupyter pip install;
add post-process for jupyter pip install;
simplify init by add agent_skills path to PYTHONPATH;
add testcase to tests jupyter pip install;
* fix bug
* use ubuntu:22.04 for eventstream integration tests
* add todo
* update testcase
* remove redundant code
* fix unit test
* reduce dependency for runtime
* try making llama-index an optional dependency that's not installed by default
* remove pip install since it seemd not needed
* log ipython execution;
await write message since it returns a future
* update ipy testcase
* do not install llama-index in CI
* do not install llama-index in the app docker as well
* set sandbox container image in the integration test script
* log plugins & env var for runtime
* update conftest for sha256
* add git
* remove all non-alphanumeric chalracters
* add working ipy module tests!
* default to use host network
* remove is_async from browser to make thing a little more reliable;
retry loading browser when error;
* add sleep to wait a bit for http server
* kill http server before regenerate browsing tests
* fix browsing
* only set sandbox container image if undefined
* skip empty config value
* update evaluation to use the latest run_controller
* revert logger in execute_server to be compatible with server runtime
* revert logging level to fix jupyter
* set logger level
* revert the logging
* chmod for workspace to fix permission
* support getting timeout from action
* update test for server runtime
* try to fix file permission
* fix test_cmd_run_action_serialization_deserialization test (added timeout)
* poetry: pip 24.2, torch 2.2.2
* revert adding pip to pyproject.toml
* add build to dependencies in pyproject.toml
* forgot poetry lock --no-update
* fix a DelegatorAgent prompt_002.log (timeout)
* fix a DelegatorAgent prompt_003.log (timeout)
* couple more timeout attribs in prompt files
* some more prompt files
* prompts galore
* add clarification comment for timeout
* default timeout to config
* add assert
* update integraton tests for eventstream
* update integration tests
* fix timeout for action<->dict
* remove redundant on_event
* fix action execution timeout
* updatelock
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: tobitege <tobitege@gmx.de>
* LLM class: added acompletion and streaming, unit test test_acompletion.py
* LLM: cleanup of self.config defaults and their use
* added set_missing_attributes to LLMConfig
* move default checker up
* add copy to
* implement for ServerRuntime
* implement copyto for runtime (required by eval);
add tests for copy to
* fix exist file check
* unify copy_to_behavior and fix stuff
* make sure codeact agent produce message in u/a/u/a order
* integration tests
* sync message changes to codeact swe
* fix integration tests
---------
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* reduce dependency for runtime
* try making llama-index an optional dependency that's not installed by default
* do not install llama-index in CI
* do not install llama-index in the app docker as well
* Remove global config from memory
* Remove runtime global config
* Remove from storage
* Remove global config
* Fix event stream tests
* Fix sandbox issue
* Change config
* Removed transferred tests
* Add swe env box
* Fixes on testing
* Fixed some tests
* Merge with stashed changes
* Fix typing
* Fix ipython test
* Revive function
* Make temp_dir fixture
* Remove test to avoid circular import
* fix eventstream filestore for test_runtime
* fix parse arg issue that cause integration test to fail
* support swebench pull from custom namespace
* add back simple tests for runtime
* move multi-line bash tests to test_runtime;
support multi-line bash for esruntime;
* add testcase to handle PS2 prompt
* use bashlex for bash parsing to handle multi-line commands;
add testcases for multi-line commands
* revert ghcr runtime change
* Apply stash
* fix run as other user;
make test async;
* fix test runtime for run as od
* add run-as-devin to all the runtime tests
* handle the case when username is root
* move all run-as-devin tests from sandbox;
only tests a few cases on different user to save time;
* move over multi-line echo related tests to test_runtime
* fix user-specific jupyter by fixing the pypoetry virtualenv folder
* make plugin's init async;
chdir at initialization of jupyter plugin;
move ipy simple testcase to test runtime;
* support agentskills import in
move tests for jupyter pwd tests;
overload `add_env_vars` for EventStreamRuntime to update env var also in Jupyter;
make agentskills read env var lazily, in case env var is updated;
* fix ServerRuntime agentskills issue
* move agnostic image test to test_runtime
* merge runtime tests in CI
* fix enable auto lint as env var
* update warning message
* update warning message
* test for different container images
* change parsing output as debug
* add exception handling for update_pwd_decorator
* fix unit test indentation
* add plugins as default input to Runtime class;
remove init_sandbox_plugins;
implement add_env_var (include jupyter) in the base class;
* fix server runtime auto lint
* Revert "add exception handling for update_pwd_decorator"
This reverts commit 2b668b1506.
* tries to print debugging info for agentskills
* explictly setting uid (try fix permission issue)
* Revert "tries to print debugging info for agentskills"
This reverts commit 8be4c86756.
* set sandbox user id during testing to hopefully fix the permission issue
* add browser tools for server runtime
* try to debug for old pwd
* update debug cmd
* only test agnostic runtime when TEST_RUNTIME is Server
* fix temp dir mkdir
* load TEST_RUNTIME at the beginning
* remove ipython tests
* only log to file when DEBUG
* default logging to project root
* temporarily remove log to file
* fix LLM logger dir
* fix logger
* make set pwd an optional aux action
* fix prev pwd
* fix infinity recursion
* simplify
* do not import the whole od library to avoid logger folder by jupyter
* fix browsing
* increase timeout
* attempt to fix agentskills yet again
* clean up in testcases, since CI maybe run as non-root
* add _cause attribute for event.id
* remove parent
* add a bunch of debugging statement again for CI :(
* fix temp_dir fixture
* change all temp dir to follow pytest's tmp_path_factory
* remove extra bracket
* clean up error printing a bit
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* jupyter chdir to self.config.workspace_mount_path_in_sandbox on initialization
* add typing for tmp dir fixture
* clear the directory before running the test to avoid weird CI temp dir
* remove agnostic test case for server runtime
* Revert "remove agnostic test case for server runtime"
This reverts commit 30e2181c3f.
* disable agnostic tests in CI
* fix test
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* split_bash_commands replaced; temp_dir fixture fix in some tests
* tweak test_runtime
* skip 2 tests in test_runtime that need fixing in extra PR
* reverting bash parsing changes and re-enabled tests
* missed to revert a changed assert in test_runtime.py
* Remove global config from memory
* Remove runtime global config
* Remove from storage
* Remove global config
* Fix event stream tests
* Fix sandbox issue
* Change config
* Removed transferred tests
* Add swe env box
* Fixes on testing
* Fixed some tests
* Merge with stashed changes
* Fix typing
* Fix ipython test
* Revive function
* Make temp_dir fixture
* Remove test to avoid circular import
* fix eventstream filestore for test_runtime
* fix parse arg issue that cause integration test to fail
* support swebench pull from custom namespace
* add back simple tests for runtime
* move multi-line bash tests to test_runtime;
support multi-line bash for esruntime;
* add testcase to handle PS2 prompt
* use bashlex for bash parsing to handle multi-line commands;
add testcases for multi-line commands
* revert ghcr runtime change
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
I noticed that in dark modes the icons don't look as good as they could - making the outlines transparent makes them pop a bit more
Co-authored-by: Tim O'Farrell <tofarr@Tims-MacBook-Pro-2.local>
* colima: fix return code handling; added delay before retry; 4 retries
* moved docker context outside of function
* changed delete occurence; added logs output
* removed delete; trying to add more logging
* fix typo
* changed logging to github-style. maybe this finally shows up.
* reverted context; loop now with install+delete and alternating IP
* fix local keyword
* try limactl for creating an instance for IP
* revert IP change attempts
* actually return 0 in start_colima
* moved install out of loop again
* another to avoid duplicate start of colima via limactl
* added --init call for lima.yaml file creation
* dont trust an LLM to give you flags...
* Update run-unit-tests.yml
* colima: use a docker context specific to runner; prevent duplicate start
* updated use of context (for docker, not colima)
* added --ssh to colima start to use TCP instead of socket
* replace --ssh with random port
* test_runtime_client.py to test _execute_bash()
* runtime_build and runtime tweaks
* fix in docker script
* revert bash changes
* use sandbox_config.update_source_code to control source code update
* add od_version to the sandbox tag
* add doc instruction for update source code
* do not remove whole poetry folder;
add mamba clean
* add missing newlines
* cleanup runtime dockerfile into jinja template
* make prep temp file a separate function;
make that function accessible through cli
* modify `runtime_build.py` so it can generate directory for building docker img
* add dockerfile and sdist of runtime to gitignore since it will be dynamically generated
* add runtime to build
* do not rebuild new image when an `od_runtime` is provided
* use default container_image for testing if possible
* move runtime tests to ghcr runtime workflow
* update docker base dir for runtime
* fix unittest
* fix image name
* fix image name for test case
* rename to make it consistent
---------
Co-authored-by: tobitege <tobitege@gmx.de>
* fix: make max_budget_per_task optional in `run_agent_controller`
* update arg for each run infer
* fix: metrics logging carried along; reset llm metric with the agent;
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* test_runtime_client.py to test _execute_bash()
* runtime_build and runtime tweaks
* fix in docker script
* revert bash changes
* use sandbox_config.update_source_code to control source code update
* add od_version to the sandbox tag
* add doc instruction for update source code
* do not remove whole poetry folder;
add mamba clean
* add missing newlines
---------
Co-authored-by: tobitege <tobitege@gmx.de>
* update and polish gptq eval
* fix typo
* Update evaluation/gpqa/README.md
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Update evaluation/gpqa/run_infer.py
Co-authored-by: Graham Neubig <neubig@gmail.com>
* add headless mode to all appropriate agent controller call
* delegate set to error when in headless mode
* try to deduplicate a bit
* make headless_mode default to True and only change it to false for AgentSession
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Refactor and remove useless test
* Refactor and test feedback modal artifacts
* Update and pass test
* Replace select with radio buttons
* Store and retrieve user email during feedback
* Improve post share feedback toast
* Fix tests
* Add test todo
* WIP for integrate aider linter, see OpenDevin#2220
Updated aider linter to:
* Always return text and line numbers
* Moved extract line number more consistently
* Changed pylint to stop after first linter detects errors
Updated agentskills
* To get back a LintResult object and then use lines and text for error message and related line number
* Moved code for extracting line number to aider linter
Tests:
* Added additional unit tests for aider to test for
* Return values from lint failures
* Confirm linter works for non-configured languages like Ruby
* move to agent_skills, fixes not seeing skills error
* format/lint to new code, fix failing tests, remove unused code from aider linter
* small changes (remove litellm, fix readme typo)
* fix failing sandbox test
* keep, change dumping of metadata
* WIP for integrate aider linter, see OpenDevin#2220
Updated aider linter to:
* Always return text and line numbers
* Moved extract line number more consistently
* Changed pylint to stop after first linter detects errors
Updated agentskills
* To get back a LintResult object and then use lines and text for error message and related line number
* Moved code for extracting line number to aider linter
Tests:
* Added additional unit tests for aider to test for
* Return values from lint failures
* Confirm linter works for non-configured languages like Ruby
* move to agent_skills, fixes not seeing skills error
* format/lint to new code, fix failing tests, remove unused code from aider linter
* remove duplication of tree-sitter, grep-ast and update poetry.lock
* revert to main branch poetry.lock version
* only update necessary package
* fix jupyter kernel wrong interpreter issue (only for swebench)
* fix failing lint tests
* update syntax error checks for flake
* update poetry lock file
* update poetry.lock file, which update content-hash
* add grep ast
* remove extra stuff caused by merge
* update pyproject
* remove extra pytest fixture, ruff styling fixes
* lint files
* update poetry.lock file
---------
Co-authored-by: Jeff Katzy <jeffreyerickatz@gmail.com>
Co-authored-by: yufansong <yufan@risingwave-labs.com>
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
Co-authored-by: tobitege <tobitege@gmx.de>
* Fix env variables, prompt, and exit
(cherry picked from commit b45bc1638397427ec5e82540c63c4cda0d1e2094)
* fix echo
* Run without docker
to avoid running as root.
---------
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
* deprecating recall action
* fix integration tests
* fix integration tests
* refractor runtime to use async
* remove search memory
* rename .initialize to .ainit
* draft of runtime image building (separate from img agnostic)
* refractor runtime build into separate file and add unit tests for it
* fix image agnostic tests
* move `split_bash_commands` into a separate util file
* fix bash pexcept parsing for env
* refractor add_env_var from sandbox to runtime;
add test runtime for env var, remove it from sandbox;
* remove unclear comment
* capture broader error
* make `add_env_var` handle multiple export at the same time
* add multi env var test
* fix tests with new config
* make runtime tests a separate ci to avoid full disk
* Update Runtime README with architecture diagram and detailed explanations
* update test
* remove dependency of global config in sandbox test
* fix sandbox typo
* runtime tests does not need ghcr build now
* remove download runtime img
* remove dependency of global config in sandbox test
* fix sandbox typo
* try to free disk before running the tests
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* try to reduce code duplication
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Update opendevin/runtime/client/README.md
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* cleanup before setup
* temporarily remove this enable lint test since env var are now handled by runtime
* linter
---------
Co-authored-by: OpenDevin <opendevin@all-hands.dev>
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
* Updated documentation using ruff's autofix feature
* Updated pyproject.toml to include docstring validations
* Updated documentation using ruff's autofix feature
* Updated pyproject.toml to include docstring validations
* Updated docstrings using ruff's autfix feature
* Deleted opendevin/runtime/utils/soource.py, Keeping in sync with main
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
This PR changes the directions in development.md to run all tests.
Note that I opted to explicitly specify `test_*.py` instead of doing test discovery so it's obvious that you can also specify specific files.
* fix the case when source and tmp are not on the same device
* always build a dev box (with updated source code) for development purpose
* tail the log before removing the container
* move browse function
* support browser!
* support loading a particular runtime class via config.runtime (default to server to not break things)
* move image agnostic util to shared runtime util
* move dependency
* include poetry.lock in sdist
* accept port as arg for client
* make client start server with specified port
* update image agnostic utility for eventstream runtime
* make client and runtime working with REST API
* rename execute_server
* add plugin to initialize stuff inside es-runtime;
cleanup runtime methods to delegate everything to container
* remove redundant ls -alh
* fix jupyter
* improve logging in agnostic sandbox
* improve logging of test function
* add read & edit
* update agnostic sandbox
* support setting work dir at start
* fix file read/write test
* fix unit test
* update tescase
* Fix unit test again
* fix unit test again again
* add replace-based block edit & preliminary test case fix
* further fix the insert behavior
* make edit only work on first occurence
* bump codeact version since we now use new edit agentskills
* update prompt for new agentskills
* update integration tests
* make run_infer.sh executable
* remove code block for edit_file
* update integration test for prompt changes
* default to not use hint for eval
* fix insert emptyfile bug
* throw value error when `to_replace` is empty
* make `_edit_or_insert_file` return string so we can try to fix some linter errors (best attempt)
* add todo
* update integration test
* fix sandbox test for this PR
* fix inserting with additional newline
* rename to edit_file_by_replace
* add back `edit_file_by_line`
* update prompt for new editing tool
* fix integration tests
* bump codeact version since there are more changes
* add back append file
* fix current line for append
* fix append unit tests
* change the location where we show edited line no to agent and fix tests
* update integration tests
* fix global window size affect by open_file bug
* fix global window size affect by open_file bug
* increase window size to 300
* add file beginning and ending marker to avoid looping
* expand the editor window to better display edit error for model
* refractor to breakdown edit to internal functions
* reduce window to 200
* move window to 100
* refractor to cleanup some logic into _calculate_window_bounds
* fix integration tests
* fix sandbox test on new prompt
* update demonstration with new changes
* fix integration
* initialize llm inside process_instance to circumvent "AttributeError: Can't pickle local object"
* update kwargs
* retry for internal server error
* fix max iteration
* override max iter from config
* fix integration tests
* remove edit file by line
* fix integration tests
* add instruction to avoid hanging
* Revert "add instruction to avoid hanging"
This reverts commit 06fd2c5938.
* handle content policy violation error
* fix integration tests
* fix typo in prompt - the window is 100
* update all integration tests
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: Xingyao Wang <xingyao@all-hands.dev>
Currently, OpenDevin uses a global singleton LLM config and a global singleton agent config. This PR allows customers to configure an LLM config for each agent. A hypothetically useful scenario is to use a cheaper LLM for repo exploration / code search, and a more powerful LLM to actually do the problem solving (CodeActAgent).
Partially solves #2075 (web GUI improvement is not the goal of this PR)
* CI: Support uploading frontend unit test coverage.
* Add make-i18n before test.
* Update vitest configuration to include only .ts and .tsx files in coverage.
* remove .only in test and fix the failed tests.
* Add text summary.
* Move vite-tsconfig-paths to dev dep. Adjust UTs.
---------
Signed-off-by: ifuryst <ifuryst@gmail.com>
Co-authored-by: sp.wack <83104063+amanape@users.noreply.github.com>
- Ensure users get the most recent stable release version when pulling default image.
- Explains the main tag for those who want the most recent updates.
* bump swebench version since the fix PR is merged
* add empy generation stats from latest pr
* delete eval_outputs if it already exists
* handle non string patch
* refactor: Enhance file handling and code editing functionality
# PR Summary
**refactor: Enhance file handling and code editing functionality**
## PR Description
This pull request includes improvements to file handling, error management, and code editing functionality across multiple files. The changes enhance the robustness, security, and user experience of the application.
### Changes in `listen.py`
1. **Imports and Error Handling**:
- Removed `warnings` import and its usage with `litellm`.
- More consistent use of `JSONResponse` and `HTTPException` for error handling.
2. **WebSocket Endpoint (`/ws`)**:
- Simplified logic for handling events using a single `isinstance` check.
3. **New Endpoint**:
- Added `/api/save-file` POST endpoint for saving file contents.
- Implemented checks for agent state before allowing file edits.
4. **Code Style and Organization**:
- Improved code formatting and organization.
- Refactored some functions for better readability and consistency.
### Changes in `fileService.ts`
1. **Error Handling**:
- Added try-catch blocks to all functions for better error handling and logging.
2. **Input Sanitization**:
- Implemented `encodeURIComponent()` for file names and paths in API requests.
3. **Type Checking**:
- Added type checks for API responses to ensure data format consistency.
4. **File Upload Improvement**:
- Refactored `uploadFiles()` to use `Array.from(files)` instead of a for loop.
5. **New Functionality**:
- Added `saveFile()` function to allow saving file content to a specified path.
### Changes in `CodeEditor.tsx`
1. **New Dependencies**:
- Added imports for state management, UI components, and file operations.
2. **State Management**:
- Introduced new state variables for tracking save status and last saved time.
- Implemented Redux state management for code and agent state.
3. **UI Enhancements**:
- Added a save button with dynamic colors based on save status.
- Implemented a save notification system.
- Added a "Last saved" timestamp display.
4. **File Saving Functionality**:
- Implemented complete file saving feature with error handling and user feedback.
5. **Code Structure**:
- Improved structure with additional hooks and memoized values for optimization.
### Testing Performed
- Manually tested new file saving functionality.
- Verified error handling and user feedback mechanisms.
- Checked integration between backend (`listen.py`) and frontend (`fileService.ts`, `CodeEditor.tsx`).
### Next Steps
- Conduct thorough testing of the file saving feature across different scenarios.
- Update documentation to reflect new file handling capabilities.
- Consider adding unit tests for new functions and components.
* Added Docstrings back
Added Docstrings back
* Fix
# Allow Code Editing in AWAITING_USER_INPUT State
## Description
This pull request extends the functionality of the code editor to allow editing when the agent is in the AWAITING_USER_INPUT state, in addition to the existing PAUSED and FINISHED states.
## Changes
1. Backend (`listen.py`):
- Updated the `save_file` function to allow saving when the agent state is AWAITING_USER_INPUT.
2. Frontend (`CodeEditor.tsx`):
- Modified the `isEditingAllowed` condition to include the AWAITING_USER_INPUT state.
## Files Changed
- `listen.py`
- `CodeEditor.tsx`
## Testing
- Verified that the save button appears when the agent is in the AWAITING_USER_INPUT state.
- Tested saving files in all three allowed states (PAUSED, FINISHED, AWAITING_USER_INPUT).
- Ensured that saving is still prohibited in other agent states.
## Additional Notes
This change improves the user experience by allowing code edits while the agent is waiting for user input, which is a common scenario in interactive coding sessions.
* Add internationalization for 'File saved successfully' message
# Add internationalization for 'File saved successfully' message
## Description
This PR adds internationalization support for the "File saved successfully" message in the CodeEditor component. It updates the translation.json file to include translations for multiple languages and modifies the CodeEditor.tsx file to use the new translation key.
## Changes
1. Updated `translation.json`:
- Added a new key `CODE_EDITOR$FILE_SAVED_SUCCESSFULLY` with translations for multiple languages.
- Ensured the file structure supports multiple languages per key.
2. Modified `CodeEditor.tsx`:
- Updated the success message to use the new translation key.
- Applied the translation to both the toast notification and the on-screen notification.
## Why
These changes improve the user experience for non-English speakers by providing localized feedback when a file is successfully saved. This aligns with our goal of making the application more accessible to a global audience.
## How to Test
1. Change the application language to different supported languages.
2. Open the CodeEditor, make changes to a file, and save it.
3. Verify that the "File saved successfully" message appears in the correct language for both the toast and on-screen notifications.
## Additional Notes
Please pay special attention to the structure of the translation.json file to ensure it follows our established patterns for internationalization.
* Add toast notifications for error handling in fileService
# Add toast notifications for error handling in fileService
## Description
This PR enhances the error handling in the `fileService.ts` file by adding toast notifications for user feedback. It maintains the existing console error logging for debugging purposes while improving the user experience by providing visible error messages in the UI.
## Changes
- Added import for the toast utility
- Implemented toast.error() calls in catch blocks for all file operations
- Kept console.error() calls for detailed logging
- Updated error messages to be more user-friendly
## Files Changed
- `src/services/fileService.ts`
## Testing
- Tested all file operations (select, upload, list, save) to ensure proper error handling
- Verified that toast notifications appear when errors are simulated
- Confirmed that console errors are still logged for debugging
## Additional Notes
This change improves error visibility for users without altering the underlying error handling logic. It should make troubleshooting easier for both users and developers.
* Add file path safety check and improve error handling in file services
# Add file path safety check and improve error handling in file services
## Description
This PR enhances the `fileService.ts` by adding a safety check for file paths in the `saveFile` function and improves error handling across all file operations. It also includes new translations for various file-related error messages.
## Changes
1. Updated `src/services/fileService.ts`:
- Added a validation check for file paths in the saveFile function
- Improved error handling for all file operations (select, upload, list, save)
- Implemented toast error messages with translation support
2. Updated `src/i18n/translations.json`:
- Added new translation keys for file service error messages:
- FILE_SERVICE$SELECT_FILE_ERROR
- FILE_SERVICE$UPLOAD_FILES_ERROR
- FILE_SERVICE$LIST_FILES_ERROR
- FILE_SERVICE$SAVE_FILE_ERROR
- FILE_SERVICE$INVALID_FILE_PATH
## Files Changed
- `src/services/fileService.ts`
- `src/i18n/translations.json`
## Key Implementation Details
```typescript
export async function saveFile(filePath: string, content: string): Promise<void> {
const { t } = useTranslation();
if (!filePath || filePath.includes('..')) {
toast.error(t(I18nKey.FILE_SERVICE$INVALID_FILE_PATH));
throw new Error('Invalid file path');
}
try {
// Existing implementation...
} catch (error) {
console.error('Error saving file:', error);
toast.error(t(I18nKey.FILE_SERVICE$SAVE_FILE_ERROR), 'File Save Error');
throw error;
}
}
```
## Testing
- Verified that the saveFile function rejects invalid file paths (empty or containing '..')
- Confirmed that appropriate error messages are displayed using toast notifications for all file operations
- Tested with different languages to ensure translated messages appear correctly
## Security Implications
The file path check in saveFile enhances security by preventing potential directory traversal attacks.
## Next Steps
- Consider adding similar safety checks to other file operations if applicable
- Ensure thorough testing of error scenarios across all supported languages
* Add docstrings to listen.py
# Add docstrings to listen.py
## Description
This PR adds comprehensive docstrings to all functions in the `listen.py` file. These additions improve code documentation, making the file more readable and maintainable for current and future developers.
## Changes
- Added docstrings to all functions in `listen.py`
- Docstrings follow the Google Python Style Guide format
- Included descriptions, parameters, return values, and potential exceptions for each function
## Files Changed
- `src/listen.py`
## Docstring Example
Here's an example of one of the added docstrings:
```python
@app.post('/api/save-file')
async def save_file(request: Request):
"""
Save a file to the agent's runtime file store.
This endpoint allows saving a file when the agent is in a paused, finished,
or awaiting user input state. It checks the agent's state before proceeding
with the file save operation.
Args:
request (Request): The incoming FastAPI request object.
Returns:
JSONResponse: A JSON response indicating the success of the operation.
Raises:
HTTPException:
- 403 error if the agent is not in an allowed state for editing.
- 400 error if the file path or content is missing.
- 500 error if there's an unexpected error during the save operation.
"""
# Function implementation...
```
## Impact
- Improved code readability and maintainability
- Better understanding of function purposes, inputs, outputs, and potential errors
- Easier onboarding for new developers working on this file
- Enhanced IDE support for function descriptions and parameter information
## Testing
- No functional changes were made, so existing tests should pass without modification
- Manual review of docstrings for accuracy and completeness is recommended
## Next Steps
- Consider adding similar docstrings to other files in the project for consistency
- Review the added docstrings to ensure they accurately describe the current functionality
- Update docstrings as needed when function implementations change in the future
## Additional Notes
The existing code structure and functionality remain unchanged. This PR focuses solely on improving documentation through the addition of docstrings.
* Revert exclude_list formatting and add docstrings in listen.py
# Revert exclude_list formatting and add docstrings in listen.py
## Description
This PR makes two main changes to the `listen.py` file:
1. Reverts the `exclude_list` in the `list_files` function to its original format, with each item on a separate line.
2. Adds comprehensive docstrings to all functions in the file.
These changes improve code readability, maintain consistency with project standards, and enhance documentation for better maintainability.
## Changes
1. Updated `opendevin/server/listen.py`:
- Reverted `exclude_list` formatting in `list_files` function
- Added docstrings to all functions
## Detailed Changes
### 1. Reverted exclude_list formatting
```python
exclude_list = (
'.git',
'.DS_Store',
'.svn',
'.hg',
'.idea',
'.vscode',
'.settings',
'.pytest_cache',
'__pycache__',
'node_modules',
'vendor',
'build',
'dist',
'bin',
'logs',
'log',
'tmp',
'temp',
'coverage',
'venv',
'env',
)
```
### 2. Added docstrings (example)
```python
@app.get('/api/list-files')
def list_files(request: Request, path: str = '/'):
"""
List files in the specified path.
This function retrieves a list of files from the agent's runtime file store,
excluding certain system and hidden files/directories.
Args:
request (Request): The incoming request object.
path (str, optional): The path to list files from. Defaults to '/'.
Returns:
list: A list of file names in the specified path.
Raises:
HTTPException: If there's an error listing the files.
"""
# Function implementation...
```
## Rationale
- Reverting `exclude_list` formatting maintains consistency with the project's coding style and ensures proper functioning of pre-commit hooks.
- Adding docstrings improves code documentation, making it easier for developers to understand and maintain the codebase.
## Impact
- Improved code readability and consistency
- Enhanced documentation for all functions in `listen.py`
- Easier onboarding for new developers
- Better IDE support for function descriptions and parameter information
## Testing
- No functional changes were made, so existing tests should pass without modification
- Manual review of the reverted `exclude_list` and new docstrings is recommended
## Additional Notes
- The existing code functionality remains unchanged
- All functions in `listen.py` now have detailed docstrings following the Google Python Style Guide format
## Next Steps
- Review the added docstrings to ensure they accurately describe the current functionality
- Consider adding similar docstrings to other files in the project for consistency
- Update docstrings as needed when function implementations change in the future
* made code reviewable
* fixed ruff issues
* Update listen.py docstrings
* final tweaks
* re-added encodedURIComponent in selectFile
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: sp.wack <83104063+amanape@users.noreply.github.com>
* add replace-based block edit & preliminary test case fix
* further fix the insert behavior
* make edit only work on first occurence
* bump codeact version since we now use new edit agentskills
* update prompt for new agentskills
* update integration tests
* make run_infer.sh executable
* remove code block for edit_file
* update integration test for prompt changes
* default to not use hint for eval
* fix insert emptyfile bug
* throw value error when `to_replace` is empty
* make `_edit_or_insert_file` return string so we can try to fix some linter errors (best attempt)
* add todo
* update integration test
* fix sandbox test for this PR
* add newline after patch to fix patch apply
* new swebench wip
* add newline after patch to fix patch apply
* only add newline if not empty
* update swebench source and update
* update gitignore for swebench eval
* update old prep_eval
* update gitignore
* add scripts for push and pull swebench images
* update eval_infer.sh
* update eval_infer for new docker workflow
* update script to create markdown report based on report.json
* update eval infer to use update output
* update readme
* only move result to folder if running whole file
* remove set-x
* update conversion script
* Update evaluation/swe_bench/README.md
* Update evaluation/swe_bench/README.md
* Update evaluation/swe_bench/README.md
* make sure last line end with newline
* switch to an fix attempt branch of swebench
* Update evaluation/swe_bench/README.md
* Update evaluation/swe_bench/README.md
---------
Co-authored-by: Engel Nyst <enyst@users.noreply.github.com>
* Update documentation with some consistency
* Make windows troubleshooting a little more clear
* Apply suggestions from code review
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
---------
Co-authored-by: Mahmoud Work <mahmoudwork@mahmouds-mini.home>
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
* add event to stream before budget check
* make the budget check before the step
* Update opendevin/controller/agent_controller.py
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
---------
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
1. Add support for rejection action on frontend
2. Show users the reason for rejection
3. Get rid of weird empty box after delegation
4. On web GUI, show customer when a delegation starts and ends
* Add "Copy" Button to Chat Messages
### PR Overview: Add "Copy" Button to Chat Messages
**Description:**
This PR introduces a "Copy" button to each chat message in the `ChatMessage` component. The button allows users to easily copy the content of a chat message to their clipboard. The implementation includes a button with a clipboard icon and the necessary functionality to copy the message content.
**Changes Made:**
1. **Imports:**
- Added `FaClipboard` from `react-icons/fa` for the clipboard icon.
- Added `toast` from `#utils/toast` for displaying notifications.
2. **New Functionality:**
- Implemented `copyToClipboard` function using `navigator.clipboard.writeText` to copy the message content.
- Added a button element with an `onClick` handler to trigger the `copyToClipboard` function.
3. **UI Enhancements:**
- The button is styled to match the existing UI and is placed next to the message content.
**Code Changes:**
- Modified `frontend/src/components/chat/ChatMessage.tsx` to include the new button and functionality.
**Testing:**
- Verified that clicking the "Copy" button copies the message content to the clipboard.
- Confirmed that a toast notification appears upon successful copy or failure.
**Example Code:**
```tsx
import React from "react";
import Markdown from "react-markdown";
import { twMerge } from "tailwind-merge";
import { code } from "../markdown/code";
import { FaClipboard } from "react-icons/fa";
import toast from "#/utils/toast"; // Assuming you have a toast utility for notifications
interface MessageProps {
message: Message;
}
function ChatMessage({ message }: MessageProps) {
const className = twMerge(
"markdown-body",
"p-3 text-white max-w-[90%] overflow-y-auto rounded-lg",
message.sender === "user" ? "bg-neutral-700 self-end" : "bg-neutral-500",
);
const copyToClipboard = () => {
navigator.clipboard.writeText(message.content).then(() => {
toast.info("Message copied to clipboard!");
}).catch((error) => {
toast.error(`Failed to copy message: ${error}`);
});
};
return (
<div data-testid="message" className={className}>
<div className="flex justify-between items-center">
<Markdown components={{ code }}>{message.content}</Markdown>
<button
onClick={copyToClipboard}
className="ml-2 p-1 bg-neutral-600 rounded hover:bg-neutral-500"
aria-label="Copy message"
>
<FaClipboard />
</button>
</div>
</div>
);
}
export default ChatMessage;
```
**Notes:**
- Ensure that the `react-icons` package is installed (`npm install react-icons` or `yarn add react-icons`).
- The toast utility is assumed to be available for notifications. If not, consider using an alternative notification method.
* layout enhancements; linting
---------
Co-authored-by: tobitege <tobitege@gmx.de>
Co-authored-by: sp.wack <83104063+amanape@users.noreply.github.com>
* updated version; added Action to update pyproject version by current tag (if changed)
* higer pyproject version creates a tag now
* Release-only run to write tag to pyproject
* feat(i18n): initial i18n setup
- Configured i18n settings in docusaurus.config.js
- Implemented Translate component and translate function in key components
* docs(i18n): complete documentation internationalization
- Added support for Simplified Chinese and French
* Update docs/i18n/zh-Hans/docusaurus-plugin-content-docs/current/usage/troubleshooting/troubleshooting.md
* Update docs/i18n/zh-Hans/docusaurus-plugin-content-docs/current/usage/troubleshooting/troubleshooting.md
* Update docs/i18n/zh-Hans/docusaurus-plugin-content-docs/current/usage/troubleshooting/troubleshooting.md
* fix(build): resolve broken links causing build failure
- Fix issue causing build errors due to broken links in Docusaurus documentation.
- Resolve uncontrolled resource consumption in braces (see: https://github.com/advisories/GHSA-grv7-fg5c-xmjg).
- Bump Docusaurus to ^3.4.0 to fix MDX loader: linkify should process the md AST instead of the md string.
* fix: sync with commit 868b746
- Change to `docusaurus write-translations` to provide translation for JSON files.
---------
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Fix Mac CI Test
* Start colima service
* unlink colima dependency: go
* Check for colima
Co-authored-by: Graham Neubig <neubig@gmail.com>
* fix indent
Co-authored-by: Graham Neubig <neubig@gmail.com>
* Try with uninstall
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
* tmp
* tmp
* merge main
* feat: auto build image cache
* remove plugins
* use config file
* update mamba setup shell
* support agnostic sandbox image autobuild
* remove config
* Update .gitignore
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
* Update opendevin/runtime/docker/ssh_box.py
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
* update setup.sh
* readd sudo
* add sudo in dockerfile
* remove export
* move od-runtime dependencies to sandbox dockerfile
* factor out re-build logic into a separate util file
* tweak existing plugin to use OD specific sandbox
* update testcase
* attempt to fix unit test using image built in ghcr
* use cache tag
* try to fix unit tests
* add unittest
* add unittest
* add some unittests
* revert gh workflow changes
* feat: optimize sandbox image naming rule
* add pull latest image hint
* add opendevin python hint and use mamba to install gcc
* update docker image naming rule and fix mamba issue
* Update opendevin/runtime/docker/ssh_box.py
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
* fix: opendevin user use correct pip
* fix lint issue
* fix custom sandbox base image
* rename test name
* add skipif
---------
Co-authored-by: Graham Neubig <neubig@gmail.com>
Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
Co-authored-by: Boxuan Li <liboxuan@connect.hku.hk>
Co-authored-by: Yufan Song <33971064+yufansong@users.noreply.github.com>
Co-authored-by: tobitege <tobitege@gmx.de>
* Fix Docker tagging issue with upper case
* Update containers/build.sh
Co-authored-by: மனோஜ்குமார் பழனிச்சாமி <smartmanoj42857@gmail.com>
* Use tr command which is available on both zsh and bash
* Lower image name
* Lower image name
* Update .github/workflows/ghcr.yml
Co-authored-by: மனோஜ்குமார் பழனிச்சாமி <smartmanoj42857@gmail.com>
* Fix shell syntax
---------
Co-authored-by: மனோஜ்குமார் பழனிச்சாமி <smartmanoj42857@gmail.com>
* Split container image build & push
* Code cleanup
* Cleanup
* Add back useless docker_build_success step to make CI happy
* Revert "Cleanup"
This reverts commit 2a260791a9.
* Use fresh built sandbox image in integration test
* fix dependency
* DEBUG: only build
* Attempt to fix dependency
* Change dependency
* Combine both jobs
* Fix env
* Remove Mac integration tests as they are too unstable
* Move sandbox tests to ghcr
* Use loaded image
* docs: Update Development and CONTRIBUTING docs
* Explain the PR process in simpler terms
* Fix formatting
---------
Co-authored-by: Mahmoud Work <mahmoudwork@mahmouds-mini.home>
* Time travel for evaluation
* Fix source script path
* Exit script if given version doesn't exist
* Exit on failure
* Update README
* Change scripts of all other benchmarks
* Modify README files
* Fix logic_reasoning README
* Exit regenerate.sh upon common known errors
* More fixes
* Remove mention of transient issue
* Use tmp file instead of tty
* Remove redundant cleanup
value:Thank you for taking the time to fill out this bug report. We greatly appreciate your effort to complete this template fully. Please provide as much information as possible to help us understand and address the issue effectively.
value:Thank you for taking the time to fill out this bug report. Please provide as much information as possible to help us understand and address the issue effectively.
- type:checkboxes
attributes:
label:Is there an existing issue for the same bug?
description:Please check if an issue already exists for the bug you encountered.
options:
- label:I have checked the troubleshooting document at https://opendevin.github.io/OpenDevin/modules/usage/troubleshooting
required:true
- label:I have checked the existing issues.
required:true
- type:textarea
id:bug-description
attributes:
label:Describe the bug
description:Provide a short description of the problem.
label:Describe the bug and reproduction steps
description:Provide a description of the issue along with any reproduction steps.
validations:
required:true
- type:textarea
id:current-version
- type:dropdown
id:installation
attributes:
label:Current OpenDevin version
description:What version of OpenDevin are you using? If you're running in docker, tell us the tag you're using (e.g. ghcr.io/opendevin/opendevin:0.3.1).
render:bash
validations:
required:true
label:OpenHands Installation
description:How are you running OpenHands?
options:
- Docker command in README
- Development workflow
default:0
- type:textarea
id:config
- type:input
id:openhands-version
attributes:
label:Installation and Configuration
description:Please provide any commands you ran and any configuration (redacting API keys)
render:bash
validations:
required:true
label:OpenHands Version
description:What version of OpenHands are you using?
placeholder:ex. 0.9.8, main, etc.
- type:textarea
id:model-agent
attributes:
label:Model and Agent
description:What model and agent are you using? You can see these settings in the UI by clicking the settings wheel.
placeholder:|
- Model:
- Agent:
- type:textarea
id:os-version
- type:dropdown
id:os
attributes:
label:Operating System
description:What Operating System are you using? Linux, Mac OS, WSL on Windows
- type:textarea
id:repro-steps
attributes:
label:Reproduction Steps
description:Please list the steps to reproduce the issue.
placeholder:|
1.
2.
3.
options:
- MacOS
- Linux
- WSL on Windows
- type:textarea
id:additional-context
attributes:
label:Logs, Errors, Screenshots, and Additional Context
description:LLM logs will be stored in the `logs/llm/default` folder. Please add any additional context about the problem here.
description:Please provide any additional information you think might help. If you want to share the chat history
you can click the thumbs-down (👎) button above the input field and you will get a shareable link
(you can also click thumbs up when things are going well of course!). LLM logs will be stored in the
`logs/llm/default` folder. Please add any additional context about the problem here.
poetry run ./evaluation/integration_tests/scripts/run_infer.sh llm.eval HEAD CodeActAgent '' $N_PROCESSES
# get evaluation report
REPORT_FILE=$(find evaluation/evaluation_outputs/outputs/integration_tests/CodeActAgent/deepseek-chat_maxiter_10_N* -name "report.md" -type f | head -n 1)
poetry run ./evaluation/swe_bench/scripts/run_infer.sh llm.eval HEAD CodeActAgent 300 30 $N_PROCESSES "princeton-nlp/SWE-bench_Lite" test
OUTPUT_FOLDER=$(find evaluation/evaluation_outputs/outputs/princeton-nlp__SWE-bench_Lite-test/CodeActAgent -name "deepseek-chat_maxiter_50_N_*-no-hint-run_1" -type d | head -n 1)
echo "OUTPUT_FOLDER for SWE-bench evaluation: $OUTPUT_FOLDER"
poetry run ./evaluation/swe_bench/scripts/eval_infer_remote.sh $OUTPUT_FOLDER/output.jsonl $N_PROCESSES "princeton-nlp/SWE-bench_Lite" test
poetry run ./evaluation/swe_bench/scripts/eval/summarize_outputs.py $OUTPUT_FOLDER/output.jsonl > summarize_outputs.log 2>&1
echo "SWEBENCH_REPORT<<EOF" >> $GITHUB_ENV
cat summarize_outputs.log >> $GITHUB_ENV
echo "EOF" >> $GITHUB_ENV
- name:Create tar.gz of evaluation outputs
run:|
TIMESTAMP=$(date +'%y-%m-%d-%H-%M')
tar -czvf evaluation_outputs_${TIMESTAMP}.tar.gz evaluation/evaluation_outputs/outputs
echo "Your coworker wants to apply a pull request to this project. Read and review ${{ github.event.pull_request.number }}.diff file. Create a review-${{ github.event.pull_request.number }}.txt and write your concise comments and suggestions there." > task.txt
echo "Your coworker wants to apply a pull request to this project." > task.txt
echo "Read and review ${{ github.event.pull_request.number }}.diff file. Create a review-${{ github.event.pull_request.number }}.txt and write your concise comments and suggestions there." >> task.txt
echo "Do not ask me for confirmation at any point." >> task.txt
# Workflow that marks issues and PRs with no activity for 30 days with "Stale" and closes them after 7 more days of no activity
name:'Close stale issues'
# Runs every day at 01:30
on:
schedule:
- cron:'30 1 * * *'
@@ -9,21 +12,10 @@ jobs:
steps:
- uses:actions/stale@v9
with:
# Aggressively close issues that have been explicitly labeled `age-out`
any-of-labels:age-out
stale-issue-message:'This issue is stale because it has been open for 7 days with no activity. Remove stale label or comment or this will be closed in 1 day.'
close-issue-message:'This issue was closed because it has been stalled for over 7 days with no activity.'
stale-pr-message:'This PR is stale because it has been open for 7 days with no activity. Remove stale label or comment or this will be closed in 1 days.'
close-pr-message:'This PR was closed because it has been stalled for over 7 days with no activity.'
days-before-stale:7
days-before-close:1
- uses:actions/stale@v9
with:
# Be more lenient with other issues
stale-issue-message:'This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-issue-message:'This issue was closed because it has been stalled for over 30 days with no activity.'
stale-pr-message:'This PR is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-pr-message:'This PR was closed because it has been stalled for over 30 days with no activity.'
days-before-stale:30
exempt-issue-labels:'tracked'
close-issue-message:'This issue was closed because it has been stalled for over 30 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for over 30 days with no activity.'
OpenHands is an automated AI software engineer. It is a repo with a Python backend
(in the `openhands` directory) and TypeScript frontend (in the `frontend` directory).
General Setup:
- To set up the entire repo, including frontend and backend, run `make build`
- To run linting and type-checking before finishing the job, run `poetry run pre-commit run --all-files --config ./dev_config/python/.pre-commit-config.yaml`
Backend:
- Located in the `openhands` directory
- Testing:
- All tests are in `tests/unit/test_*.py`
- To test new code, run `poetry run pytest tests/unit/test_xxx.py` where `xxx` is the appropriate file for the current functionality
- Write all tests with pytest
Frontend:
- Located in the `frontend` directory
- Prerequisites: A recent version of NodeJS / NPM
- Setup: Run `npm install` in the frontend directory
- Testing:
- Run tests: `npm run test`
- To run specific tests: `npm run test -- -t "TestName"`
- Building:
- Build for production: `npm run build`
- Environment Variables:
- Set in `frontend/.env` or as environment variables
- Available variables: VITE_BACKEND_HOST, VITE_USE_TLS, VITE_INSECURE_SKIP_VERIFY, VITE_FRONTEND_PORT
- Internationalization:
- Generate i18n declaration file: `npm run make-i18n`
We have a separate doc [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md) that tells you how to set up a development workflow.
Set the official repository as your [upstream](https://www.atlassian.com/git/tutorials/git-forks-and-upstreams) to synchronize with the latest update in the official repository.
You should see both `origin` and `upstream` in the output.
1.**Download and use** OpenHands, and send [issues](https://github.com/All-Hands-AI/OpenHands/issues) when you encounter something that isn't working or a feature that you'd like to see.
2.**Send feedback** after each session by [clicking the thumbs-up thumbs-down buttons](https://docs.all-hands.dev/modules/usage/feedback), so we can see where things are working and failing, and also build an open dataset for training code agents.
3.**Improve the Codebase** by sending PRs (see details below). In particular, we have some [good first issues](https://github.com/All-Hands-AI/OpenHands/labels/good%20first%20issue) that may be ones to start on.
### 3. Synchronize with Official Repository
Synchronize latest commit with official repository before coding.
## What can I build?
Here are a few ways you can help improve the codebase.
```shell
git fetch upstream
git checkout main
git merge upstream/main
git push origin main
```
#### UI/UX
We're always looking to improve the look and feel of the application. If you've got a small fix
for something that's bugging you, feel free to open up a PR that changes the `./frontend` directory.
### 4. Create a New Branch And Open a Pull Request
After you finish implementation, open forked repository. The source branch is your new branch, and the target branch is `OpenDevin/OpenDevin``main` branch. Then PR should appears in [OpenDevin PRs](https://github.com/OpenDevin/OpenDevin/pulls).
If you're looking to make a bigger change, add a new UI element, or significantly alter the style
of the application, please open an issue first, or better, join the #frontend channel in our Slack
to gather consensus from our design team first.
Then OpenDevin team will review your code.
#### Improving the agent
Our main agent is the CodeAct agent. You can [see its prompts here](https://github.com/All-Hands-AI/OpenHands/tree/main/openhands/agenthub/codeact_agent)
## PR Rules
Changes to these prompts, and to the underlying behavior in Python, can have a huge impact on user experience.
You can try modifying the prompts to see how they change the behavior of the agent as you use the app
locally, but we will need to do an end-to-end evaluation of any changes here to ensure that the agent
is getting better over time.
### 1. Pull Request title
We use the [SWE-bench](https://www.swebench.com/) benchmark to test our agent. You can join the #evaluation
channel in Slack to learn more.
As described in [here](https://github.com/commitizen/conventional-commit-types/blob/master/index.json), a valid PR title should begin with one of the following prefixes:
#### Adding a new agent
You may want to experiment with building new types of agents. You can add an agent to `openhands/agenthub`
to help expand the capabilities of OpenHands.
#### Adding a new runtime
The agent needs a place to run code and commands. When you run OpenHands on your laptop, it uses a Docker container
to do this by default. But there are other ways of creating a sandbox for the agent.
If you work for a company that provides a cloud-based runtime, you could help us add support for that runtime
by implementing the [interface specified here](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/runtime.py).
#### Testing
When you write code, it is also good to write tests. Please navigate to the `tests` folder to see existing test suites.
At the moment, we have two kinds of tests: `unit` and `integration`. Please refer to the README for each test suite. These tests also run on GitHub's continuous integration to ensure quality of the project.
## Sending Pull Requests to OpenHands
You'll need to fork our repository to send us a Pull Request. You can learn more
about how to fork a GitHub repo and open a PR with your changes in [this article](https://medium.com/swlh/forks-and-pull-requests-how-to-contribute-to-github-repos-8843fac34ce8)
### Pull Request title
As described [here](https://github.com/commitizen/conventional-commit-types/blob/master/index.json), a valid PR title should begin with one of the following prefixes:
-`feat`: A new feature
-`fix`: A bug fix
-`doc`: Documentation only changes
-`docs`: Documentation only changes
-`style`: Changes that do not affect the meaning of the code (white space, formatting, missing semicolons, etc.)
-`refactor`: A code change that neither fixes a bug nor adds a feature
-`style`: A refactoring that improves code style
-`perf`: A code change that improves performance
-`test`: Adding missing tests or correcting existing tests
-`ci`: Changes to CI configuration files and scripts (example scopes: `.github`, `ci` (Buildkite))
-`build`: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
-`ci`: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
-`chore`: Other changes that don't modify src or test files
-`revert`: Reverts a previous commit
@@ -65,26 +84,11 @@ For example, a PR title could be:
-`refactor: modify package path`
-`feat(frontend): xxxx`, where `(frontend)` means that this PR mainly focuses on the frontend component.
You may also check out previous PRs in the [PR list](https://github.com/OpenDevin/OpenDevin/pulls).
As described in [here](https://github.com/OpenDevin/OpenDevin/labels), we create several labels. Every PR should be tagged with the corresponding labels.
### 2. Pull Request description
You may also check out previous PRs in the [PR list](https://github.com/All-Hands-AI/OpenHands/pulls).
### Pull Request description
- If your PR is small (such as a typo fix), you can go brief.
- If it is large and you have changed a lot, it's better to write more details.
- If it contains a lot of changes, it's better to write more details.
## How to begin
Please refer to the README in each module:
- [frontend](./frontend/README.md)
- [agenthub](./agenthub/README.md)
- [evaluation](./evaluation/README.md)
- [opendevin](./opendevin/README.md)
- [server](./opendevin/server/README.md)
- [mock server](./opendevin/mock/README.md)
## Tests
Please navigate to `tests` folder to see existing test suites.
At the moment, we have two kinds of tests: `unit` and `integration`. Please refer to the README for each test suite. These tests also run on CI to ensure quality of
the project.
If your changes are user-facing (e.g. a new feature in the UI, a change in behavior, or a bugfix)
please include a short message that we can add to our changelog.
We would like to thank all the [contributors](https://github.com/All-Hands-AI/OpenHands/graphs/contributors) who have helped make OpenHands possible. We greatly appreciate your dedication and hard work.
## Open Source Projects
OpenHands includes and adapts the following open source projects. We are grateful for their contributions to the open source community:
- Description: AI pair programming tool. OpenHands has adapted and integrated its linter module for code-related tasks in [`agentskills utilities`](https://github.com/All-Hands-AI/OpenHands/tree/main/openhands/runtime/plugins/agent_skills/utils/aider)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
### BSD 3-Clause License
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
### Apache License 2.0
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
This guide is for people working on OpenDevin and editing the source code.
This guide is for people working on OpenHands and editing the source code.
If you wish to contribute your changes, check out the [CONTRIBUTING.md](https://github.com/All-Hands-AI/OpenHands/blob/main/CONTRIBUTING.md) on how to clone and setup the project initially before moving on.
Otherwise, you can clone the OpenHands project directly.
## Start the server for development
### 1. Requirements
* Linux, Mac OS, or [WSL on Windows](https://learn.microsoft.com/en-us/windows/wsl/install)
* Linux, Mac OS, or [WSL on Windows](https://learn.microsoft.com/en-us/windows/wsl/install) [Ubuntu <= 22.04]
* [Docker](https://docs.docker.com/engine/install/) (For those on MacOS, make sure to allow the default Docker socket to be used from advanced settings!)
Begin by building the project which includes setting up the environment and installing dependencies. This step ensures that OpenHands is ready to run on your system:
- **Build the Project:** Begin by building the project, which includes setting up the environment and installing dependencies. This step ensures that OpenDevin is ready to run smoothly on your system.
```bash
make build
```
```bash
make build
```
### 3. Configuring the Language Model
OpenHands supports a diverse array of Language Models (LMs) through the powerful [litellm](https://docs.litellm.ai) library. By default, we've chosen the mighty GPT-4 from OpenAI as our go-to model, but the world is your oyster! You can unleash the potential of Anthropic's suave Claude, the enigmatic Llama, or any other LM that piques your interest.
OpenDevin supports a diverse array of Language Models (LMs) through the powerful [litellm](https://docs.litellm.ai) library. By default, we've chosen the mighty GPT-4 from OpenAI as our go-to model, but the world is your oyster! You can unleash the potential of Anthropic's suave Claude, the enigmatic Llama, or any other LM that piques your interest.
To configure the LM of your choice, run:
To configure the LM of your choice, follow these steps:
1. **Using the Makefile: The Effortless Approach**
With a single command, you can have a smooth LM setup for your OpenDevin experience. Simply run:
```bash
make setup-config
```
This command will prompt you to enter the LLM API key, model name, and other variables ensuring that OpenDevin is tailored to your specific needs. Note that the model name will apply only when you run headless. If you use the UI, please set the model in the UI.
Set `persist_sandbox` to false if you want to use clean sandbox for each task. If `persist_sandbox` is set to true, you will need to set the `ssh_password` as well.
This command will prompt you to enter the LLM API key, model name, and other variables ensuring that OpenHands is tailored to your specific needs. Note that the model name will apply only when you run headless. If you use the UI, please set the model in the UI.
Note: If you have previously run OpenHands using the docker command, you may have already set some environmental variables in your terminal. The final configurations are set from highest to lowest priority:
Some alternative models may prove more challenging to tame than others. Fear not, brave adventurer! We shall soon unveil LLM-specific documentation to guide you on your quest. And if you've already mastered the art of wielding a model other than OpenAI's GPT, we encourage you to [share your setup instructions with us](https://github.com/OpenDevin/OpenDevin/issues/417).
Some alternative models may prove more challenging to tame than others. Fear not, brave adventurer! We shall soon unveil LLM-specific documentation to guide you on your quest.
And if you've already mastered the art of wielding a model other than OpenAI's GPT, we encourage you to share your setup instructions with us by creating instructions and adding it [to our documentation](https://github.com/All-Hands-AI/OpenHands/tree/main/docs/modules/usage/llms).
For a full list of the LM providers and models available, please consult the [litellm documentation](https://docs.litellm.ai/docs/providers).
There is also [documentation for running with local models using ollama](./docs/documentation/LOCAL_LLM_GUIDE.md).
### 4. Run the Application
- **Run the Application:** Once the setup is complete, launching OpenDevin is as simple as running a single command. This command starts both the backend and frontend servers seamlessly, allowing you to interact with OpenDevin without any hassle.
```bash
make run
```
### 5. Individual Server Startup
### 4. Running the application
#### Option A: Run the Full Application
Once the setup is complete, launching OpenHands is as simple as running a single command. This command starts both the backend and frontend servers seamlessly, allowing you to interact with OpenHands:
```bash
make run
```
#### Option B: Individual Server Startup
- **Start the Backend Server:** If you prefer, you can start the backend server independently to focus on backend-related tasks or configurations.
```bash
make start-backend
@@ -74,29 +76,53 @@ There is also [documentation for running with local models using ollama](./docs/
```
### 6. LLM Debugging
If you encounter any issues with the Language Model (LM) or you're simply curious, you can inspect the actual LLM prompts and responses. To do so, export DEBUG=1 in the environment and restart the backend. OpenDevin will then log the prompts and responses in the logs/llm/CURRENT_DATE directory, allowing you to identify the causes.
If you encounter any issues with the Language Model (LM) or you're simply curious, you can inspect the actual LLM prompts and responses. To do so, export DEBUG=1 in the environment and restart the backend.
OpenHands will then log the prompts and responses in the logs/llm/CURRENT_DATE directory, allowing you to identify the causes.
### 7. Help
- **Get Some Help:** Need assistance or information on available targets and commands? The help command provides all the necessary guidance to ensure a smooth experience with OpenDevin.
```bash
make help
```
Need assistance or information on available targets and commands? The help command provides all the necessary guidance to ensure a smooth experience with OpenHands.
```bash
make help
```
### 8. Testing
To run tests, refer to the following:
#### Unit tests
```bash
poetry run pytest ./tests/unit/test_sandbox.py
poetry run pytest ./tests/unit/test_*.py
```
#### Integration tests
Please refer to [this README](./tests/integration/README.md) for details.
### 9. Add or update dependency
1. Add your dependency in `pyproject.toml` or use `poetry add xxx`
2. Update the poetry.lock file via `poetry lock --no-update`
### 9. Use existing Docker image
To reduce build time (e.g., if no changes were made to the client-runtime component), you can use an existing Docker container image. Follow these steps:
1. Set the SANDBOX_RUNTIME_CONTAINER_IMAGE environment variable to the desired Docker image.
These are the procedures and guidelines on how issues are triaged in this repo by the maintainers.
## General
* Most issues must be tagged with **enhancement** or **bug**
* Issues may be tagged with what it relates to (**backend**, **frontend**, **agent quality**, etc.)
## Severity
* **Low**: Minor issues, single user report
* **Medium**: Affecting multiple users
* **Critical**: Affecting all users or potential security issues
## Effort
* Issues may be estimated with effort required (**small effort**, **medium effort**, **large effort**)
## Difficulty
* Issues with low implementation difficulty may be tagged with **good first issue**
## Not Enough Information
* User is asked to provide more information (logs, how to reproduce, etc.) when the issue is not clear
* If an issue is unclear and the author does not provide more information or respond to a request, the issue may be closed as **not planned** (Usually after a week)
## Multiple Requests/Fixes in One Issue
* These issues will be narrowed down to one request/fix so the issue is more easily tracked and fixed
* Issues may be broken down into multiple issues if required
<a href="https://docs.all-hands.dev/modules/usage/getting-started"><img src="https://img.shields.io/badge/Documentation-000?logo=googledocs&logoColor=FFE165&style=for-the-badge" alt="Check out the documentation"></a>
<a href="https://arxiv.org/abs/2407.16741"><img src="https://img.shields.io/badge/Paper%20on%20Arxiv-000?logoColor=FFE165&logo=arxiv&style=for-the-badge" alt="Paper on Arxiv"></a>
<h1 align="center">OpenDevin: Code Less, Make More</h1>
<a href="https://opendevin.github.io/OpenDevin/"><img src="https://img.shields.io/badge/Documentation-OpenDevin-blue?logo=googledocs&logoColor=white&style=for-the-badge" alt="Check out the documentation"></a>
</div>
<hr>
Welcome to OpenHands (formerly OpenDevin), a platform for software development agents powered by AI.
Welcome to OpenDevin, a platform for autonomous software engineers, powered by AI and LLMs.
OpenHands agents can do anything a human developer can: modify code, run commands, browse the web,
call APIs, and yes—even copy code snippets from StackOverflow.
OpenDevin agents collaborate with human developers to write code, fix bugs, and ship features.
Learn more at [docs.all-hands.dev](https://docs.all-hands.dev), or jump to the [Quick Start](#-quick-start).
You'll find OpenDevin running at [http://localhost:3000](http://localhost:3000) with access to `./workspace`. To have OpenDevin operate on your code, place it in `./workspace`.
You'll find OpenHands running at [http://localhost:3000](http://localhost:3000)!
OpenDevin will only have access to this workspace folder. The rest of your system will not be affected as it runs in a secured docker sandbox.
Finally, you'll need a model provider and API key.
[Anthropic's Claude 3.5 Sonnet](https://www.anthropic.com/api) (`anthropic/claude-3-5-sonnet-20241022`)
works best, but you have [many options](https://docs.all-hands.dev/modules/usage/llms).
## 🚀 Documentation
---
To learn more about the project, and for tips on using OpenDevin,
**check out our [documentation](https://opendevin.github.io/OpenDevin/)**.
You can also [connect OpenHands to your local filesystem](https://docs.all-hands.dev/modules/usage/runtimes),
run OpenHands in a scriptable [headless mode](https://docs.all-hands.dev/modules/usage/how-to/headless-mode),
interact with it via a [friendly CLI](https://docs.all-hands.dev/modules/usage/how-to/cli-mode),
or run it on tagged issues with [a github action](https://github.com/All-Hands-AI/OpenHands-resolver).
There you'll find resources on how to use different LLM providers (like ollama and Anthropic's Claude),
Visit [Installation](https://docs.all-hands.dev/modules/usage/installation) for more information and setup instructions.
If you want to modify the OpenHands source code, check out [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
Having issues? The [Troubleshooting Guide](https://docs.all-hands.dev/modules/usage/troubleshooting) can help.
## 📖 Documentation
To learn more about the project, and for tips on using OpenHands,
**check out our [documentation](https://docs.all-hands.dev/modules/usage/getting-started)**.
There you'll find resources on how to use different LLM providers,
troubleshooting resources, and advanced configuration options.
## 🤝 How to Contribute
OpenDevin is a community-driven project, and we welcome contributions from everyone.
OpenHands is a community-driven project, and we welcome contributions from everyone.
Whether you're a developer, a researcher, or simply enthusiastic about advancing the field of
software engineering with AI, there are many ways to get involved:
- **Code Contributions:** Help us develop new agents, core functionality, the frontend and other interfaces, or sandboxing solutions.
- **Research and Evaluation:** Contribute to our understanding of LLMs in software engineering, participate in evaluating the models, or suggest improvements.
- **Feedback and Testing:** Use the OpenDevin toolset, report bugs, suggest features, or provide feedback on usability.
- **Feedback and Testing:** Use the OpenHands toolset, report bugs, suggest features, or provide feedback on usability.
For details, please check [CONTRIBUTING.md](./CONTRIBUTING.md).
## 🤖 Join Our Community
Whether you're a developer, a researcher, or simply enthusiastic about OpenDevin, we'd love to have you in our community.
Whether you're a developer, a researcher, or simply enthusiastic about OpenHands, we'd love to have you in our community.
Let's make software engineering better together!
- [Slack workspace](https://join.slack.com/t/opendevin/shared_invite/zt-2jsrl32uf-fTeeFjNyNYxqSZt5NPY3fA) - Here we talk about research, architecture, and future development.
- [Slack workspace](https://join.slack.com/t/openhands-ai/shared_invite/zt-2tom0er4l-JeNUGHt_AxpEfIBstbLPiw) - Here we talk about research, architecture, and future development.
- [Discord server](https://discord.gg/ESHStjSjD4) - This is a community-run server for general discussion, questions, and feedback.
## 📈 Progress
<p align="center">
<a href="https://www.swebench.com/lite.html">
<img src="/docs/static/img/results.png" alt="SWE-Bench Lite Score" width="500" height="auto">
OpenHands is built by a large number of contributors, and every contribution is greatly appreciated! We also build upon other open source projects, and we are deeply thankful fortheir work.
For a list of open source projects and licenses used in OpenHands, please see our [CREDITS.md](./CREDITS.md) file.
## 📚 Cite
```
@misc{opendevin2024,
author = {{OpenDevin Team}},
title = {{OpenDevin: An Open Platform for AI Software Developers as Generalist Agents}},
note = {Accessed: ENTER THE DATE YOU ACCESSED THE PROJECT}
@misc{openhands,
title={{OpenHands: An Open Platform for AI Software Developers as Generalist Agents}},
author={Xingyao Wang and Boxuan Li and Yufan Song and Frank F. Xu and Xiangru Tang and Mingchen Zhuge and Jiayi Pan and Yueqi Song and Bowen Li and Jaskirat Singh and Hoang H. Tran and Fuqiang Li and Ren Ma and Mingzhang Zheng and Bill Qian and Yanjun Shao and Niklas Muennighoff and Yizhe Zhang and Binyuan Hui and Junyang Lin and Robert Brennan and Hao Peng and Heng Ji and Graham Neubig},
In this folder, there may exist multiple implementations of `Agent` that will be used by the framework.
For example, `agenthub/codeact_agent`, etc.
Contributors from different backgrounds and interests can choose to contribute to any (or all!) of these directions.
## Constructing an Agent
The abstraction for an agent can be found [here](../opendevin/controller/agent.py).
Agents are run inside of a loop. At each iteration, `agent.step()` is called with a
[State](../opendevin/controller/state/state.py) input, and the agent must output an [Action](../opendevin/events/action).
Every agent also has a `self.llm` which it can use to interact with the LLM configured by the user.
See the [LiteLLM docs for `self.llm.completion`](https://docs.litellm.ai/docs/completion).
## State
The `state` contains:
- A history of actions taken by the agent, as well as any observations (e.g. file content, command output) from those actions
- A list of actions/observations that have happened since the most recent step
- A [`root_task`](https://github.com/OpenDevin/OpenDevin/blob/main/opendevin/controller/state/task.py), which contains a plan of action
- The agent can add and modify subtasks through the `AddTaskAction` and `ModifyTaskAction`
## Actions
Here is a list of available Actions, which can be returned by `agent.step()`:
- [`CmdRunAction`](../opendevin/events/action/commands.py) - Runs a command inside a sandboxed terminal
- [`CmdKillAction`](../opendevin/events/action/commands.py) - Kills a background command
- [`IPythonRunCellAction`](../opendevin/events/action/commands.py) - Execute a block of Python code interactively (in Jupyter notebook) and receives `CmdOutputObservation`. Requires setting up `jupyter` [plugin](../opendevin/runtime/plugins) as a requirement.
- [`FileReadAction`](../opendevin/events/action/files.py) - Reads the content of a file
- [`FileWriteAction`](../opendevin/events/action/files.py) - Writes new content to a file
- [`BrowseURLAction`](../opendevin/events/action/browse.py) - Gets the content of a URL
- [`AgentRecallAction`](../opendevin/events/action/agent.py) - Searches memory (e.g. a vector database)
- [`AddTaskAction`](../opendevin/events/action/tasks.py) - Adds a subtask to the plan
- [`ModifyTaskAction`](../opendevin/events/action/tasks.py) - Changes the state of a subtask.
- [`AgentFinishAction`](../opendevin/events/action/agent.py) - Stops the control loop, allowing the user/delegator agent to enter a new task
- [`AgentRejectAction`](../opendevin/events/action/agent.py) - Stops the control loop, allowing the user/delegator agent to enter a new task
- [`AgentFinishAction`](../opendevin/events/action/agent.py) - Stops the control loop, allowing the user to enter a new task
- [`MessageAction`](../opendevin/events/action/message.py) - Represents a message from an agent or the user
You can use `action.to_dict()` and `action_from_dict` to serialize and deserialize actions.
## Observations
There are also several types of Observations. These are typically available in the step following the corresponding Action.
But they may also appear as a result of asynchronous events (e.g. a message from the user, logs from a command running
To start implementing Conway's Game of Life in Python using the pygame library, I first need to set up a Python script file where I can write the code. I'll create a new Python file named `game_of_life.py`. This file will serve as the base for writing the game logic and using pygame functionalities.
Action:
"""
write game_of_life.py # This is a placeholder for the game of life implementation using pygame.
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='# This is a placeholder for the game of life implementation using pygame.', start=0, end=-1, thoughts="Thoughts:\nTo start implementing Conway's Game of Life in Python using the pygame library, I first need to set up a Python script file where I can write the code. I'll create a new Python file named `game_of_life.py`. This file will serve as the base for writing the game logic and using pygame functionalities.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 0:-1.
==============
STEP 1
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
The placeholder for the game of life implementation using pygame has been set up in the file `game_of_life.py`. The next step is to start implementing the basic structure of the game. This includes importing necessary libraries, initializing the pygame module, setting up the display window, and defining the main game loop. I will begin by importing pygame and initializing it, which are the foundational steps for any pygame application.
Action:
"""
edit 0 0 import pygame
pygame.init()
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='import pygame\n\npygame.init()', start=0, end=0, thoughts='Thoughts:\nThe placeholder for the game of life implementation using pygame has been set up in the file `game_of_life.py`. The next step is to start implementing the basic structure of the game. This includes importing necessary libraries, initializing the pygame module, setting up the display window, and defining the main game loop. I will begin by importing pygame and initializing it, which are the foundational steps for any pygame application.\n\nAction:', action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 0:0.
==============
STEP 2
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
Previously, I initialized pygame in the `game_of_life.py` file. The next step is to set up the display window for the game. This involves defining the size of the window and setting the title. This is crucial as it provides the visual interface for the game. I will also add a comment to indicate that this is the setup for the display window.
Action:
"""
edit 2 2
# Setup the display window
screen_size = (800, 600)
screen = pygame.display.set_mode(screen_size)
pygame.display.set_caption("Conway's Game of Life")
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='# Setup the display window\nscreen_size = (800, 600)\nscreen = pygame.display.set_mode(screen_size)\npygame.display.set_caption("Conway\'s Game of Life")', start=2, end=2, thoughts='Thoughts:\nPreviously, I initialized pygame in the `game_of_life.py` file. The next step is to set up the display window for the game. This involves defining the size of the window and setting the title. This is crucial as it provides the visual interface for the game. I will also add a comment to indicate that this is the setup for the display window.\n\nAction:', action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 2:2.
==============
STEP 3
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame and setting up the display window. The next step is to define the main game loop where the game's logic will be continuously updated and rendered. This loop will handle events, update the game state, and redraw the screen. I will start by defining the main loop structure and a basic event handling mechanism to allow for quitting the game when the user presses the close button.
Action:
"""
edit 5 5 # Main game loop
running = True
while running:
for event in pygame.event.get():
if event.type == pygame.QUIT:
running = False
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='# Main game loop\nrunning = True\nwhile running:\n for event in pygame.event.get():\n if event.type == pygame.QUIT:\n running = False', start=5, end=5, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame and setting up the display window. The next step is to define the main game loop where the game's logic will be continuously updated and rendered. This loop will handle events, update the game state, and redraw the screen. I will start by defining the main loop structure and a basic event handling mechanism to allow for quitting the game when the user presses the close button.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 5:5.
==============
STEP 4
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, and defining the main game loop. The next step is to implement the logic for Conway's Game of Life. This involves creating a grid to represent the game state, initializing it with a random pattern, and defining the rules for cell survival, birth, and death. I will start by defining the grid size and initializing the grid with random states.
Action:
"""
edit 7 7 # Define grid size and initialize grid
grid_size = (50, 50) # Grid size as a tuple (rows, columns)
grid = [[0 for x in range(grid_size[1])] for y in range(grid_size[0])] # Initialize grid with zeros
import random
for y in range(grid_size[0]):
for x in range(grid_size[1]):
grid[y][x] = random.randint(0, 1) # Randomly assign cells as alive (1) or dead (0)
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='# Define grid size and initialize grid\ngrid_size = (50, 50) # Grid size as a tuple (rows, columns)\ngrid = [[0 for x in range(grid_size[1])] for y in range(grid_size[0])] # Initialize grid with zeros\nimport random\nfor y in range(grid_size[0]):\n for x in range(grid_size[1]):\n grid[y][x] = random.randint(0, 1) # Randomly assign cells as alive (1) or dead (0)', start=7, end=7, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, and defining the main game loop. The next step is to implement the logic for Conway's Game of Life. This involves creating a grid to represent the game state, initializing it with a random pattern, and defining the rules for cell survival, birth, and death. I will start by defining the grid size and initializing the grid with random states.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 7:7.
==============
STEP 5
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, and initializing the grid with random states. The next step is to implement the rules for Conway's Game of Life. This involves checking each cell's neighbors to determine its next state based on the number of alive neighbors. I will start by defining a function to count the alive neighbors for a given cell.
if 0 <= nx < grid_size[1] and 0 <= ny < grid_size[0]:
count += grid[ny][nx]
return count
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='def count_alive_neighbors(grid, x, y):\n directions = [(-1, -1), (-1, 0), (-1, 1), (0, -1), (0, 1), (1, -1), (1, 0), (1, 1)]\n count = 0\n for dx, dy in directions:\n nx, ny = x + dx, y + dy\n if 0 <= nx < grid_size[1] and 0 <= ny < grid_size[0]:\n count += grid[ny][nx]\n return count', start=9, end=9, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, and initializing the grid with random states. The next step is to implement the rules for Conway's Game of Life. This involves checking each cell's neighbors to determine its next state based on the number of alive neighbors. I will start by defining a function to count the alive neighbors for a given cell.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 9:9.
==============
STEP 6
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating a function to count alive neighbors. The next step is to implement the rules for Conway's Game of Life. This involves updating the grid state based on the number of alive neighbors each cell has. I will define a function `update_grid` that applies the rules of the game to update the grid for the next generation.
Action:
"""
write game_of_life.py def update_grid(grid):
new_grid = [[0 for x in range(grid_size[1])] for y in range(grid_size[0])]
if grid[y][x] == 1 and (alive_neighbors == 2 or alive_neighbors == 3):
new_grid[y][x] = 1
elif grid[y][x] == 0 and alive_neighbors == 3:
new_grid[y][x] = 1
return new_grid
11
11
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='def update_grid(grid):\n new_grid = [[0 for x in range(grid_size[1])] for y in range(grid_size[0])]\n for y in range(grid_size[0]):\n for x in range(grid_size[1]):\n alive_neighbors = count_alive_neighbors(grid, x, y)\n if grid[y][x] == 1 and (alive_neighbors == 2 or alive_neighbors == 3):\n new_grid[y][x] = 1\n elif grid[y][x] == 0 and alive_neighbors == 3:\n new_grid[y][x] = 1\n return new_grid', start=11, end=11, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating a function to count alive neighbors. The next step is to implement the rules for Conway's Game of Life. This involves updating the grid state based on the number of alive neighbors each cell has. I will define a function `update_grid` that applies the rules of the game to update the grid for the next generation.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 11:11.
==============
STEP 7
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to integrate the `update_grid` function into the main game loop to continuously update the state of the grid based on the game rules. This will allow the game to evolve over time, showing different generations of the cell population.
Action:
"""
edit 6 6
grid = update_grid(grid)
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='grid = update_grid(grid)', start=6, end=6, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to integrate the `update_grid` function into the main game loop to continuously update the state of the grid based on the game rules. This will allow the game to evolve over time, showing different generations of the cell population.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 6:6.
==============
STEP 8
PLAN:
Please make conway's game of life in python using the pygame library. Be sure to use the tools in your workspace to help you out.
So far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to integrate the `update_grid` function into the main game loop to continuously update the state of the grid based on the game rules. This will allow the game to evolve over time, showing different generations of the cell population. I need to ensure that the `update_grid` function is called within the main game loop and that the display is updated accordingly. I will start by checking the current content of the main game loop to see where to integrate the `update_grid` function.
Action:
"""
goto 6
"""
==== END RAW ====
ACTION:
FileReadAction(path='game_of_life.py', start=6, end=106, thoughts="Thoughts:\nSo far, I have set up the basic structure for Conway's Game of Life using pygame, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to integrate the `update_grid` function into the main game loop to continuously update the state of the grid based on the game rules. This will allow the game to evolve over time, showing different generations of the cell population. I need to ensure that the `update_grid` function is called within the main game loop and that the display is updated accordingly. I will start by checking the current content of the main game loop to see where to integrate the `update_grid` function.\n\nAction:", action=<ActionType.READ: 'read'>)
OBSERVATION:
grid = update_grid(grid)
running = True
# Define grid size and initialize grid
grid_size = (50, 50) # Grid size as a tuple (rows, columns)
From the previous actions, it seems that the basic structure for Conway's Game of Life using pygame has been set up, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to ensure that the game loop properly updates the grid and refreshes the display to show the new state of the grid in each iteration. This involves calling `pygame.display.update()` to update the entire screen and using `pygame.time.Clock()` to control the frame rate. I will start by adding these necessary updates to the game loop.
Action:
"""
edit 95 95
pygame.display.update()
clock = pygame.time.Clock()
clock.tick(10) # Control the frame rate (10 frames per second)
"""
==== END RAW ====
ACTION:
FileWriteAction(path='game_of_life.py', content='pygame.display.update()\n clock = pygame.time.Clock()\n clock.tick(10) # Control the frame rate (10 frames per second)', start=95, end=95, thoughts="Thoughts:\nFrom the previous actions, it seems that the basic structure for Conway's Game of Life using pygame has been set up, including initializing pygame, setting up the display window, defining the main game loop, initializing the grid with random states, and creating functions to count alive neighbors and update the grid. The next step is to ensure that the game loop properly updates the grid and refreshes the display to show the new state of the grid in each iteration. This involves calling `pygame.display.update()` to update the entire screen and using `pygame.time.Clock()` to control the frame rate. I will start by adding these necessary updates to the game loop.\n\nAction:", action=<ActionType.WRITE: 'write'>)
OBSERVATION:
WRITE OPERATION:
You have written to "game_of_life.py" on these lines: 95:95.
16:43:55 - opendevin:INFO: agent_controller.py:125 - Exited before finishing the task.
```
## Result:
```
import pygame
# Setup the display window
screen_size = (800, 600)
screen = pygame.display.set_mode(screen_size)
# Main game loop
grid = update_grid(grid)
running = True
# Define grid size and initialize grid
grid_size = (50, 50) # Grid size as a tuple (rows, columns)
'read <file_name> [<start_line>] [<end_line>]':"Shows a given file's contents starting from <start_line> up to <end_line>. Default: start_line = 0, end_line = -1. By default the whole file will be read.",
'write <file> <changes> [<start_line>] [<end_line>]':'Modifies a <file> by replacing the current lines between <start_line> and <end_line> with <changes>. Default start_line = 0 and end_line = -1. Calling this with no line args will replace the whole file.',
'browse <url>':'Returns the text version of any url, this can be useful to look up documentation or finding issues on github',
'scroll_up':'Takes no arguments. This will scroll up and show you the 100 lines above your current lines',
'scroll_down':'Takes no arguments. This will scroll down and show you the 100 lines below your current lines',
'edit <start_line> <end_line> <changes>':'This will modify lines in the currently open file. use start_line and end_line to designate which lines to change and then write the multiline changes. Set end_line to -1 to denote the end of the file',
'goto <line_num>':'This will take you directly to a line and show you the 100 lines below it.',
'<bash_command> <args>':'You can use any bash command you need (cd, ls, rm, grep, dir, mv, wget, git, zip, etc.) with their arguments included',
'pip install <package>':'You can use this to import python packages. Make sure you include the correct package name when using this command.',
'ls':'Use the ls command to view all the files in your current directory, this is a good starting point.',
'NOT ALLOWED':'You cannot use interactive commands like python or node',
}
COMMAND_USAGE={
'exit':'Usage:\n```\nexit\n```\nExecuted when task is complete',
'read':"Args:\n<file_name> [<start_line>] [<end_line>]\nUsage:\n```\nread file.py\n```\nor\n```\nread example.py <start_line> <end_line>\n```\nShows a given file's contents starting from <start_line> up to <end_line>. Default: start_line = 0, end_line = -1. by default the whole file will be read.",
'write':'Args:\n<file> <changes> [<start_line>] [<end_line>]\nUsage:\n```\nwrite "def main():\n print("This is line one")" 0 2\n```\nModifies a <file> by replacing the current lines between <start_line> and <end_line> with <changes>. Default start_line = 0 and end_line = -1. Calling this with no line args will replace the whole file.',
'edit':'Args:\n<start_line> <end_line> <changes>\nUsage:\n```\nedit 0 1 import pandas as pd\n```\nThis will modify the current file you are in with the changes you make between the line numbers you designate',
'goto':'Args:\n<line_num>\nUsage:\n```\ngoto <line_num>\n```\nThis will show you the 100 lines below and including the line you specify within your current file.',
'scroll_up':'Usage:\n```\nscroll_up\n```\nThis will return the 100 lines above where you are currently at',
'scroll_down':'Usage:\n```\nscroll_down\n```\nThis will return the 100 line below where you are currently at',
'browse':'Args:\n<url>\nUsage:\n```\nbrowse https://github.com/OpenDevin/OpenDevin\n```\nThis will fetch the Text elements from the given url and show them to you.',
# from opendevin.parse_commands import parse_command_file
# USE parse_command_file(filepath) to get the custom commands
CUSTOM_DOCS=None
CUSTOM_COMMANDS=f"""Custom bash commands:
{CUSTOM_DOCS}
"""
DOCUMENTATION=f"""DOCUMENTATION:
It is recommend that you use the commands provided for interacting with files and your directory because they have been specially built for you.
They will make it much easier for you to look at files and make changes. Using these commands will help you be better at your task.
You can open an file by using either the read or write operations.
- If a file already exists you should read it before making any changes. Use the `edit` command to make changes once you have read it.
- If you are creating a new file use the write command. Use the `edit` command to make changes once you have created the new file.
Commands:
{DEFAULT_COMMANDS}
{CUSTOM_COMMANDS}
The following commands require an open file to be used: edit, scroll_up, scroll_down, goto
To modify the current file use 'edit'. To move through the current file use 'goto' or 'scroll_up'/'scroll_down'
when using write and edit do not surround the code with any "" just write the code.
"""
GENERAL_GUIDELINES="""INSTRUCTIONS:
Now, you're going to solve this issue on your own. You can use any bash commands or custom commands you wish to complete your task. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU CAN ONLY ENTER ONE COMMAND AT A TIME. You should always wait for feedback after every command.
When you're satisfied with all of the changes you've made, you can indicate that you are done by running the exit command.
Note however that you cannot use any interactive session commands (e.g. python, vim, node) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with `python <script_name>.py`.
NOTE ABOUT THE write COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Reproduce the bug: Always start by trying to replicate the bug that the issue discusses. If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment and run it to ensure you can reproduce the bug. Then, start trying to fix it. When you think you've fixed the bug, re-run the bug reproduction script to make sure that the issue has indeed been resolved.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file, so that you can be sure the script ran fine all the way through.
2. Try different commands: If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it.
3. Navigate large files: If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, you would use the 'read' command like this: 'read <file> 583'. This is a much faster way to read through the file.
4. Handle input files: If the bug reproduction script requires inputting/reading a specific file, such as 'buggy-input.png', and you'd like to understand how to input that file, conduct a search in the existing repository code to see whether someone else has already done that. Do this by running the command: 'search_dir "buggy-input.png"'. If that doesn't work, use the Linux 'find' command.
5. Understand your context: Always make sure to look at the currently open file and the current working directory. The currently open file might be in a different directory than the working directory.
6. Verify your edits: When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
7. Thoroughly test your solution: After making any changes to fix a bug, be sure to thoroughly test your solution to ensure the bug has been resolved. Re-run the bug reproduction script and verify that the issue has been addressed.
"""
RESPONSE_FORMAT="""RESPONSE FORMAT:
This is the format of the response you will make in order to solve the current issue.
You will be given multiple iterations to complete this task so break it into steps and solve them one by one.
Your output must contain the following:
- First, thoughts about what your next action should be and plan it out.
- You will have a memory of your thoughts so you can use this to remember things for the next step.
- Use your thoughts to think about what you are currently doing, what you have done on prior steps and how that relates to solving the problem.
- Second, create a piece of code that will execute your next action based on the thoughts you have.
- Remember that you can only have one action for each thought, do not include multiple actions.
Your code MUST be surrounded in triple back ticks EXACTLY like this:
```
<code>
```
Notes:
- Adhere to the format so that the program loop continues smoothly, it is very important to only give one command per output.
- DO NOT give more than one command within the triple backticks. This will just throw an error and nothing will happen as a result.
- Do not give multiple code blocks, if you do only the second one will be captured and run, this might give an error if the first one was necessary.
- To execute multiple commands you should write them down in your thoughts section so you can remember it on the next step and execute them then.
- The only commands you are not capable of executing are interactive commands like `python` or `node` by themselves.
- If you think that you have completed the task that has been given to you based on your previous actions and outputs then use ``` exit ``` as the command to let the system know that you are done.
- DO NOT make any copies of your previous memories, those will be provided to you at each step, making copies just wastes time and energy. Think smarter not harder.
- The write and edit commands requires proper indentation in the content section ex. `write hw.py def hello():\n print(\'Hello World\')` this is how you would have to format your write command.
- The white spaces matter as the code changes will be added to the code so they must have proper syntax.
This is a template using the format described above
Items in <> are suggestions for you, fill them out based on the context of the problem you are solving.
[ FORMAT ]
Thoughts:
<Provide clear and concise thoughts on the next step to take, highlighting any important details or context that should be remembered.>
<You can use multiple lines to express your thoughts>
Action:
```
<command> <params>
```
[ END FORMAT ]
Do not provide anything extra just your thought and action.
"""
SYSTEM_MESSAGE=f"""SYSTEM INFO:
You are an autonomous coding agent, here to provide solutions for coding issues.
You have been designed to assist with a wide range of programming tasks, from code editing and debugging to testing and deployment.
You have access to a variety of tools and commands that you can use to help you solve problems efficiently.
{GENERAL_GUIDELINES}
{DOCUMENTATION}
""".strip()
defNO_ACTION(latest):
returnf"""
You did not include any action to take in your most recent output:
===== Output ======
{latest}
==== End Output ===
Remember these are the custom commands you can use:
{DOCUMENTATION}
Lets try that again, it is very important that you adhere to the output format
This time, be sure to use the exact format below, replacing anything in <> with the appropriate value(s):
{RESPONSE_FORMAT}
It is crucial you use the format provided as the output will be parsed automatically.
"""
deffile_info(file:str,line:int):
iffile:
returnf"""CURRENT WORKSPACE:
Open File: {file} on line {line}
You can use these commands with the current file:
Navigation: `scroll_up`, `scroll_down`, and `goto <line>`
res+='Use these memories to provide additional context to the problem you are solving.\nRemember that you have already completed these steps so you do not need to perform them again.'
This folder implements the CodeAct idea ([paper](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) that consolidates LLM agents’**act**ions into a unified **code** action space for both *simplicity* and *performance* (see paper for more details).
The conceptual idea is illustrated below. At each turn, the agent can:
1.**Converse**: Communicate with humans in natural language to ask for clarification, confirmation, etc.
2.**CodeAct**: Choose to perform the task by executing code
- Execute any valid Linux `bash` command
- Execute any valid `Python` code with [an interactive Python interpreter](https://ipython.org/). This is simulated through `bash` command, see plugin system below for more details.
To make the CodeAct agent more powerful with only access to `bash` action space, CodeAct agent leverages OpenDevin's plugin system:
- [Jupyter plugin](https://github.com/OpenDevin/OpenDevin/tree/main/opendevin/runtime/plugins/jupyter): for IPython execution via bash command
- [SWE-agent tool plugin](https://github.com/OpenDevin/OpenDevin/tree/main/opendevin/runtime/plugins/swe_agent_commands): Powerful bash command line tools for software development tasks introduced by [swe-agent](https://github.com/princeton-nlp/swe-agent).
The agent works by passing the model a list of action-observation pairs and prompting the model to take the next step.
### Overview
This agent implements the CodeAct idea ([paper](https://arxiv.org/abs/2402.13463), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) that consolidates LLM agents’ **act**ions into a unified **code** action space for both *simplicity* and *performance* (see paper for more details).
The conceptual idea is illustrated below. At each turn, the agent can:
1. **Converse**: Communicate with humans in natural language to ask for clarification, confirmation, etc.
2. **CodeAct**: Choose to perform the task by executing code
- Execute any valid Linux `bash` command
- Execute any valid `Python` code with [an interactive Python interpreter](https://ipython.org/). This is simulated through `bash` command, see plugin system below for more details.
To make the CodeAct agent more powerful with only access to `bash` action space, CodeAct agent leverages OpenDevin's plugin system:
- [Jupyter plugin](https://github.com/OpenDevin/OpenDevin/tree/main/opendevin/runtime/plugins/jupyter): for IPython execution via bash command
- [SWE-agent tool plugin](https://github.com/OpenDevin/OpenDevin/tree/main/opendevin/runtime/plugins/swe_agent_commands): Powerful bash command line tools for software development tasks introduced by [swe-agent](https://github.com/princeton-nlp/swe-agent).
in_context_example:str=f"Here is an example of how you can interact with the environment for task solving:\n{get_in_context_example()}\n\nNOW, LET'S START!"
action_parser=CodeActResponseParser()
def__init__(
self,
llm:LLM,
)->None:
"""
Initializes a new instance of the CodeActAgent class.
Parameters:
- llm (LLM): The llm to be used by this agent
"""
super().__init__(llm)
self.reset()
defreset(self)->None:
"""
Resets the CodeAct Agent.
"""
super().reset()
defstep(self,state:State)->Action:
"""
Performs one step using the CodeAct Agent.
This includes gathering info on previous steps and prompting the model to make a command to execute.
Parameters:
- state (State): used to get updated info and background commands
Returns:
- CmdRunAction(command) - bash command to run
- IPythonRunCellAction(code) - IPython code to run
- AgentDelegateAction(agent, inputs) - delegate action for (sub)task
- MessageAction(content) - Message action to run (e.g. ask for clarification)
'\nApart from the standard Python library, the assistant can also use the following functions (already imported) in <execute_ipython> environment:\n'
f'{_AGENT_SKILLS_DOCS}'
"Please note that THE `edit_file` and `append_file` FUNCTIONS REQUIRE PROPER INDENTATION. If the assistant would like to add the line ' print(x)', it must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run."
)
# ======= SYSTEM MESSAGE =======
MINIMAL_SYSTEM_PREFIX="""A chat between a curious user and an artificial intelligence assistant. The assistant gives helpful, detailed, and polite answers to the user's questions.
The assistant can use an interactive Python (Jupyter Notebook) environment, executing code with <execute_ipython>.
<execute_ipython>
print("Hello World!")
</execute_ipython>
The assistant can execute bash commands on behalf of the user by wrapping them with <execute_bash> and </execute_bash>.
For example, you can list the files in the current directory by <execute_bash> ls </execute_bash>.
Important, however: do not run interactive commands. You do not have access to stdin.
Also, you need to handle commands that may run indefinitely and not return a result. For such cases, you should redirect the output to a file and run the command in the background to avoid blocking the execution.
For example, to run a Python script that might run indefinitely without returning immediately, you can use the following format: <execute_bash> python3 app.py > server.log 2>&1 & </execute_bash>
Also, if a command execution result saying like: Command: "npm start" timed out. Sending SIGINT to the process, you should also retry with running the command in the background.
"""
BROWSING_PREFIX="""The assistant can browse the Internet with <execute_browse> and </execute_browse>.
For example, <execute_browse> Tell me the usa's president using google search </execute_browse>.
Or <execute_browse> Tell me what is in http://example.com </execute_browse>.
"""
PIP_INSTALL_PREFIX="""The assistant can install Python packages using the %pip magic command in an IPython environment by using the following syntax: <execute_ipython> %pip install [package needed] </execute_ipython> and should always import packages and define variables before starting to use them."""
If $GITHUB_TOKEN is not set, ask the user to set it."""
SYSTEM_SUFFIX="""Responses should be concise.
The assistant should attempt fewer things at a time instead of putting too much commands OR code in one "execute" block.
Include ONLY ONE <execute_ipython>, <execute_bash>, or <execute_browse> per response, unless the assistant is finished with the task or need more input or action from the user in order to proceed.
IMPORTANT: Execute code using <execute_ipython>, <execute_bash>, or <execute_browse> whenever possible.
"""
# ======= EXAMPLE MESSAGE =======
EXAMPLES="""
--- START OF EXAMPLE ---
USER: Create a list of numbers from 1 to 10, and display them in a web page at port 5000.
ASSISTANT:
Sure! Let me create a Python file `app.py`:
<execute_ipython>
create_file('app.py')
</execute_ipython>
USER:
OBSERVATION:
[File: /workspace/app.py (1 lines total)]
1|
[File app.py created.]
ASSISTANT:
Now I will write the Python code for starting a web server and save it to the file `app.py`:
[File updated. Please review the changes and make sure they are correct (correct indentation, no duplicate lines, etc). Edit the file again if necessary.]
ASSISTANT:
I have created a Python file `app.py` that will display a list of numbers from 1 to 10 when you run it. Let me run the Python file for you:
Now that Flask is installed, let me run the Python file again:
<execute_bash>
python3 app.py > server.log 2>&1 &
</execute_bash>
USER:
OBSERVATION:
[1] 124
ASSISTANT:
Let me check the server log again:
<execute_bash>
cat server.log
</execute_bash>
USER:
OBSERVATION:
* Serving Flask app 'app'
* Debug mode: off
WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
* Running on http://127.0.0.1:5000
Press CTRL+C to quit
ASSISTANT:
The server is running on port 5000 with PID 124. You can access the list of numbers by visiting http://127.0.0.1:5000. If you have any further questions, feel free to ask!
USER: Now browse the newly started server's homepage and show me the content.
ASSISTANT:
Sure! Let me browse the server's homepage at http://127.0.0.1:5000:
<execute_browse>
Get the content on "http://127.0.0.1:5000"
</execute_browse>
USER:
OBSERVATION:
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
ASSISTANT:
The content of the server's homepage is "[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]". If you have any further questions, feel free to ask!
USER: Now kill the server, make it display the numbers in a table format.
ASSISTANT:
Sure! Let me stop the server first:
<execute_bash>
kill 124
</execute_bash>
USER:
OBSERVATION:
[1]+ Terminated python3 app.py > server.log 2>&1
ASSISTANT:
The server has been stopped. Let me open the Python file and modify it.
<execute_ipython>
open_file('app.py')
</execute_ipython>
USER:
[File: /workspace/app.py (10 lines total)]
1|from flask import Flask
2|app = Flask(__name__)
3|
4|@app.route('/')
5|def index():
6| numbers = list(range(1, 11))
7| return str(numbers)
8|
9|if __name__ == '__main__':
10| app.run(port=5000)
ASSISTANT:
I should edit the file to display the numbers in a table format. I should include correct indentation. Let me update the file:
<execute_ipython>
edit_file('app.py', start=7, end=7, content=" return '<table>' + ''.join([f'<tr><td>{i}</td></tr>' for i in numbers]) + '</table>'")
</execute_ipython>
USER:
Observation:
[File: /workspace/app.py (10 lines total after edit)]
1|from flask import Flask
2|app = Flask(__name__)
3|
4|@app.route('/')
5|def index():
6| numbers = list(range(1, 11))
7| return '<table>' + ''.join([f'<tr><td>{i}</td></tr>' for i in numbers]) + '</table>'
8|
9|if __name__ == '__main__':
10| app.run(port=5000)
[File updated. Please review the changes and make sure they are correct (correct indentation, no duplicate lines, etc). Edit the file again if necessary.]
ASSISTANT:
Running the updated file:
<execute_bash>
python3 app.py > server.log 2>&1 &
</execute_bash>
USER:
Observation:
[1] 126
ASSISTANT:
The server is running on port 5000 with PID 126. You can access the list of numbers in a table format by visiting http://127.0.0.1:5000. Let me know if you have any further requests!
--- END OF EXAMPLE ---
"""
INVALID_INPUT_MESSAGE=(
"I don't understand your input. \n"
'For bash commands, use <execute_bash> YOUR_COMMAND </execute_bash>.\n'
'For Python code, use <execute_ipython> YOUR_CODE </execute_ipython>.\n'
'For browsing, use <execute_browse> YOUR_COMMAND </execute_browse>.\n'
in_context_example:str=f"Here is an example of how you can interact with the environment for task solving:\n{get_in_context_example()}\n\nNOW, LET'S START!"
def__init__(
self,
llm:LLM,
)->None:
"""
Initializes a new instance of the CodeActAgent class.
Parameters:
- llm (LLM): The llm to be used by this agent
"""
super().__init__(llm)
self.reset()
defreset(self)->None:
"""
Resets the CodeAct Agent.
"""
super().reset()
defstep(self,state:State)->Action:
"""
Performs one step using the CodeAct Agent.
This includes gathering info on previous steps and prompting the model to make a command to execute.
Parameters:
- state (State): used to get updated info and background commands
Returns:
- CmdRunAction(command) - bash command to run
- IPythonRunCellAction(code) - IPython code to run
- BrowseInteractiveAction(browsergym_command) - BrowserGym commands to run
- MessageAction(content) - Message action to run (e.g. ask for clarification)
*`run` - runs a command on the command line in a Linux shell. Arguments:
*`command` - the command to run
*`background` - if true, run the command in the background, so that other commands can be run concurrently. Useful for e.g. starting a server. You won't be able to see the logs. You don't need to end the command with `&`, just set this to true.
Modifies the current state by adding the most recent actions and observations, then prompts the model to think about it's next action to take using monologue, memory, and hint.
Parameters:
- state (State): The current state based on previous steps taken
Returns:
- Action: The next action to take based on LLM response
You're a thoughtful robot. Your main task is this:
%(task)s
Don't expand the scope of your task--just complete it as written.
This is your internal monologue, in JSON format:
%(monologue)s
Your most recent thought is at the bottom of that monologue. Continue your train of thought.
What is your next single thought or action? Your response must be in JSON format.
It must be a single object, and it must contain two fields:
* `action`, which is one of the actions below
* `args`, which is a map of key-value pairs, specifying the arguments for that action
Here are the possible actions:
* `read` - reads the content of a file. Arguments:
* `path` - the path of the file to read
* `write` - writes the content to a file. Arguments:
* `path` - the path of the file to write
* `content` - the content to write to the file
* `run` - runs a command. Arguments:
* `command` - the command to run
* `background` - if true, run the command in the background, so that other commands can be run concurrently. Useful for e.g. starting a server. You won't be able to see the logs. You don't need to end the command with `&`, just set this to true.
* `kill` - kills a background command
* `command_id` - the ID of the background command to kill
* `browse` - opens a web page. Arguments:
* `url` - the URL to open
* `push` - Push a branch from the current repo to github:
* `owner` - the owner of the repo to push to
* `repo` - the name of the repo to push to
* `branch` - the name of the branch to push
* `recall` - recalls a past memory. Arguments:
* `query` - the query to search for
* `message` - make a plan, set a goal, record your thoughts, or ask for more input from the user. Arguments:
* `content` - the message to record
* `wait_for_response` - set to `true` to wait for the user to respond before proceeding
* `finish` - if you're absolutely certain that you've completed your task and have tested your work, use the finish action to stop working.
%(background_commands)s
You MUST take time to think in between read, write, run, kill, browse, push, and recall actions--do this with the `message` action.
You should never act twice in a row without thinking. But if your last several
actions are all `message` actions, you should consider taking a different action.
Notes:
* you are logged in as %(user)s, but sudo will always work without a password.
* all non-background commands will be forcibly stopped if they remain running for over %(timeout)s seconds.
* your environment is Debian Linux. You can install software with `sudo apt-get`, but remember to use -y.
* don't run interactive commands, or commands that don't return (e.g. `node server.js`). You may run commands in the background (e.g. `node server.js &`)
* don't run interactive text editors (e.g. `nano` or 'vim'), instead use the 'write' or 'read' action.
* don't run gui applications (e.g. software IDEs (like vs code or codium), web browsers (like firefox or chromium), or other complex software packages). Use non-interactive cli applications, or special actions instead.
* whenever an action fails, always send a `message` about why it may have happened before acting again.
What is your next single thought or action? Again, you must reply with JSON, and only with JSON. You must respond with exactly one 'action' object.
%(hint)s
"""
MONOLOGUE_SUMMARY_PROMPT="""
Below is the internal monologue of an automated LLM agent. Each
thought is an item in a JSON array. The thoughts may be memories,
actions taken by the agent, or outputs from those actions.
Please return a new, smaller JSON array, which summarizes the
internal monologue. You can summarize individual thoughts, and
you can condense related thoughts together with a description
of their content.
%(monologue)s
Make the summaries as pithy and informative as possible.
Be specific about what happened and what was learned. The summary
will be used as keywords for searching for the original memory.
Be sure to preserve any key words or important information.
Your response must be in JSON format. It must be an object with the
key `new_monologue`, which is a JSON array containing the summarized monologue.
Each entry in the array must have an `action` key, and an `args` key.
The action key may be `summarize`, and `args.summary` should contain the summary.
You can also use the same action and args from the source monologue.
"""
INITIAL_THOUGHTS=[
'I exist!',
'Hmm...looks like I can type in a command line prompt',
'Looks like I have a web browser too!',
"Here's what I want to do: $TASK",
'How am I going to get there though?',
'It seems like I have some kind of short term memory.',
'Each of my thoughts seems to be stored in a JSON array.',
'It seems whatever I say next will be added as an object to the list.',
'But no one has perfect short-term memory. My list of thoughts will be summarized and condensed over time, losing information in the process.',
'Fortunately I have long term memory!',
'I can just perform a recall action, followed by the thing I want to remember. And then related thoughts just spill out!',
"Sometimes they're random thoughts that don't really have to do with what I wanted to remember. But usually they're exactly what I need!",
"Let's try it out!",
'RECALL what it is I want to do',
"Here's what I want to do: $TASK",
'How am I going to get there though?',
"Neat! And it looks like it's easy for me to use the command line too! I just have to perform a run action and include the command I want to run in the command argument. The command output just jumps into my head!",
'RUN echo "hello world"',
'hello world',
'Cool! I bet I can write files too using the write action.',
Install [Docker](https://docs.docker.com/engine/install/) on your host machine and run:
```bash
make docker-dev
# same as:
cd ./containers/dev
./dev.sh
```
It could take some time if you are running for the first time as Docker will pull all the tools required for building OpenHands. The next time you run again, it should be instant.
## Build and run
If everything goes well, you should be inside a container after Docker finishes building the `openhands:dev` image similar to the following:
```bash
Build and run in Docker ...
root@93fc0005fcd2:/app#
```
You may now proceed with the normal [build and run](../../Development.md) workflow as if you were on the host.
## Make changes
The source code on the host is mounted as `/app` inside docker. You may edit the files as usual either inside the Docker container or on your host with your favorite IDE/editors.
The following are also mapped as readonly from your host:
[E2B](https://e2b.dev) is an [open-source](https://github.com/e2b-dev/e2b) secure cloud environment (sandbox) made for running AI-generated code and agents. E2B offers [Python](https://pypi.org/project/e2b/) and [JS/TS](https://www.npmjs.com/package/e2b) SDK to spawn and control these sandboxes.
This folder builds a runtime image (sandbox), which will use a dynamically generated `Dockerfile`
that depends on the `base_image`**AND** a [Python source distribution](https://docs.python.org/3.10/distutils/sourcedist.html) that is based on the current commit of `openhands`.
The following command will generate a `Dockerfile` file for `nikolaik/python-nodejs:python3.12-nodejs22` (the default base image), an updated `config.sh` and the runtime source distribution files/folders into `containers/runtime`:
```bash
poetry run python3 openhands/runtime/utils/runtime_build.py \
"message":"est un ingénieur logiciel autonome qui peut résoudre des tâches d'ingénierie logicielle et de navigation web à tout moment. Il peut exécuter des requêtes en sciences des données, telles que \"Trouver le nombre de demandes de pull à l'repository OpenHands dans les derniers mois\", et des tâches d'ingénierie logicielle, comme \"Veuillez ajouter des tests à ce fichier et vérifier si tous les tests passent. Si ce n'est pas le cas, réparez le fichier.\"",
"description":"Description for OpenHands"
},
"faq.section.description.2":{
"message":"De plus, OpenHands est une plateforme et communauté pour les développeurs d'agents qui souhaitent tester et évaluer de nouveaux agents.",
"description":"Further Description for OpenHands"
},
"faq.section.title.2":{
"message":"Support",
"description":"Support Section Title"
},
"faq.section.support.answer":{
"message":"Si vous rencontrez un problème que d'autres utilisateurs peuvent également avoir, merci de le signaler sur {githubLink}. Si vous avez des difficultés à l'installation ou des questions générales, rejoignez-vous sur {discordLink} ou {slackLink}.",
"description":"Support Answer"
},
"faq.section.title.3":{
"message":"Comment résoudre un problème sur GitHub avec OpenHands ?",
"description":"GitHub Issue Section Title"
},
"faq.section.github.steps.intro":{
"message":"Pour résoudre un problème sur GitHub en utilisant OpenHands, envoyez une commande à OpenHands demandant qu'il suit des étapes comme les suivantes :",
"message":"Cloner le dépôt et vérifier une nouvelle branche",
"description":"GitHub Step 2"
},
"faq.section.github.step3":{
"message":"Sur la base des instructions dans la description de l'issue, modifiez les fichiers pour résoudre le problème",
"description":"GitHub Step 3"
},
"faq.section.github.step4":{
"message":"Pousser le résultat à GitHub en utilisant la variable d'environnement GITHUB_TOKEN",
"description":"GitHub Step 4"
},
"faq.section.github.step5":{
"message":"Dites-moi le lien que je dois utiliser pour envoyer une demande de pull",
"description":"GitHub Step 5"
},
"faq.section.github.steps.preRun":{
"message":"Avant de lancer OpenHands, vous pouvez faire :",
"description":"GitHub Steps Pre-Run"
},
"faq.section.github.steps.tokenInfo":{
"message":"où XXX est un jeton GitHub que vous avez créé et qui a les autorisations pour pousser dans le dépôt OpenHands. Si vous n'avez pas d'autorisations de modification du dépôt OpenHands, vous devrez peut-être changer cela en :",
"description":"GitHub Steps Token Info"
},
"faq.section.github.steps.usernameInfo":{
"message":"où USERNAME est votre nom GitHub.",
"description":"GitHub Steps Username Info"
},
"faq.section.title.4":{
"message":"Comment OpenHands est-il différent de Devin ?",
"description":"Devin Section Title"
},
"faq.section.openhands.linkText":{
"message":"Devin",
"description":"Devin Link Text"
},
"faq.section.openhands.description":{
"message":"est un produit commercial par Cognition Inc., qui a servi d'inspiration initiale pour OpenHands. Les deux visent à bien faire le travail d'ingénierie logicielle, mais vous pouvez télécharger, utiliser et modifier OpenHands, tandis que Devin peut être utilisé uniquement via le site de Cognition. De plus, OpenHands a évolué au-delà de l'inspiration initiale, et est maintenant un écosystème communautaire pour le développement d'agents en général, et nous serions ravis de vous voir rejoindre et",
"description":"Devin Description"
},
"faq.section.openhands.contribute":{
"message":"contribuer",
"description":"Contribute Link"
},
"faq.section.title.5":{
"message":"Comment OpenHands est-il différent de ChatGPT ?",
"description":"ChatGPT Section Title"
},
"faq.section.chatgpt.description":{
"message":"ChatGPT vous pouvez accéder en ligne, il ne se connecte pas aux fichiers locaux et ses capacités d'exécution du code sont limitées. Alors qu'il peut écrire du code, mais c'est difficile à tester ou à exécuter.",
"description":"ChatGPT Description"
},
"homepage.description":{
"message":"Génération d'code AI pour l'ingénierie logicielle.",
"description":"The homepage description"
},
"homepage.getStarted":{
"message":"Commencer"
},
"welcome.message":{
"message":"Bienvenue à OpenHands, un système d'IA autonome ingénieur logiciel capable d'exécuter des tâches d'ingénierie complexes et de collaborer activement avec les utilisateurs sur les projets de développement logiciel."
},
"theme.ErrorPageContent.title":{
"message":"Cette page a planté.",
"description":"The title of the fallback page when the page crashed"
},
"theme.BackToTopButton.buttonAriaLabel":{
"message":"Retourner en haut de la page",
"description":"The ARIA label for the back to top button"
},
"theme.blog.archive.title":{
"message":"Archives",
"description":"The page & hero title of the blog archive page"
},
"theme.blog.archive.description":{
"message":"Archives",
"description":"The page & hero description of the blog archive page"
},
"theme.blog.paginator.navAriaLabel":{
"message":"Pagination des listes d'articles du blog",
"description":"The ARIA label for the blog pagination"
},
"theme.blog.paginator.newerEntries":{
"message":"Nouvelles entrées",
"description":"The label used to navigate to the newer blog posts page (previous page)"
},
"theme.blog.paginator.olderEntries":{
"message":"Anciennes entrées",
"description":"The label used to navigate to the older blog posts page (next page)"
},
"theme.blog.post.paginator.navAriaLabel":{
"message":"Pagination des articles du blog",
"description":"The ARIA label for the blog posts pagination"
},
"theme.blog.post.paginator.newerPost":{
"message":"Article plus récent",
"description":"The blog post button label to navigate to the newer/previous post"
},
"theme.blog.post.paginator.olderPost":{
"message":"Article plus ancien",
"description":"The blog post button label to navigate to the older/next post"
},
"theme.blog.post.plurals":{
"message":"Un article|{count} articles",
"description":"Pluralized label for \"{count} posts\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.blog.tagTitle":{
"message":"{nPosts} tags avec « {tagName} »",
"description":"The title of the page for a blog tag"
},
"theme.tags.tagsPageLink":{
"message":"Voir tous les tags",
"description":"The label of the link targeting the tag list page"
},
"theme.colorToggle.ariaLabel":{
"message":"Basculer entre le mode sombre et clair (actuellement {mode})",
"description":"The ARIA label for the navbar color mode toggle"
},
"theme.colorToggle.ariaLabel.mode.dark":{
"message":"mode sombre",
"description":"The name for the dark color mode"
},
"theme.colorToggle.ariaLabel.mode.light":{
"message":"mode clair",
"description":"The name for the light color mode"
},
"theme.docs.breadcrumbs.navAriaLabel":{
"message":"Bouton de navigation des liens de la page",
"description":"The ARIA label for the breadcrumbs"
"description":"Pluralized label for \"{count} docs tagged\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.tagDocListPageTitle":{
"message":"{nDocsTagged} avec \"{tagName}\"",
"description":"The title of the page for a docs tag"
},
"theme.docs.versionBadge.label":{
"message":"Version: {versionLabel}"
},
"theme.docs.versions.unreleasedVersionLabel":{
"message":"Ceci est la documentation de la prochaine version {versionLabel} de {siteTitle}.",
"description":"The label used to tell the user that he's browsing an unreleased doc version"
},
"theme.docs.versions.unmaintainedVersionLabel":{
"message":"Ceci est la documentation de {siteTitle} {versionLabel}, qui n'est plus activement maintenue.",
"description":"The label used to tell the user that he's browsing an unmaintained doc version"
"message":"Réduire la catégorie '{label}' de la barre latérale",
"description":"The ARIA label to collapse the sidebar category"
},
"theme.NavBar.navAriaLabel":{
"message":"Main",
"description":"The ARIA label for the main navigation"
},
"theme.navbar.mobileLanguageDropdown.label":{
"message":"Langues",
"description":"The label for the mobile language switcher dropdown"
},
"theme.NotFound.p1":{
"message":"Nous n'avons pas trouvé ce que vous recherchez.",
"description":"The first paragraph of the 404 page"
},
"theme.NotFound.p2":{
"message":"Veuillez contacter le propriétaire du site qui vous a lié à l'URL d'origine et leur faire savoir que leur lien est cassé.",
"description":"The 2nd paragraph of the 404 page"
},
"theme.TOCCollapsible.toggleButtonLabel":{
"message":"Sur cette page",
"description":"The label used by the button on the collapsible TOC component"
},
"theme.blog.post.readMore":{
"message":"Lire plus",
"description":"The label used in blog post item excerpts to link to full blog posts"
},
"theme.blog.post.readMoreLabel":{
"message":"En savoir plus sur {title}",
"description":"The ARIA label for the link to full blog posts from excerpts"
},
"theme.blog.post.readingTime.plurals":{
"message":"Une minute de lecture|{readingTime} minutes de lecture",
"description":"Pluralized label for \"{readingTime} min read\". Use as much plural forms (separated by \"|\") as your language support (see https://www.unicode.org/cldr/cldr-aux/charts/34/supplemental/language_plural_rules.html)"
},
"theme.docs.breadcrumbs.home":{
"message":"Page d'accueil",
"description":"The ARIA label for the home page in the breadcrumbs"
},
"theme.docs.sidebar.collapseButtonTitle":{
"message":"Réduire le menu latéral",
"description":"The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.collapseButtonAriaLabel":{
"message":"Réduire le menu latérale",
"description":"The title attribute for collapse button of doc sidebar"
},
"theme.docs.sidebar.navAriaLabel":{
"message":"Barre de navigation latérale des docs",
"description":"The ARIA label for the sidebar navigation"
"description":"The label of the back button to return to main menu, inside the mobile navbar sidebar secondary menu (notably used to display the docs sidebar)"
"description":"The ARIA label for hamburger menu button of mobile navigation"
},
"theme.docs.sidebar.expandButtonTitle":{
"message":"Déplier le menu latéral",
"description":"The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.docs.sidebar.expandButtonAriaLabel":{
"message":"Déployer le menu latérale",
"description":"The ARIA label and title attribute for expand button of doc sidebar"
},
"theme.ErrorPageContent.tryAgain":{
"message":"Réessayer",
"description":"The label of the button to try again rendering when the React error boundary captures an error"
},
"theme.common.skipToMainContent":{
"message":"Aller directement au contenu principal",
"description":"The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
},
"theme.tags.tagsPageTitle":{
"message":"Tags",
"description":"The title of the tag list page"
},
"theme.unlistedContent.title":{
"message":"Page non répertoriée",
"description":"The unlisted content banner title"
},
"theme.unlistedContent.message":{
"message":"Cette page n'est pas répertoriée. Les moteurs de recherche ne l'indexeront pas, et seuls les utilisateurs ayant un lien direct peuvent y accéder.",
La réplication complète d'applications de niveau production avec des LLM est une entreprise complexe. Notre stratégie implique :
1.**Recherche technique fondamentale :** Se concentrer sur la recherche fondamentale pour comprendre et améliorer les aspects techniques de la génération et de la gestion de code
2.**Capacités spécialisées :** Améliorer l'efficacité des composants de base grâce à la curation de données, aux méthodes d'entraînement, etc.
3.**Planification des tâches :** Développer des capacités de détection de bugs, de gestion de base de code et d'optimisation
4.**Évaluation :** Établir des métriques d'évaluation complètes pour mieux comprendre et améliorer nos modèles
## 🚧 Agent par défaut
Notre Agent par défaut est actuellement le [CodeActAgent](agents), qui est capable de générer du code et de gérer des fichiers.
## 🤝 Comment contribuer
OpenHands est un projet communautaire et nous accueillons les contributions de tous. Que vous soyez développeur, chercheur ou simplement enthousiaste à l'idée de faire progresser le domaine de l'ingénierie logicielle avec l'IA, il existe de nombreuses façons de s'impliquer :
- **Contributions de code :** Aidez-nous à développer les fonctionnalités de base, l'interface frontend ou les solutions de sandboxing
- **Recherche et évaluation :** Contribuez à notre compréhension des LLM dans l'ingénierie logicielle, participez à l'évaluation des modèles ou suggérez des améliorations
- **Retours et tests :** Utilisez la boîte à outils OpenHands, signalez des bugs, suggérez des fonctionnalités ou donnez votre avis sur la facilité d'utilisation
Pour plus de détails, veuillez consulter [ce document](https://github.com/All-Hands-AI/OpenHands/blob/main/CONTRIBUTING.md).
## 🤖 Rejoignez notre communauté
Nous avons à la fois un espace de travail Slack pour la collaboration sur la construction d'OpenHands et un serveur Discord pour discuter de tout ce qui est lié, par exemple, à ce projet, LLM, agent, etc.
- [Espace de travail Slack](https://join.slack.com/t/opendevin/shared_invite/zt-2oikve2hu-UDxHeo8nsE69y6T7yFX_BA)
Si vous souhaitez contribuer, n'hésitez pas à rejoindre notre communauté. Simplifions ensemble l'ingénierie logicielle !
🐚 **Codez moins, faites plus avec OpenHands.**
[](https://star-history.com/#All-Hands-AI/OpenHands&Date)
## 🛠️ Construit avec
OpenHands est construit en utilisant une combinaison de frameworks et de bibliothèques puissants, fournissant une base solide pour son développement. Voici les principales technologies utilisées dans le projet :
Veuillez noter que la sélection de ces technologies est en cours et que des technologies supplémentaires peuvent être ajoutées ou des technologies existantes peuvent être supprimées à mesure que le projet évolue. Nous nous efforçons d'adopter les outils les plus appropriés et les plus efficaces pour améliorer les capacités d'OpenHands.
## 📜 Licence
Distribué sous la licence MIT. Voir [notre licence](https://github.com/All-Hands-AI/OpenHands/blob/main/LICENSE) pour plus d'informations.
Cet agent implémente l'idée de CodeAct ([article](https://arxiv.org/abs/2402.01030), [tweet](https://twitter.com/xingyaow_/status/1754556835703751087)) qui consolide les **act**ions des agents LLM dans un espace d'action de **code** unifié à la fois pour la _simplicité_ et la _performance_.
L'idée conceptuelle est illustrée ci-dessous. À chaque tour, l'agent peut :
1.**Converser** : Communiquer avec les humains en langage naturel pour demander des clarifications, des confirmations, etc.
2.**CodeAct** : Choisir d'effectuer la tâche en exécutant du code
- Exécuter n'importe quelle commande Linux `bash` valide
- Exécuter n'importe quel code `Python` valide avec [un interpréteur Python interactif](https://ipython.org/). Ceci est simulé via une commande `bash`, voir le système de plugin ci-dessous pour plus de détails.
Voici un aperçu de haut niveau de l'architecture du système. Le système est divisé en deux composants principaux : le frontend et le backend. Le frontend est responsable de la gestion des interactions avec l'utilisateur et de l'affichage des résultats. Le backend est responsable de la gestion de la logique métier et de l'exécution des agents.
Cet aperçu est simplifié pour montrer les principaux composants et leurs interactions. Pour une vue plus détaillée de l'architecture du backend, consultez la section [Architecture du Backend](#backend-architecture-fr).
# Architecture du Backend {#backend-architecture-fr}
_**Avertissement**: L'architecture du backend est en cours de développement et est sujette à modifications. Le schéma suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du schéma._
2. Ouvrez le fichier généré dans un éditeur PlantUML, par exemple Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
3. Révisez le PUML généré et apportez toutes les modifications nécessaires au schéma (ajoutez les parties manquantes, corrigez les erreurs, améliorez l'agencement).
_py2puml crée le schéma à partir des annotations de type dans le code, donc les annotations de type manquantes ou incorrectes peuvent entraîner un schéma incomplet ou incorrect._
4. Examinez la différence entre le nouveau schéma et le précédent et vérifiez manuellement si les modifications sont correctes.
_Assurez-vous de ne pas supprimer les parties ajoutées manuellement au schéma par le passé et qui sont toujours pertinentes._
5. Ajoutez le hash du commit qui a été utilisé pour générer le schéma dans le pied de page du schéma.
6. Exporte le schéma sous forme de fichiers PNG et SVG et remplacez les schémas existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par exemple [PlantText](https://www.planttext.com/))
<img src="https://github.com/All-Hands-AI/OpenHands/assets/16201837/97d747e3-29d8-4ccb-8d34-6ad1adb17f38" alt="OpenHands System Architecture Diagram Jul 4 2024" />
<p><em>Diagramme de l'Architecture du Système OpenHands (4 juillet 2024)</em></p>
</div>
Ceci est une vue d'ensemble de haut niveau de l'architecture du système. Le système est divisé en deux composants principaux : le frontend et le backend. Le frontend est responsable de la gestion des interactions utilisateur et de l'affichage des résultats. Le backend est responsable de la gestion de la logique métier et de l'exécution des agents.
# Architecture du Frontend {#frontend-architecture-fr}
Cette vue d'ensemble est simplifiée pour montrer les principaux composants et leurs interactions. Pour une vue plus détaillée de l'architecture du backend, voir la section Architecture du Backend ci-dessous.
# Architecture du Backend {#backend-architecture-fr}
_**Avertissement** : L'architecture du backend est en cours de développement et est sujette à changement. Le diagramme suivant montre l'architecture actuelle du backend basée sur le commit indiqué dans le pied de page du diagramme._
La génération du diagramme d'architecture du backend est partiellement automatisée.
Le diagramme est généré à partir des indications de type dans le code en utilisant l'outil py2puml. Le diagramme est ensuite manuellement revu, ajusté et exporté en PNG et SVG.
## Prérequis
- Environnement python fonctionnel dans lequel openhands est exécutable
(selon les instructions du fichier README.md à la racine du dépôt)
2. Ouvrir le fichier généré dans un éditeur PlantUML, par ex. Visual Studio Code avec l'extension PlantUML ou [PlantText](https://www.planttext.com/)
3. Revoir le PUML généré et effectuer tous les ajustements nécessaires au diagramme (ajouter les parties manquantes, corriger les erreurs, améliorer le positionnement).
_py2puml crée le diagramme en se basant sur les indications de type dans le code, donc des indications manquantes ou incorrectes peuvent entraîner un diagramme incomplet ou incorrect._
4. Revoir la différence entre le nouveau diagramme et le précédent et vérifier manuellement si les changements sont corrects.
_S'assurer de ne pas supprimer des parties qui ont été ajoutées manuellement au diagramme par le passé et qui sont toujours pertinentes._
5. Ajouter le hash du commit qui a été utilisé pour générer le diagramme dans le pied de page du diagramme.
6. Exporter le diagramme sous forme de fichiers PNG et SVG et remplacer les diagrammes existants dans le répertoire `docs/architecture`. Cela peut être fait avec (par ex. [PlantText](https://www.planttext.com/))
Le Runtime EventStream d'OpenHands est le composant principal qui permet l'exécution sécurisée et flexible des actions des agents d'IA.
Il crée un environnement en bac à sable (sandbox) en utilisant Docker, où du code arbitraire peut être exécuté en toute sécurité sans risquer le système hôte.
## Pourquoi avons-nous besoin d'un runtime en bac à sable ?
OpenHands doit exécuter du code arbitraire dans un environnement sécurisé et isolé pour plusieurs raisons :
1. Sécurité : L'exécution de code non fiable peut poser des risques importants pour le système hôte. Un environnement en bac à sable empêche le code malveillant d'accéder ou de modifier les ressources du système hôte
2. Cohérence : Un environnement en bac à sable garantit que l'exécution du code est cohérente sur différentes machines et configurations, éliminant les problèmes du type "ça fonctionne sur ma machine"
3. Contrôle des ressources : Le bac à sable permet un meilleur contrôle de l'allocation et de l'utilisation des ressources, empêchant les processus incontrôlés d'affecter le système hôte
4. Isolation : Différents projets ou utilisateurs peuvent travailler dans des environnements isolés sans interférer les uns avec les autres ou avec le système hôte
5. Reproductibilité : Les environnements en bac à sable facilitent la reproduction des bugs et des problèmes, car l'environnement d'exécution est cohérent et contrôlable
## Comment fonctionne le Runtime ?
Le système Runtime d'OpenHands utilise une architecture client-serveur implémentée avec des conteneurs Docker. Voici un aperçu de son fonctionnement :
```mermaid
graph TD
A[Image Docker personnalisée fournie par l'utilisateur] --> B[Backend OpenHands]
B -->|Construit| C[Image OH Runtime]
C -->|Lance| D[Exécuteur d'actions]
D -->|Initialise| E[Navigateur]
D -->|Initialise| F[Shell Bash]
D -->|Initialise| G[Plugins]
G -->|Initialise| L[Serveur Jupyter]
B -->|Génère| H[Agent]
B -->|Génère| I[EventStream]
I <--->|Exécute l'action pour
obtenir l'observation
via l'API REST
| D
H -->|Génère l'action| I
I -->|Obtient l'observation| H
subgraph "Conteneur Docker"
D
E
F
G
L
end
```
1. Entrée utilisateur : L'utilisateur fournit une image Docker de base personnalisée
2. Construction de l'image : OpenHands construit une nouvelle image Docker (l'"image OH runtime") basée sur l'image fournie par l'utilisateur. Cette nouvelle image inclut le code spécifique à OpenHands, principalement le "client runtime"
3. Lancement du conteneur : Lorsqu'OpenHands démarre, il lance un conteneur Docker en utilisant l'image OH runtime
4. Initialisation du serveur d'exécution des actions : Le serveur d'exécution des actions initialise un `ActionExecutor` à l'intérieur du conteneur, mettant en place les composants nécessaires comme un shell bash et chargeant les plugins spécifiés
5. Communication : Le backend OpenHands (`openhands/runtime/impl/eventstream/eventstream_runtime.py`) communique avec le serveur d'exécution des actions via une API RESTful, envoyant des actions et recevant des observations
6. Exécution des actions : Le client runtime reçoit les actions du backend, les exécute dans l'environnement en bac à sable et renvoie les observations
7. Retour des observations : Le serveur d'exécution des actions renvoie les résultats d'exécution au backend OpenHands sous forme d'observations
Le rôle du client :
- Il agit comme un intermédiaire entre le backend OpenHands et l'environnement en bac à sable
- Il exécute différents types d'actions (commandes shell, opérations sur les fichiers, code Python, etc.) en toute sécurité dans le conteneur
- Il gère l'état de l'environnement en bac à sable, y compris le répertoire de travail courant et les plugins chargés
- Il formate et renvoie les observations au backend, assurant une interface cohérente pour le traitement des résultats
## Comment OpenHands construit et maintient les images OH Runtime
L'approche d'OpenHands pour la construction et la gestion des images runtime assure l'efficacité, la cohérence et la flexibilité dans la création et la maintenance des images Docker pour les environnements de production et de développement.
Consultez le [code pertinent](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/utils/runtime_build.py) si vous souhaitez plus de détails.
### Système de balises d'images
OpenHands utilise un système à trois balises pour ses images runtime afin d'équilibrer la reproductibilité et la flexibilité.
Les balises peuvent être dans l'un des 2 formats suivants :
- **Balise versionnée** : `oh_v{openhands_version}_{base_image}` (ex : `oh_v0.9.9_nikolaik_s_python-nodejs_t_python3.12-nodejs22`)
- **Balise de verrouillage** : `oh_v{openhands_version}_{16_digit_lock_hash}` (ex : `oh_v0.9.9_1234567890abcdef`)
(ex : `oh_v0.9.9_1234567890abcdef_1234567890abcdef`)
#### Balise source - La plus spécifique
Il s'agit des 16 premiers chiffres du MD5 du hash du répertoire pour le répertoire source. Cela donne un hash
uniquement pour la source d'openhands
#### Balise de verrouillage
Ce hash est construit à partir des 16 premiers chiffres du MD5 de :
- Le nom de l'image de base sur laquelle l'image a été construite (ex : `nikolaik/python-nodejs:python3.12-nodejs22`)
- Le contenu du `pyproject.toml` inclus dans l'image.
- Le contenu du `poetry.lock` inclus dans l'image.
Cela donne effectivement un hash pour les dépendances d'Openhands indépendamment du code source.
#### Balise versionnée - La plus générique
Cette balise est une concaténation de la version d'openhands et du nom de l'image de base (transformé pour s'adapter au standard des balises).
#### Processus de construction
Lors de la génération d'une image...
- **Pas de reconstruction** : OpenHands vérifie d'abord si une image avec la même **balise source la plus spécifique** existe. S'il existe une telle image,
aucune construction n'est effectuée - l'image existante est utilisée.
- **Reconstruction la plus rapide** : OpenHands vérifie ensuite si une image avec la **balise de verrouillage générique** existe. S'il existe une telle image,
OpenHands construit une nouvelle image basée sur celle-ci, en contournant toutes les étapes d'installation (comme `poetry install` et
`apt-get`) sauf une opération finale pour copier le code source actuel. La nouvelle image est balisée avec une
balise **source** uniquement.
- **Reconstruction correcte** : Si ni une balise **source** ni une balise **de verrouillage** n'existe, une image sera construite sur la base de l'image avec la balise **versionnée**.
Dans l'image avec la balise versionnée, la plupart des dépendances devraient déjà être installées, ce qui permet de gagner du temps.
- **Reconstruction la plus lente** : Si les trois balises n'existent pas, une toute nouvelle image est construite à partir de
l'image de base (ce qui est une opération plus lente). Cette nouvelle image est balisée avec toutes les balises **source**, **de verrouillage** et **versionnée**.
Cette approche de balisage permet à OpenHands de gérer efficacement les environnements de développement et de production.
1. Un code source et un Dockerfile identiques produisent toujours la même image (via des balises basées sur des hashs)
2. Le système peut reconstruire rapidement les images lorsque des changements mineurs se produisent (en s'appuyant sur des images compatibles récentes)
3. La balise **de verrouillage** (ex : `runtime:oh_v0.9.3_1234567890abcdef`) pointe toujours vers la dernière version pour une combinaison particulière d'image de base, de dépendances et de version d'OpenHands
## Système de plugins du Runtime
Le Runtime d'OpenHands prend en charge un système de plugins qui permet d'étendre les fonctionnalités et de personnaliser l'environnement d'exécution. Les plugins sont initialisés lorsque le client runtime démarre.
Consultez [un exemple de plugin Jupyter ici](https://github.com/All-Hands-AI/OpenHands/blob/ecf4aed28b0cf7c18d4d8ff554883ba182fc6bdd/openhands/runtime/plugins/jupyter/__init__.py#L21-L55) si vous souhaitez implémenter votre propre plugin.
*Plus de détails sur le système de plugins sont encore en construction - les contributions sont les bienvenues !*
Aspects clés du système de plugins :
1. Définition des plugins : Les plugins sont définis comme des classes Python qui héritent d'une classe de base `Plugin`
2. Enregistrement des plugins : Les plugins disponibles sont enregistrés dans un dictionnaire `ALL_PLUGINS`
3. Spécification des plugins : Les plugins sont associés à `Agent.sandbox_plugins: list[PluginRequirement]`. Les utilisateurs peuvent spécifier quels plugins charger lors de l'initialisation du runtime
4. Initialisation : Les plugins sont initialisés de manière asynchrone lorsque le client runtime démarre
5. Utilisation : Le client runtime peut utiliser les plugins initialisés pour étendre ses capacités (par exemple, le JupyterPlugin pour exécuter des cellules IPython)
Le sandbox par défaut OpenHands est équipé d'une configuration ubuntu minimaliste. Votre cas d'utilisation pourrait nécessiter des logiciels installés par défaut. Cet article vous enseignera comment réaliser cela en utilisant une image docker personnalisée.
## Configuration
Assurez-vous de pouvoir utiliser OpenHands en suivant la documentation [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
## Créer Votre Image Docker
Ensuite, vous devez créer votre image docker personnalisée qui doit être basée sur debian/ubuntu. Par exemple, si nous souhaitons que OpenHands ait accès au "node" binaire, nous utiliserions ce Dockerfile:
```bash
# Commencez avec l'image ubuntu la plus récente
FROM ubuntu:latest
# Effectuez les mises à jour nécessaires
RUN apt-get update && apt-get install
# Installez nodejs
RUN apt-get install -y nodejs
```
Ensuite, construisez votre image docker avec le nom de votre choix. Par exemple "image_personnalisée". Pour cela, créez un répertoire et placez le fichier à l'intérieur avec le nom "Dockerfile", puis dans le répertoire exécutez cette commande:
```bash
docker build -t image_personnalisée .
```
Cela produira une nouvelle image appelée ```image_personnalisée``` qui sera disponible dans Docker Engine.
> Remarque: Dans la configuration décrite ici, OpenHands va fonctionner en tant que utilisateur "openhands" à l'intérieur du sandbox et donc tous les packages installés via le Dockerfile seront disponibles pour tous les utilisateurs sur le système, pas seulement root.
>
> L'installation avec apt-get ci-dessus installe nodejs pour tous les utilisateurs.
## Spécifiez votre image personnalisée dans le fichier config.toml
La configuration OpenHands se fait via le fichier de niveau supérieur ```config.toml``` .
Créez un fichier ```config.toml``` dans le répertoire OpenHands et entrez ces contenus:
> Assurez-vous que ```sandbox_base_container_image``` est défini sur le nom de votre image personnalisée précédente.
## Exécution
Exécutez OpenHands en exécutant ```make run``` dans le répertoire racine.
Naviguez vers ```localhost:3001``` et vérifiez si vos dépendances souhaitées sont disponibles.
Dans le cas de l'exemple ci-dessus, la commande ```node -v``` dans la console produit ```v18.19.1```
Félicitations !
## Explication technique
Lorsqu'une image personnalisée est utilisée pour la première fois, elle ne sera pas trouvée et donc elle sera construite (à l'exécution ultérieure, l'image construite sera trouvée et renvoyée).
L'image personnalisée est construite avec [_build_sandbox_image()](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/docker/image_agnostic_util.py#L29), qui crée un fichier docker en utilisant votre image personnalisée comme base et configure ensuite l'environnement pour OpenHands, comme ceci:
> Remarque: Le nom de l'image est modifié via [_get_new_image_name()](https://github.com/All-Hands-AI/OpenHands/blob/main/openhands/runtime/docker/image_agnostic_util.py#L63) et c'est ce nom modifié qui sera recherché lors des exécutions ultérieures.
## Dépannage / Erreurs
### Erreur: ```useradd: UID 1000 est non unique```
Si vous voyez cette erreur dans la sortie de la console, il s'agit du fait que OpenHands essaie de créer le utilisateur openhands dans le sandbox avec un ID d'utilisateur de 1000, cependant cet ID d'utilisateur est déjà utilisé dans l'image (pour une raison inconnue). Pour résoudre ce problème, changez la valeur du champ sandbox_user_id dans le fichier config.toml en une valeur différente:
Si vous voyez un message d'erreur indiquant que le port est utilisé ou indisponible, essayez de supprimer toutes les containers docker en cours d'exécution (exécutez `docker ps` et `docker rm` des containers concernés) puis ré-exécutez ```make run```
## Discuter
Pour d'autres problèmes ou questions rejoignez le [Slack](https://join.slack.com/t/opendevin/shared_invite/zt-2oikve2hu-UDxHeo8nsE69y6T7yFX_BA) ou le [Discord](https://discord.gg/ESHStjSjD4) et demandez!
Lorsque vous utilisez OpenHands, vous rencontrerez des cas où les choses fonctionnent bien, et d'autres où elles ne fonctionnent pas. Nous vous encourageons à fournir des commentaires lorsque vous utilisez OpenHands pour aider à donner des retours à l'équipe de développement, et peut-être plus important encore, créer un corpus ouvert d'exemples d'entraînement d'agents de codage -- Share-OpenHands !
## 📝 Comment fournir des commentaires
Fournir des commentaires est facile ! Lorsque vous utilisez OpenHands, vous pouvez appuyer sur le bouton pouce vers le haut ou pouce vers le bas à tout moment pendant votre interaction. Vous serez invité à fournir votre adresse e-mail (par exemple, afin que nous puissions vous contacter si nous voulons poser des questions de suivi), et vous pouvez choisir si vous souhaitez fournir des commentaires publiquement ou en privé.
Lorsque vous soumettez des données, vous pouvez les soumettre publiquement ou en privé.
* Les données **publiques** seront distribuées sous la licence MIT, comme OpenHands lui-même, et pourront être utilisées par la communauté pour entraîner et tester des modèles. Évidemment, les commentaires que vous pouvez rendre publics seront plus précieux pour la communauté dans son ensemble, donc lorsque vous ne traitez pas d'informations sensibles, nous vous encourageons à choisir cette option !
* Les données **privées** ne seront partagées qu'avec l'équipe OpenHands dans le but d'améliorer OpenHands.
### Qui collecte et stocke les données ?
Les données sont collectées et stockées par [All Hands AI](https://all-hands.dev), une entreprise fondée par les mainteneurs d'OpenHands pour soutenir et améliorer OpenHands.
### Comment les données publiques seront-elles publiées ?
Les données publiques seront publiées lorsque nous atteindrons des jalons fixes, tels que 1 000 exemples publics, 10 000 exemples publics, etc.
À ce moment-là, nous suivrons le processus de publication suivant :
1. Toutes les personnes qui ont contribué à des commentaires publics recevront un e-mail décrivant la publication des données et auront la possibilité de se retirer.
2. La ou les personnes en charge de la publication des données effectueront un contrôle de la qualité des données, en supprimant les commentaires de mauvaise qualité, en supprimant les adresses e-mail des soumissionnaires et en essayant de supprimer toute information sensible.
3. Les données seront publiées publiquement sous la licence MIT via des sites couramment utilisés tels que GitHub ou Hugging Face.
### Que faire si je veux que mes données soient supprimées ?
Pour les données sur les serveurs d'All Hands AI, nous sommes heureux de les supprimer sur demande :
**Une pièce de données :** Si vous souhaitez supprimer une pièce de données, nous ajouterons prochainement un mécanisme pour supprimer les pièces de données en utilisant le lien et le mot de passe qui s'affichent sur l'interface lorsque vous soumettez des données.
**Toutes les données :** Si vous souhaitez que toutes vos données soient supprimées, ou si vous n'avez pas l'ID et le mot de passe que vous avez reçus lors de la soumission des données, veuillez contacter `contact@all-hands.dev` à partir de l'adresse e-mail que vous avez enregistrée lorsque vous avez initialement soumis les données.
OpenHands peut être exécuté en mode CLI interactif, ce qui permet aux utilisateurs de démarrer une session interactive via la ligne de commande.
Ce mode est différent du [mode headless](headless-mode), qui est non interactif et mieux adapté aux scripts.
## Avec Python
Pour démarrer une session OpenHands interactive via la ligne de commande, suivez ces étapes :
1. Assurez-vous d'avoir suivi les [instructions de configuration de développement](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
2. Exécutez la commande suivante :
```bash
poetry run python -m openhands.core.cli
```
Cette commande démarrera une session interactive où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
Vous devrez vous assurer de définir votre modèle, votre clé API et d'autres paramètres via des variables d'environnement
[ou le fichier `config.toml`](https://github.com/All-Hands-AI/OpenHands/blob/main/config.template.toml).
## Avec Docker
Pour exécuter OpenHands en mode CLI avec Docker, suivez ces étapes :
1. Définissez `WORKSPACE_BASE` sur le répertoire que vous souhaitez qu'OpenHands modifie :
```bash
WORKSPACE_BASE=$(pwd)/workspace
```
2. Définissez `LLM_MODEL` sur le modèle que vous souhaitez utiliser :
```bash
LLM_MODEL="anthropic/claude-3-5-sonnet-20241022"
```
3. Définissez `LLM_API_KEY` sur votre clé API :
```bash
LLM_API_KEY="sk_test_12345"
```
4. Exécutez la commande Docker suivante :
```bash
docker run -it \
--pull=always \
-e SANDBOX_USER_ID=$(id -u)\
-e WORKSPACE_MOUNT_PATH=$WORKSPACE_BASE\
-e LLM_API_KEY=$LLM_API_KEY\
-e LLM_MODEL=$LLM_MODEL\
-v $WORKSPACE_BASE:/opt/workspace_base \
-v /var/run/docker.sock:/var/run/docker.sock \
--add-host host.docker.internal:host-gateway \
--name openhands-app-$(date +%Y%m%d%H%M%S)\
ghcr.io/all-hands-ai/openhands:0.11 \
python -m openhands.core.cli
```
Cette commande démarrera une session interactive dans Docker où vous pourrez saisir des tâches et recevoir des réponses d'OpenHands.
## Exemples de commandes CLI et de sorties attendues
Voici quelques exemples de commandes CLI et leurs sorties attendues :
### Exemple 1 : Tâche simple
```bash
Comment puis-je vous aider ? >> Écrivez un script Python qui affiche "Hello, World!"
```
Sortie attendue :
```bash
🤖 Bien sûr ! Voici un script Python qui affiche "Hello, World!" :
❯ print("Hello, World!")
```
### Exemple 2 : Commande Bash
```bash
Comment puis-je vous aider ? >> Créez un répertoire nommé "test_dir"
```
Sortie attendue :
```bash
🤖 Création d'un répertoire nommé "test_dir" :
❯ mkdir test_dir
```
### Exemple 3 : Gestion des erreurs
```bash
Comment puis-je vous aider ? >> Supprimez un fichier inexistant
Le sandbox est l'endroit où l'agent effectue ses tâches. Au lieu d'exécuter des commandes directement sur votre ordinateur (ce qui pourrait être risqué), l'agent les exécute à l'intérieur d'un conteneur Docker.
Le sandbox OpenHands par défaut (`python-nodejs:python3.12-nodejs22` de [nikolaik/python-nodejs](https://hub.docker.com/r/nikolaik/python-nodejs)) est livré avec certains paquets installés tels que Python et Node.js, mais peut nécessiter l'installation d'autres logiciels par défaut.
Vous avez deux options pour la personnalisation :
1. Utiliser une image existante avec les logiciels requis.
2. Créer votre propre image Docker personnalisée.
Si vous choisissez la première option, vous pouvez passer la section `Créer Votre Image Docker`.
## Créer Votre Image Docker
Pour créer une image Docker personnalisée, elle doit être basée sur Debian.
Par exemple, si vous voulez qu'OpenHands ait `ruby` installé, créez un `Dockerfile` avec le contenu suivant :
```dockerfile
FROMdebian:latest
# Installer les paquets requis
RUN apt-get update && apt-get install -y ruby
```
Enregistrez ce fichier dans un dossier. Ensuite, construisez votre image Docker (par exemple, nommée custom-image) en naviguant vers le dossier dans le terminal et en exécutant :
```bash
docker build -t custom-image .
```
Cela produira une nouvelle image appelée `custom-image`, qui sera disponible dans Docker.
> Notez que dans la configuration décrite dans ce document, OpenHands s'exécutera en tant qu'utilisateur "openhands" à l'intérieur du sandbox et donc tous les paquets installés via le docker file devraient être disponibles pour tous les utilisateurs du système, pas seulement root.
## Utiliser le Workflow de Développement
### Configuration
Tout d'abord, assurez-vous de pouvoir exécuter OpenHands en suivant les instructions dans [Development.md](https://github.com/All-Hands-AI/OpenHands/blob/main/Development.md).
### Spécifier l'Image de Base du Sandbox
Dans le fichier `config.toml` dans le répertoire OpenHands, définissez `sandbox_base_container_image` sur l'image que vous souhaitez utiliser. Cela peut être une image que vous avez déjà extraite ou une que vous avez construite :
```bash
[core]
...
sandbox_base_container_image="custom-image"
```
### Exécuter
Exécutez OpenHands en exécutant ```make run``` dans le répertoire de niveau supérieur.
## Explication Technique
Veuillez vous référer à la [section image docker personnalisée de la documentation d'exécution](https://docs.all-hands.dev/modules/usage/architecture/runtime#advanced-how-openhands-builds-and-maintains-od-runtime-images) pour plus de détails.
## Dépannage / Erreurs
### Erreur : ```useradd: UID 1000 is not unique```
Si vous voyez cette erreur dans la sortie de la console, c'est parce qu'OpenHands essaie de créer l'utilisateur openhands dans le sandbox avec un UID de 1000, mais cet UID est déjà utilisé dans l'image (pour une raison quelconque). Pour corriger cela, changez le champ sandbox_user_id dans le fichier config.toml à une valeur différente :
```toml
[core]
workspace_base="./workspace"
run_as_openhands=true
sandbox_base_container_image="custom_image"
sandbox_user_id="1001"
```
### Erreurs d'utilisation de port
Si vous voyez une erreur concernant un port déjà utilisé ou indisponible, essayez de supprimer tous les conteneurs Docker en cours d'exécution (exécutez `docker ps` et `docker rm` sur les conteneurs pertinents) puis réexécutez ```make run```.
## Discuter
Pour d'autres problèmes ou questions, rejoignez le [Slack](https://join.slack.com/t/opendevin/shared_invite/zt-2oikve2hu-UDxHeo8nsE69y6T7yFX_BA) ou le [Discord](https://discord.gg/ESHStjSjD4) et demandez !
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.