FR: Custom location of file with OpenAI API Key

[chrisgrieser]

Basically the same issue I also reported for ai.vim: Some of us have their dotfiles public, so that putting the API key into files like .zshenv is not ideal.

The workaround right now is to set it via vim.env outside of the dotfiles repo, and symlink that file into the nvim config, which is unnecessarily many hoops to jump through just to get it set up.

[RhydianJenkins]

I have something like this in my zshrc

[ -f ~/.zshrc.local ] && source ~/.zshrc.local

That way, I can add secret/machine specific config to my .zshrc.local file without it getting pushed to my dotfiles repo.

Edit: Or you could just not source track your .zshenv file :D

[olimorris]

For anyone reading this using fish, I have a ~/.env file which is in my dotfiles folder but not commited to a public repo (everything is blacklisted by default).

I then have this simple function to load the env file:

function load_env_vars -d "Load variables in a .env file"
    for i in (cat $argv)
        set arr (echo $i |tr = \n)
        set -gx $arr[1] $arr[2]
    end
end

load_env_vars ~/.env

with the env file looking like:

OPENAI_API_KEY=abc123

[jackMort]

I like the idea of keeping it as an environment variable, but we can consider storing it in a different way

[chrisgrieser]

while all methods suggested here work, I think the solution suggested by the dev of ai.vim seems the most user-friendly to me:

Maybe defaulting to ~/.config/nvim/.openai_key with an option to override the file path?

[FBorowiec]

I hope my solution inspires someone:
I added a ~/.config/.open_ai with the following content: OPENAI_API_KEY=abc123.
Then I added this to my .zshrc:

source ~/.config/.open_ai

[rounakcodes]

Thanks for the attempt. For future readers: The issue with this solution is that it assumes nvim is launched after zsh. When you want to open nvim with something like alacritty -e nvim (I use it from Xmonad config) or such other shell command/script which is triggered via a keybinding, then this won't work. The other solutions which use nvim config to setup the environment variable will always work as nvim will always load its own config.

[LoneExile]

Here my solution

ChatGPT.lua

local env = vim.fn.expand('$HOME') .. '/.config/nvim/env.lua'
dofile(env)

if vim.env.OPENAI_API_KEY == nil then
  print('Please set the OPENAI_API_KEY environment variable')
  return
end

local status_ok, chatgpt = pcall(require, 'chatgpt')
if not status_ok then
  return
end

chatgpt.setup({})

env.lua ( use gitignore on this file )

vim.cmd("let $OPENAI_API_KEY='<PUT-YOUR-KEY_HERE>'")

[gvolpe]

I've put up a PR that lets you configure the secret on setup: #147

This is my preference and how I currently use this plugin in a declarative way, may not be for everyone.

[rounakcodes]

Most of them would want their nvim config to be version controlled. Secrets should not be hosted along with the code. Hence, this is not a good approach. Even if its your preference, its unlikely to get merged as it sends a wrong message: That it is fine to use secrets directly in code.

[gvolpe]

I understand where you come from, but this is completely fine whenever secrets are encrypted. A custom file location with the API Key will follow the same approach on my Home Manager / NixOS set up. Thus, it's fine to assume Nix users are the target audience of my PR (which has a big Neovim user base) more than regular Neovim users.