Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move config directory (& state?) to XDG paths #144

Open
paravoid opened this issue Sep 27, 2020 · 3 comments
Open

Move config directory (& state?) to XDG paths #144

paravoid opened this issue Sep 27, 2020 · 3 comments
Labels
kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale.

Comments

@paravoid
Copy link
Contributor

(Thanks for writing gmailctl and releasing it as open source!)

The proliferation of dot files/directories in users' home directories, the poor portability of paths like ".app" as well as the mixing of config and state are problems that are being addressed by the (now ubiquitous) freedesktop.org XDG base directory specification. This specifies directories like ~/.config/gmailctl (and possibly ~/.local/share/token.json) on Linux systems, and equivalent paths on OS X & Windows, unless overriden by environment variables. It'd be great if gmailctl moved its paths to match the XDG specification.

The implementation should be easy enough, but there are multiple Go libraries implementing this as well¹:

(All but the last are used enough to exist as a Debian package, if that matters)

1: There is a certain irony in a proliferation of libraries trying to address a proliferation problem…

@paravoid paravoid changed the title Move config director (& state?) to XDG paths Move config directory (& state?) to XDG paths Sep 27, 2020
@mbrt
Copy link
Owner

mbrt commented Sep 29, 2020

I agree that this would be an improvement for new users.

The problem is the migration path for existing installations. I would avoid moving their files around, as many use symlinks or rely on the config directory to not change. Perhaps the only safe way to do this would be to always check if $HOME/.gmailctl is empty, and if so use the new path.

@mbrt mbrt added kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale. labels Sep 29, 2020
lgarron added a commit to lgarron/gmailctl that referenced this issue Mar 21, 2024
lgarron added a commit to lgarron/gmailctl that referenced this issue Mar 21, 2024
lgarron added a commit to lgarron/gmailctl that referenced this issue Mar 21, 2024
lgarron added a commit to lgarron/gmailctl that referenced this issue Mar 21, 2024
@lgarron
Copy link

lgarron commented Mar 21, 2024

Perhaps the only safe way to do this would be to always check if $HOME/.gmailctl is empty, and if so use the new path.

I've submitted a PR for this: #393

In theory it could be improved by using a library, but it's only a 4 additional lines of code to avoid the primary issue of requiring a folder directly in the home directory. Seeing as this issue has the most upvotes, I think it would be a welcome improvement over the existing behaviour!

lgarron added a commit to lgarron/gmailctl that referenced this issue Mar 21, 2024
@mbrt
Copy link
Owner

mbrt commented Mar 23, 2024

I'm inclined at this point to say that this is a nice to have but will probably not be implemented. The risk of breaking existing users, plus introducing a weird behavior by which in certain situations the old directory is considered and in others we get the standard behavior, for me are not worth the trouble.

This can also be easily solved by the end user by simply aliasing gmailctl:

alias gmailctl='gmailctl --config=$HOME/.config/gmailctl'

I'll keep this open for now as I want to take another look in case there's an easy and clear to understand solution I'm missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale.
Projects
None yet
Development

No branches or pull requests

3 participants