I'm curious at how interconnected to CLI repo is w...
# questions
w
I'm curious at how interconnected to CLI repo is with the main repo? If we have the web front end running, is it utilizing anything from the CLI repo to do any heavy lifting behind the scenes? The reason I ask is if we want to start making contributions to the CLI repo in a fork and we want the latest version of our fork to be what our self-hosted web front end uses. Do we have to modify anything in particular so that it uses the fork and not the main repo version?
c
The CLI repo doesn't use directly the web (main) repo. And the main repo doesn't use the CLI repo 🤔 Could you maybe tell how you are running a web frontend (which)? cc: @quick-window-91705
q
The CLI repo is completely separate from the web (main) repo as of today However, we have been thinking about something along this line. For the web UI when looking at a single agent doing its work, instead of having a react UI we could just have one big terminal running the CLI TUI instead Essentially embed the TUI like an iframe to interact with the agent
👀 1
w
Oh this is very good information. So if you implemented agent or skill improvements in the cli you'd have to duplicate that in the react UI version. Is one more advanced than the other right now? If you had to recommend a team, use one or the other as their workhorse is one more reliable/efficient/effective at engineering tasks?
q
Really depends on your needs CLI is an easier setup, but doesn't have sandbox isolation (yet). Convos are started based on your current working directory Web UI has sandbox isolation by default. You can also start convos with a repo As far as efficacy goes they are both equally good (they run the same agent)
c
Yes, I would strongly recommend starting with the CLI - it's simpler, it does the job, and you will know if you want stuff not in it The thing is, OpenHands has a huge surface right now - SDK for programmatic use, CLI, single machine Web UI, multi-user hosted Cloud, multi-user self-hosted Enterprise. The thing is, if you want to play and try and figure out your workflows, and maybe contribute to it, I do think the CLI is best
For some background. We have recently rebuilt a lot of OpenHands, from what we call legacy V0 to the current version V1. SDK and CLI repos have been completely rebuilt, they're V1 all the way. The web repo though, is like, 3+ codebases into one repo, it still has code relying on V0, and/or some tight coupling that we'll get cleaned up in time, and I do see that right now it creates a bit of confusion and issues. So if you wish to just use OH and figure out things, I would recommend _the V1 OpenHands_: via SDK/CLI, and take it from there: CLI also has an integration with the Cloud, so you can also take advantage of Cloud features and maybe figure out if you want something else That said, all this surface works, and people are trying to help, so you can always choose web, and please know that a lot of work and attention is going into it.
Also, the CLI actually has the ability to run a web interface: https://docs.openhands.dev/openhands/usage/cli/web-interface
(yes, OpenHands has... a lot 😅)
w
@calm-artist-7206 - "Could you maybe tell how you are running a web frontend (which)?" I am not yet. Currently in cli only with the intention of setting up virtual workspaces for everyone at the company with cli/web frontends depending on preference and/or department. This plan was under the assumption that there is a centralized engine of sorts, but in lieu of that I have to rethink things I'll stick to the cli for the heavy lifting and explore the web frontend for testing and lighter less complicated work. thanks!