sourcegraph / sg.nvim

Experimental Sourcegraph + Cody plugin for Neovim

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Auth on nixOS

BirdeeHub opened this issue · comments

I can't auth anymore. I used to do it in lua, fetched from bitwarden,

I disabled all of that and ran just the setup function. I ran SourcegraphLogin and SourcegraphLogin!

Neither throw errors, neither work.

I tried to roll back.
The old authentication scheme no longer works at all so rolling back to before the auth changes no longer works either.

Is the only way to auth programmatically by environment variables now? This is problematic for me as it forces me to find a way to auth without using bitwarden and without putting any secrets in my nix

The environment variables do work though

Can you set the env vars in the environment you're loading neovim from? If you have the endpoint and access token?

Also, it's possible you need something in your environment for this crate to work: https://crates.io/crates/keyring

I assumed that it would work cause I tried in windows, linux and mac.

Hmmm ok ill get back to you after I try the keyring. Might have to be later though I have some things to do today.

I will say that the environment variable option does work, I'd rather not set it independently though I was hoping to be able to manage that from my config. I can put environment variables in my neovim flake and that works but then the token is in my nix code.

I was authenticating like this
https://github.com/BirdeeHub/birdeevim/blob/addb4805393de8bab82de11e19c910f67cff7a8f/plugin/AI.lua#L11

It checks if you are logged in, if not it prompts a bitwarden login and then fetches the token using a uuid from bitwarden store.

I understand this method no longer works, as the function has been changed for a direct check to environment variables, but the only method that seems to work for me at all is environment variables right now. The regular login methods dont work.

I dont 100% know how to add the keyring to my environment entirely, Do i just add it to the path for neovim or do I need it as a build input? Im not an experienced dev by any means I just like to tinker with stuff. I will do my best at that tonight.

My config is based on this nix flake I made for neovim config
Its a generalized scheme for neovim configuration in nix that allows you to do normal neovim configuration in your preferred method but still be able to access values from nix and do project specific packaging from within 1 mostly normal neovim config.

https://github.com/BirdeeHub/nixCats-nvim

You should check it out its pretty cool :) Maybe you can verify if Im loading the config folder accurately but im 95% sure I have it.

This is how im loading the config folder if you want to check it out. Its like 20 lines of vimscript.
https://github.com/BirdeeHub/nixCats-nvim/blob/main/nix/builder/default.nix

Basically its a category system for downloading plugins in nix, then it writes the categories you have to a table in a lua file that you can check in your config, and it loads the flake as if it was a config folder.

Also I have tried all commits up through the one before the auth changes, back to the one from last month. The old ones use the old scheme but it doesnt work anymore, the new ones use the new scheme, which doesnt work unless I use env variables

Does using require("sg.auth").set(endpoint, token) work OK for you in your config? I think that should work at startup as well (only thing is I'm not sure if it will error if the keyring-rs stuff doesn't work on your OS. I'm not sure how to test that yet).

( note for myself, to check out this thread some more tomorrow: hwchen/keyring-rs#36 )

I can write a patch as well to force not storing it in the keyring stuff

It works fantastic!
Was that there before and I was just using an old scheme?
I was passing it in in a table like before, now im doing it the way you said.
Passing it in as 2 separate arguments to require('sg.auth').set instead of as a table to the old require('sg.auth').set_nvim_auth worked great!

Can I still check login status from lua?

Can I still check login status from lua?

yes. It creates the variables within nvim so yes I can check if those exist and if not run my auth prompt. Sweet.

Thank you!!!!

Oh.. Its not persistent... hmmmmm

it just sets the variables but from lua where I am able to supply a local filepath. With bitwarden I would have to put in a password every time I open nvim.

This is.... its ok, but not ideal like before where it happens once and thats it. Although, to be fair, it did just save in cleartext to a local filepath so that wasnt as ideal hahaha. This is just basically me recreating that same thing. Getting it to somehow hook into the persistent keyring from the lua setup function would be better but im not sure how possible that is with this method, or even if I have the keyring or how that works or not. I just opened github and saw i had a notification so I went to check.

Hrm. I'm not sure whether to open another issue or add to this one. Since the switch to Pro about 15 minutes ago, I'm unable to complete auth flow. It told me I wasn't logged in, I did :SourcegraphLogin, it took me through the web flow, got a token of the form

http://localhost:52068/api/sourcegraph/token?token=sgp_12345...

and was asked to restart Neovim, which I did but... still not authenticated. I do note that copy/pasting the token from the URL and doing as you suggested above:

:lua  require("sg.auth").set("https://sourcegraph.com", "sgp_12345...") 

does successfully authenticate. So is it possible this is wider than a Nix problem? Arch 6.6.6-arch1-1 here.

@richchurcher can you paste what's in :checkhealth sg for me?

@BirdeeHub yes, basically it comes down to I don't want to be the one who manages credentials ;) so you need to find some way to pass it to the system. Ideally, a keyring would work on your system, so we can try and figure out how to make that work.

Basically the options are:

  1. Load the tokens into the environment before loading nvim
  2. Load the tokens into the environment via lua before calling sg.setup()
  3. Use the keyring provider, which will manage persistence

It seems to me one of the first two options should be able to work for you (load them up once / store them locally in some file that only your user could access / save them to some env var that is shared / etc)

Yes absolutely. It will work fine. It works exactly like before now, the only difference is I'm the one saving it to a file rather than you. I can work on figuring out a better auth solution myself this way at least without necessarily having it need to be within nix. I'm happy with that.

If that is how it should work then I am fine with this solution. I will implement fetching from bitwarden and saving to local and fetching it from the file for now, and then come up with a better idea later.

Should I close it or should I leave it open because the regular sign in methods don't work? Ill let you close it I think.

Sure! Before the above auth workaround:

sg: require("sg.health").check()

sg.nvim report ~
- Machine: x86_64, sysname: Linux
- OK Valid nvim version: 0.10.0-dev+gc431d820e
- OK Found `cargo` (cargo 1.74.1 (ecb9851af 2023-10-18)) is executable
-     Use `:SourcegraphDownloadBinaries` to avoid building locally.
- OK Found `sg-nvim-agent`: "/home/basie/.local/share/nvim/lazy/sg.nvim/target/release/sg-nvim-agent"
- OK Found `node` (config.node_executable) is executable.
      Version: '21.2.0'
- OK Found `cody-agent`: /home/basie/.local/share/nvim/lazy/sg.nvim/dist/cody-agent.js
- ERROR No valid auth strategy detected. See ':help |sg'| for more info.
- ERROR Cannot check Cody Status, not logged in
- ERROR sg.nvim has issues that need to be resolved

After:

sg: require("sg.health").check()

sg.nvim report ~
- Machine: x86_64, sysname: Linux
- OK Valid nvim version: 0.10.0-dev+gc431d820e
- OK Found `cargo` (cargo 1.74.1 (ecb9851af 2023-10-18)) is executable
-     Use `:SourcegraphDownloadBinaries` to avoid building locally.
- OK Found `sg-nvim-agent`: "/home/basie/.local/share/nvim/lazy/sg.nvim/target/release/sg-nvim-agent"
- OK Found `node` (config.node_executable) is executable.
      Version: '21.2.0'
- OK Found `cody-agent`: /home/basie/.local/share/nvim/lazy/sg.nvim/dist/cody-agent.js
- OK   Authentication setup correctly
- OK     endpoint set to: https://sourcegraph.com
- ERROR   Sourcegraph Connection info failed: nil
- ERROR Cody Auth Failed: nil
- ERROR sg.nvim has issues that need to be resolved

Relevant config:

local on_attach = function(client, bufnr)
    if client.supports_method("textDocument/formatting") then
        vim.api.nvim_clear_autocmds({ group = augroup, buffer = bufnr })
        vim.api.nvim_create_autocmd("BufWritePre", {
            buffer = bufnr,
            callback = function()
                lsp_formatting(bufnr)
            end,
            group = augroup,
        })
    end
    -- LSP semantic tokens conflicts with Treesitter, turn it off:
    client.server_capabilities.semanticTokensProvider = nil
end

require("sg").setup {
    auth_strategy = { "nvim" },
    on_attach = on_attach,
}

Tried a full remove/reinstall for good measure, no dice.

Hrm. Maybe I'm out of date, and SRC_ACCESS_TOKEN is the way forward for now? I could swear I didn't used to do that :D

FWIW, with the environment variables set I get:

sg: require("sg.health").check()

sg.nvim report ~
- Machine: x86_64, sysname: Linux
- OK Valid nvim version: 0.10.0-dev+gc431d820e
- OK Found `cargo` (cargo 1.74.1 (ecb9851af 2023-10-18)) is executable
-     Use `:SourcegraphDownloadBinaries` to avoid building locally.
- OK Found `sg-nvim-agent`: "/home/basie/.local/share/nvim/lazy/sg.nvim/dist/sg-nvim-agent"
- OK Found `node` (config.node_executable) is executable.
      Version: '21.2.0'
- OK Found `cody-agent`: /home/basie/.local/share/nvim/lazy/sg.nvim/dist/cody-agent.js
- OK   Authentication setup correctly
- OK     endpoint set to: https://sourcegraph.com
- OK Found correct binary versions: "1.0.5" = "1.0.5"
- OK   Sourcegraph Connection info: {
    access_token_set = true,
    endpoint = "https://sourcegraph.com",
    sg_nvim_version = "1.0.5",
    sourcegraph_version = {
      build = "254842_2023-12-14_5.2-70b068c4c6d9",
      product = "254842_2023-12-14_5.2-70b068c4c6d9"
    }
  }
- To manage your Cody Account, navigate to: https://sourcegraph.com/cody/manage
- OK Cody Account Information: {
    chat_limit = 0,
    chat_usage = 1,
    code_limit = 0,
    code_usage = 0,
    cody_pro_enabled = true,
    username = "richchurcher"
  }
- OK sg.nvim is ready to run

so it's not like I don't have a workaround. Just the current behaviour of :SourcegraphLogin feels a bit like I'm hitting a weird edge case 🙂

yeah sourcegraphLogin and sourcegraphLogin! are meant to sign you in but they do not, and thus we are required to use the lua auth set or the envvars. They changed SourcegrahLogin to be a redirect to browser experience and SourcegraphLogin! to be like the old way. I think they also added a keyring? But my stuff and I guess your stuff isnt saving to that keyring so its not working. The issue is I dont actually know how to setup the rust keyring the right way but I suppose ill have to tackle that at some point soon XD

For now, Im just getting it from bitwarden and saving it to a local file in the data directory like it did before.

Hmm, SourcegraphLogin should open up a browser window to do the login / authentication in the browser. When you do that @richchurcher it open a browser window at all? or not?

Yep! That part of the flow works fine. Then it tells me to restart nvim, which I do and... still not authenticated.

Oh, very weird -- I'll try and at least add some additional logging/tracing information so we can figure out what's going on there. (Might not be able to get to it super soon though because I'm out until January starting next week, sorry for any inconvenience :/)

No I completely get it. I'll poke around myself and see if I can turn anything up. Have a great break!

Oh, also, via that method, I realized it actually cant read any of my files. I will let you know if I manage to figure out why and in what circumstances that happens.

But yeah the normal login method gives me the same issue as rich.

Also, if you decide you are curious about nix over the break, I pushed some good updates to nixCats-nvim XD

I wonder if it's a file permissions or location thing... I'll try to take a peek after work.

OK, I'm back from break and working on sg.nvim again, so I can try and track stuff down as needed.

What's each of your current status for the issue? haha I'm not 100% sure where everything left off at this point

Oh boy... TBH I completely spaced on this! I'll revert my workaround and report back. Hope your holiday was delightful :)

Mine still cant read the project it is in.

To be honest I dont even use it much to begin with so I kinda forgot about it too. Havent used it in a while

It was cool when it was able to read the project and tell me where stuff is being called and stuff but yeah its kinda not that useful if it cant.

Ah, @BirdeeHub that's a separate problem. We added some new ways to search local context in the VSCode plugin that I need to port over to neovim, so that's expected (but on my todo list)

Ah. Okok. Well, Im glad it's not a surprise then

Well, if that's the expected behavior, it appears that the auth option you added works fine for me then. Assuming that the not being able to read the project thing is expected regardless of auth of course.

Ya, I'm working on that part as we speak :) Thanks for the patience!

AHAHAHA YESSSSS CODY IS BAAAAAACK

TYSM
It works. It can read my files now and stuff.

@tjdevries did I give you enough credit across the repo to include a template like this? I mention your? the? project like 30 bajillion times.

https://github.com/BirdeeHub/nixCats-nvim/blob/nixCats-5.0.0/nix/templates/kickstart-nvim/init.lua

haha yes, it's great. don't worry about it