Repository navigation
Improved XDG basedir spec compliance #554
Description
Activity
Thank you! I definitely want to support the XDG basedir spec before we reach stable release. 👍
Reacted by MelvinI also noticed that the files within .config/gh aren't "config" (at least, not in the sense that I'd expect people to be able to version in dotfiles repo or anything). Both the oauth token in config.yml and the entire state.yml file should probably be saved in XDG_DATA_HOME. Should that just be noted here or as a separate issue? (It's all the same general concern, but I'd honestly expect them to be implemented as separate PRs. But also understand it's still early days for the project and having a hundred issues isn't helpful. 😸 )
I'm very pleased to see that adding support is a goal for a stable release!
I also noticed that the files within .config/gh aren't "config" (at least, not in the sense that I'd expect people to be able to version in dotfiles repo or anything).
This is a very important and often overlooked part of the entire value proposition of the XDG basedir spec. What resides in
$XDG_CONFIG_HOMEshould only be configuration files in the purest sense, and be ideally a human readable, plain text file format that is easily edited by hand and stable (in that, if I invoke gh, it won't modify the file unless explicitly asked).Apologies if I've come across a bit strong there, but there are a thousand and one programs that violate that and nullify half the point of the spec (see: Chromium and everything derived from it).
Reacted by Mislav Marohnić, James D, Edwin Kofler, Neurognostic and Daniel BayleyApologies if I've come across a bit strong there, but there a thousand and one programs that violate that and nullify half the point of the spec
@severen Your opinions about XDG certainly seem strongly held, but I value you arguing for them because that gives us useful pointers about what we should consider when we do implement it.
@jasonkarns I agree that our config file right now isn't really config. We might be able to avoid storing one's username, because we know your user handle as soon as we authenticate with the stored token, and we might be able to avoid storing the token in a file in the first place if we implement storing it in your OS's keyring.
In the future, though, GitHub CLI will probably have some actual configuration options, and we will store these under XDG_CONFIG_HOME, and I'm guessing that we can store "data" files (such as the date of the last lookup of the update notifier) under XDG_DATA_HOME.
Reacted by Severen Redwood, Oliver Ford, Edwin Kofler, Neurognostic, Alisson Bruno and Daniel BayleyReacted by Jason Karns, James D, Oliver Ford, Edwin Kofler, Neurognostic and Alisson BrunoReacted by Jason Karns- changed the title
[-]Does not respect XDG_CONFIG_HOME[/-][+]Improved XDG basedir spec compliance[/+]on Mar 6, 2020 I'd like to revisit this conversation, but I think that sets off a connected conversation about host-specific configuration.
It sounds like we should stop putting host-specific config into
hosts.ymlso thathosts.ymlcan be moved intoXDG_DATA_HOME.In general, I think the host/global config concept can be improved or at least better edified; that will make it easier to consider this issue.
I'm not sure I understand exactly what you are proposing to do with
hosts.yml, but I'm going to outline my general thoughts.In a future where we support the XDG basedir spec (I'm sorry @jasonkarns @severen that this didn't make it into our v1.0), I do not feel strongly about
hosts.ymlbeing moved to XDG_DATA_HOME. After all, most of whathosts.ymlholds is host-specific configuration, and as such I feel like it belongs to XDG_CONFIG_HOME.We can weigh the pros vs. cons of storing OAuth tokens in this file, or in DATA vs CONFIG directory, but I believe that ultimately we should move these tokens out of plain text files anyway: #449
Describe the bug
ghappears to conform to the XDG basedir spec by writing to~/.config/gh. However, it does not respectXDG_CONFIG_HOMEas it should.~/.configis the default value for XDG_CONFIG_HOME, but should only be used if XDG_CONFIG_HOME itself is unset. If it is set, it should be respected.Steps to reproduce the behavior
rm -rf ~/.config/gh(or rename)export XDG_CONFIG_HOME=$(mktemp -d)(configure a custom config-home)gh issue listrun a command to trigger authenticationls ~/.config/ghnote thatghwas re-created under~/.configinstead of the temp directoryls $XDG_CONFIG_HOMEnote that nothing was written toXDG_CONFIG_HOME; this is wheregh/config.ymlshould have been written.Expected vs actual behavior
Conformance to the XDG spec requires that the XDG_CONFIG_HOME variable be respected for where to write user configuration files.
ghis writing to~/.configbut not respecting XDG_CONFIG_HOME when it is set.