Change GitHub accounts decoupled from Git Config

[armindarvish]

Hi,

Is there a way to decouple the GitHub account from git config?

I am trying to support multiple accounts in my package, consult-gh, but since I added support for magit/forge, I would like to have switching accounts integrated with forge as well, but currently forge is using ghub and therefore git config to get the user info and retrieve tokens from auth-source-search. I would like to be able to customize that behavior and pass usernames decoupled from git config.

For example, if you can add a variable that keeps the current user info (host, username, etc.) that is used for authenticaiton. Then I can simply edit that variable and let forge and ghub do their normal things. Normal users should not see any difference because this variable can pick up its default value from git config anyway. Note that I cannot pass user and host to ghub--token because everything else in forge is calling ghub--token on its own.

[armindarvish]

Another approach would be to customizable variable that takes a function and ghub--token calls that function. This will allow the users to define custom functions, which would then make it easier to customize things. For example, instead of defining a completely new auth-source-backend as in this discussion the user can override the behavior of ghub--token with a different function. This way all the other packages that will use ghub--token like forge will be doing the same thing!

[tarsius]

Is there a way to decouple the GitHub account from git config?

I am trying to support multiple accounts in my package, consult-gh, but since I added support for magit/forge, I would like to have switching accounts integrated with forge as well, but currently

forge is using ghub and therefore git config to get the user info and retrieve tokens from auth-source-search. I would like to be able to customize that behavior and pass usernames decoupled from git config.

For example, if you can add a variable that keeps the current user info (host, username, etc.) that is used for authenticaiton. Then I can simply edit that variable and let forge and ghub do their normal things.

You should be able to do that using this basic idea:

(cl-defmethod ghub--username :around (host &optional forge)
  (or your-variable
      (cl-call-next-method)))

Normal users should not see any difference because this variable can pick up its default value from git config anyway.

If you do something like what I suggested above, then I ask you to make users aware that some ghub and forge documentation is superseded by that.

The Git variables can be used to use different users in different repositories. If you override these repository-local settings with one global variable, there obviously is some loss of functionality.

(Alternatively, why not just use the Git variable?)

Note that I cannot pass user and host to ghub--token because everything else in forge is calling ghub--token on its own.

That makes it sound like we call this internal function all over the place, but it is actually quite simple. ghub-request/ghub--graphql-vacuum are the only callers of ghub--headers, which is the only caller of ghub--auth, which is the only callers of ghub--token.

But yes, you are not supposed to pass arguments to that function directly. It's a very internal function.

Note however that ghub-request does support specifying the username, token, host and forge explicitly. It's just that Forge doesn't use that option.

Another approach would be to customizable variable that takes a function and ghub--token calls that function. This will allow the users to define custom functions, which would then make it easier to customize things.

Ghub doesn't provide such a variable, but if one really wanted to bypass auth-source, then one could just use an override advice for ghub--token.

For example, instead of defining a completely new auth-source-backend as in this discussion the user can override the behavior of ghub--token with a different function.

That discussion demonstrates that it is actually fairly simple to define a new auth-source backend.

This way all the other packages that will use ghub--token like forge will be doing the same thing!

The same happens if you configure this at the auth-source level.

I would assume that a user who doesn't want to use any of the available auth-source backends with Forge would also not want to use to do that with any other package that uses auth-source. By teaching auth-source about another authentification information source, all those packages can make use of it. That's the purpose of auth-source: not every package that has to store some secrets has to implement support for the numerous secret stores in existance. Support for another backend can be implemented once for auth-source, and then the users of all packages that use auth-source can use that backend.

---

You seem to conflate two distinct things:

1. How to store and retrieve the secret needed to identify ourselves. That's what ghub--token deals with.
2. How to determine who we are and what host we want to talk to. That's what ghub--username and ghub--host deal with.

You have concentrated on the former function but what is really matters for you are the latter two functions.

---

I've written the above a while ago but then did not post it because it doesn't address the most important part: "can you make changes so my hacks are not necessary".

Yes, and that would help with the code in Forge that allows viewing topics even if the respective repository hasn't been cloned and or been added to the local database. That works most of the time, but not always -- for the same simply ignoring that a repository might not exist locally doesn't work for you either.

I will have to look into teaching forge-visit-setup-buffer to forgo using magit-setup-buffer when necessary. Patching related functions, like you have done, should work also, but it would be better to just avoid the unnecessary/impossible work, instead of trying to neuter it.

[armindarvish]

@tarsius Thanks for the detailed response and discussion. I think the last part of your answer captures the core of the discussion. In an Ideal world, forge can visit/edit any topic without any needs for local variables (this includes not just a local repo, but also the git user!). All it needs is to know who the user is and what secret to use to identify the user when editing topics (those can be provided in some interactive way if needed or passed to a function as variables rather than relying on a locally stored value). The current approach with using magit-setup-buffer and the ghub--token etc. just makes it hard to use forge as a general tool. Of course, I can understand that this is voluntary open source work, and you will have to spend time to redo things, etc. and that's not always an option. That's why I opened this as a discussion to see if you think it makes sense and want to look into it or not.

Now let me first make a general suggestion and then address some of the questions you had:
I think it makes perfect sense to have multiple global accounts stored and allow the user to switch between them. You can make some interactive commands for storing such global credentials for forge. I tried this, and it works, but with the current approach of forge, I had to hack a few things to get it to work. I used auth-source-creation-prompts to query the user to get username, host and token and then stored them in auth-sources accordingly. Then, I keep a plist of all the known identities (without secrets, of course) and can switch between them globally (not locally inside a git variable). In an ideal world, I can also directly tell forge to use that account (username and host) to retrieve the secret from auth sources, etc. etc. If for some reason this secret is missing from auth-sources, forge can also query the user for it and save it in auth-sources instead of throwing errors. Now, this should not cause any loss of functionality because it does not change the global or local git usernames and variables. Those can be used as it is. In fact, you can even have a variable (let's say current-forge-global-account set to nil by default) that by default does not change anything, but if the user decides to can set this variable to ask forge to change to a different global user, or to ask forge to query for the user and credentials every time, or something else. This would make the user experience a lot better because:

1- The user does not need to worry about adding the confusing "^forge" to their secret, etc. That happens automatically by forge itself, and it can be fixed for all credentials.
2- The user can switch between different global accounts without editing repos or git variables etc.
3- The user can open forge topics from any directory using the current global account and if needed switch to a different account without cloning repos locally and defining git variables locally.
This is of the part where I currently do have some solutions with hacking auth-sources, but it's just too much hacking for something that can be a lot simpler if addressed from the forge side.

Now, with that in mind, I can address some of the things you mentioned:

(Alternatively, why not just use the Git variable?)

The assumption in my package is that you make calls from any directory (so no dependence on default-directory) and can explore any GitHub repo from within emacs. So essentially this is like opening the browser and looking at repos, issues, etc. but inside emacs buffers with emacs powers! Using git variables would not work because then the user has to call the commands in my package from the right directory and that does not make a lot of sense for the kind of workflow I am trying to support.

You should be able to do that using this basic idea with cl-defmethos

This is indeed something that looks interesting. If I find some time, I'll give it a try and see what I can do. But at the same time, think about whether it makes sense to do this by default in ghub or forge especially for switching between global accounts as I described above.

Ghub doesn't provide such a variable, but if one really wanted to bypass auth-source, then one could just use an override advice for ghub--token.

Yes, if this was just something I was doing in my config, I could do it. But I am trying to provide a package to users and I don't want to break things with forge. I think the cl-defmethod you suggested above would be a much cleaner solution.

Note however that ghub-request does support specifying the username, token, host and forge explicitly. It's just that Forge doesn't use that option.

The issue is exactly this. Of course, we can make a call to GitHub API and specify those variables (with or without ghub), but forge does not use this. Therefore, I cannot teach forge to change between global accounts (without storing variables in some local repository settings like git variables and saving secrets in auth-sources etc.) In general, forge's dependence on local settings whether it is magit-setup-buffer, or using ghub--token does not seem necessary to me (at least in concept, I'm not sure how tricky it is to change the current implementation and what issues you had to deal with to make forge to work with different hosts, ...). So far, I am extremely happy with the combination of my consult-gh package together with forge and I think the community would also like to see solutions like this, therefore I would like to try and provide this in my package. Currently, with just those hacks that I did, the two packages are working together just fine and that is already great; the only missing part is the ability to switch between global accounts. I do have more hacky solutions for that (by hacking auth-sources) which does work, but I don't think this is the right solution to provide in a package to the community and over time it would be difficult to maintain such hacky solutions anyway. Therefore, I figured I should ask you to see if you are interested in supporting the cause within forge especially because I think this would address some of the issues that users run into with forge in general as well.

You seem to conflate two distinct things:
How to store and retrieve the secret needed to identify ourselves. That's what ghub--token deals with.
How to determine who we are and what host we want to talk to. That's what ghub--username and ghub--host deal with.

I understand your point, but as I mentioned above, if you look at it from forge's perspectives, the two are not really different because there is no straightforward way to pass ghub--username and ghub--host directly to forge to switch between global accounts (again without local variables stored in repos, etc.) So as far as forge is concerned (and remember I am interested in forge for the nice interactive frontend to interact with topics, not just making calls to GitHub API), the two are not separate unless we hack the way forge does authentication.

Thanks for taking the time to respond in details again.