-
Notifications
You must be signed in to change notification settings - Fork 120
Description
Description
Allowing the user to skip certain or all initial questions when first running the tool, by using environment variables.
Use Case
This will be useful when running nanocoder in container environments, automating the tool (if one-shot command line provided prompts will be a thing later), and giving third party users a predictable environment to run this in.
I'm sysadmin/devops, and would like to give developers access to nanocoder in a predictable way, where they don't have to have the knowledge of things like the LLM they use, API keys, or even the working directory. With future one-shot/non-interactive automation options, I could also see a use for this in a CI/CD pipeline.
It would also be useful in order to not have agents.config.json files littered around the active codebase, which could potentially be an issue for leaking secrets (like API keys). This way "docker secrets" could handle the issue. Though I'll be clear, I think there are probably use cases outside of docker as well, but my main focus remains with containers, since it allows for a predictable execution environment that can't stray outside the context of the container. Using docker also allows you to let the LLM install system tools with little risk to the host system, and reset that environment to its default state easily.
Proposed Solution
When starting nanocoder, it should look for environment variables in a format that makes it easy to automatically parse and set options, and fill in the blanks or override any existing agents.config.json file.
I don't think these environment variables should be actually written into the agents.config.json file, at least not without opting into that with a command line parameter for nanocoder, for secrets management or other reasons.
Say you want to mimic the following agents.config.json file:
{
"nanocoder": {
"providers": [
{
"name": "MyOllama",
"models": [
"devstral-small-2:latest"
],
"baseUrl": "http://ollama:11434/v1"
}
]
}
}
It should be functionally identical to have this environment variables set:
NANOCODER_PROVIDERS='[{"name": "MyOllama", "models": ["devstral-small-2:latest"], "baseUrl": "http://ollama:11434/v1"}]'
Obviously there should be more variables like this so you can specify MCP servers, etc.
Since agents.config.json is JSON, and you are able to have multiple providers, etc., I think it would be acceptable as a first pass of this to simply provide chunks of JSON in your environment variables as shown above.
A more granular approach would be nice, but it's probably a lot of work to parse user named variables, like:
NANOCODER_PROVIDERS_MyOllama_MODELS='["devstral-small-2:latest"]'
NANOCODER_PROVIDERS_MyOllama_BASEURL="http://ollama:11434/v1"
Alternatives Considered
Supplying agents.config.json as a docker config, or baked into the image. Which is obviously a way to do it, but using environment variables is emerging as a fairly standard solution in containerization, and will allow for this with a minimal number of extra files.
Additional Context
- I have searched existing issues to ensure this is not a duplicate
- This feature aligns with the project's goals (local-first AI assistance)
Implementation Notes (optional)
I would favor the more granular implementation, and possibly to save yourself some future headaches, maybe the simpler approach should still be implemented in a way that iterate over variable names starting with "NANOCODER_" and procedurally extracting JSON keys from it anyway, to avoid a spaghetti mess of looking for very specifically named variables. Though I supposed you'd need at the very least a white-list of possible key names and their formats anyway for security purposes. I'm not a proficient developer, so not sure how to attack this.
Maybe the easiest approach would be to only capitalize "NANOCODER_" and keep the rest in its proper capitalizations, to make it easier to parse, like "NANOCODER_providers" or "NANOCODER_providers_MyOllama_baseUrl" (if you go with the granular approach)