Whats are the main issues?
-
Our installer needs to be used in a way thats similar to create-react-app (call dim new-app once per project -- not a one-time install like open claw).
- We can't just install a global
dimos executable and be done.
- Not only do we have BOTH global and project-specific install aspects, but we have weird inbetween things, like project-specific choices that affect globally installed stuff - like nix with direnv.
-
dim new-app requires lots of Opinions (things that probably shouldn't be decided by one guy)
If we decide what SHOULD happen, I can implement it (and make it pretty).
What we should do right now
- A globally installed command (different than our existing
dimos command). Like dim or ds that:
- Is insanely reliable, bulletproof, and heavily tested. (I'm going to suggest Rust compiled against musl, using cliclack)
- Helps OEMs diagnose problems (
dim doctor), establish a systemd process, and perform system-level modifications (like systemctl multicast stuff)
- Has a
dim new-app sub-command that asks the user a bunch of questions, then creates a git repo filled with whatever setup the user picked (docker based, apt-based, nix-based, devcontainer based, etc)
Everyone should have input on this:
-
Have template repos that decide: What is a apt-based/nix-based/docker-based project-that-uses-dimos supposed to look like? (folder structure, starter files)
- ex: a repo with a dockerfile that starts with
FROM dimos:<some tag>
- Note: Austin, Humzah (spel?), and Miguel have all requested template repos - creating these kills two birds with one stone
- Problems will be revealed -- problems like we can't just copy our flake.nix to an empty repo and it work (needs to be tracked and copying a flake is a nix anit-pattern, flakes are supposed to be imported)
-
Decide:
- What should be asked on the inital global install?
- What questions should be asked during the
dim new-app phase?
- do we ask them to select which dimos extras they want and then install corrisponding system level stuff? (like dds)
- if they pick cuda, do we just say
- do we force them to use
uv or ask them? (I say force uv, but many roboticists use conda)
- if they pick nix do we ask if they want to use direnv? (I say keep it simple: let them setup direnv, but @leshy might disagree)
- etc
Whats are the main issues?
Our installer needs to be used in a way thats similar to create-react-app (call
dim new-apponce per project -- not a one-time install like open claw).dimosexecutable and be done.dim new-apprequires lots of Opinions (things that probably shouldn't be decided by one guy)If we decide what SHOULD happen, I can implement it (and make it pretty).
What we should do right now
dimoscommand). Likedimordsthat:dim doctor), establish a systemd process, and perform system-level modifications (likesystemctl multicaststuff)dim new-appsub-command that asks the user a bunch of questions, then creates a git repo filled with whatever setup the user picked (docker based, apt-based, nix-based, devcontainer based, etc)Everyone should have input on this:
Have template repos that decide: What is a apt-based/nix-based/docker-based project-that-uses-dimos supposed to look like? (folder structure, starter files)
FROM dimos:<some tag>Decide:
dim new-appphase?uvor ask them? (I say force uv, but many roboticists use conda)