gemini-cli: write to system settings file

[iainlane]

Description

gemini writes state back to the user config file (~/.gemini/settings.json), which doesn't work when it's a symlink into the nix store. To fix this, we can write our settings to the "system" settings file instead, and set the appropriate environment variable so that this file can still be placed in ~/.config/gemini. This leaves setttings.json free for gemini to write to as it wishes.

Checklist

• Change is backwards compatible.

• Code formatted with nix fmt or
  nix-shell -p treefmt nixfmt deadnix keep-sorted --run treefmt.

• Code tested through nix run .#tests -- test-all or
  nix-shell --pure tests -A run.all.

• Test cases updated/added. See example.

• Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • Added myself as module maintainer. See example.
  • Generate a news entry. See News
  • Basic tests added. See Tests

• If this PR adds an exciting new feature or contains a breaking change.

  • Generate a news entry. See News

[rrvsh]

lgtm good idea

[khaneliman]

This will work, only concern would be for anyone who might want to actually do a system management through nixpkgs and then user level management through home manager is no longer going to have that separation.

EDIT: Maybe make the system settings a option so someone who wants to keep it user settings level can, but those who want to use the system level has that choice?

[iainlane]

@khaneliman good point. What I see is that then we'll have to go back to writing settings.json, and gemini doesn't work properly if this points to the store. You can't log in interactively as it wants to write the auth block. Settings can't be saved either, but this perhaps less of a blocker for nix users?

On my system right now this file has:

{
  "security": {
    "auth": {
      "selectedType": "oauth-personal"
    }
  },
  "general": {
    "previewFeatures": true
  }
}

...which was written by the tool itself.

Counter proposal: we could document that this sets GEMINI_CLI_SYSTEM_SETTINGS_PATH, and this makes it incompatible with managing that file another way.

WDYT? I don't mind adding an option really, but it's worth a brief discussion.

[khaneliman]

I guess I'd prefer an option to keep it flexible for more scenarios. We can even default it to enabled so that it works the way a normal user would expect.

What I see is that then we'll have to go back to writing settings.json, and gemini doesn't work properly if this points to the store. You can't log in interactively as it wants to write the auItith block. Settings can't be saved either, but this perhaps less of a blocker for nix users?

You CAN use it still. It just doesn't persist settings because it can't write to the file. But, you can add the settings yourself and it works just fine persisting the things you tell it to.

[iainlane]

You CAN use it still. It just doesn't persist settings because it can't write to the file. But, you can add the settings yourself and it works just fine persisting the things you tell it to.

I'd just like to check what you mean here because I can't quite tell what you are disagreeing with / correcting me on. Feels like that's what I said. But I don't want to misunderstand and not fix the PR properly.

[khaneliman]

Just meant that the app works fine, it's just unusable to save changes to the file through the app.