replying to @dtinth
Glad it works! If you want it in agent-env itself (an SMB option in the configurator, or Samba in the image), say the word.
Commit
480bb82
Would love to have that as optional feature, but let's talk first. I kinda want the components to be more modular. Grill me pls.
Q1, the root: what is a "component"? Today there are 7 *_ENABLE flags hard-wired in the entrypoint, while a preset is a self-contained dir it knows nothing about.
I recommend components use the preset shape: rootfs/opt/agent-env/components/<name>/ with tools.toml, a daemon…
Definitely in the same image, yes. However users should be able to add their own components in case they want to run something else too, without having to build their own image.
Q2, where user components live and what they may run as. A built-in one may need root (sshd, the desktop, rootless dockerd). A user one is just files in a volume.
I recommend user components live in ~/.config/agent-env/components/<name>/, the same shape as built-ins, on the home…
Hmm… let me think… what needs to be root vs what can be userland. Could everything be userland?
Almost everything. Looking at what runs here:
Must stay root (the core, not components):
- sshd: it logs you in as dev
- the gateway (caddy + oauth2-proxy as
gateway): an edge hole must not land in the account with sudo, and dev's code must not read its secrets
- the…Agree. Please look at all the core and components. What are the common things it need to do? For example, I might want to set up a daemon that runs whenever this container runs. I would have to configure pitchfork myself, etc. So I am thinking of something more convention-based.…
Surveyed everything. The glue every piece repeats:
1. an enable flag
2. a daemon (user pitchfork), with readiness (port/cmd/http) and sometimes depends
3. a loopback run script reading env with defaults
4. a gateway route under /~env/<name>, prefix stripped or passed through
5.…
- I wonder if we can get rid of the preset and make it also a component.
-
component.env - how about toml?
- run - I think this can link to a folder with pitchfork.toml so we can run pitchfork on it.
- I don't like the *_ENABLED env. Maybe better to have it not run in the…1. Presets as components: yes. opencode becomes a component that claims / . vanilla is simply "nothing claims /". PRIMARY_COMMAND becomes a tiny built-in component. One rule: at most one component may claim / .
2. TOML: yes, component.toml.
3. pitchfork.toml in the folder:…
Sounds good. It should support symlinking.
agent-env-component.toml?
I think we should also have some kind of support for startup script or hook which runs before we start user-level pitchfork. Then this would let me write script that provision. I would put it in a compose…Good. agent-env-component.toml it is: distinctive, so a repo root can be a component by itself.
Symlinks: work, with one catch I just tested. pitchfork names daemons after the link's target, so components/smb -> ~/src/my-repo shows up as my-repo/web. pitchfork.toml has a…
Agree. Also want an easy way to install a component, so maybe
agent-env component install . which idempotently creates a symlink. Name is defined in toml and it refuses to replace a symlink if already installed but points to different folder unless --force? It should lint stuff…Agree on all of it:
-
agent-env component install . reads the name from agent-env-component.toml and symlinks ~/.config/agent-env/components/<name>. It's a no-op if the link already points here, refuses if it points elsewhere unless --force. Plus uninstall <name> and list.…Next: what goes in agent-env-component.toml. My proposal, smb as the example:…
Agree. The host is good. For mise tools, on reconcile, it would symlink the tool to conf.d right? e.g.
conf.d/agent-env-<name>.toml. And also deletes the ones not listed?Yes, symlink rather than copy (today it copies), so editing a component's mise.toml applies on the next
mise install. Tested: mise reads a conf.d symlink pointing outside ~/.config with no trust prompt, [env] included.
Deleting: the reconciler owns every…Looks good. Why we need
agent-env opencode in the first place? What is it for, like what are its use cases? No need to keep backwards compatibility tho.
Btw just noting, before you start the implementation I want you to make a docs describing the component system. Then, have a…Good question. Looking at them, there's not much case for it:
-
agent-env tui cds to the workspace, waits for the server and runs opencode --server .... But env.sh already sets OPENCODE_SERVER and its password in login shells, so plain opencode attaches to the same server.
- agent-env password prints a value env.sh already exports as $OPENCODE_SERVER_PASSWORD.
So I'd drop commands/ from the convention. A component that wants a helper ships bin/, linked into ~/.local/bin when installed (lint: no clash with another component's command). Then helpers are ordinary commands, not agent-env subcommands. OK?
Noted on the docs: before any code I'll write a doc for the component system, have a Haiku subagent review it as a user who reads only that file, and iterate until it reads clearly. Then I'll show you.commit 480bb82