Conform to XDG directory specification

[rpdelaney]

I find that configuration and state data is stored in $HOME/.grip/, including (but not limited to) in these files:

• ~/.grip/cache-*

Users who do not expect state data to be stored here may accidentally back it up and synchronize it across systems improperly. Configuration data are fine, but prefer storing state data somewhere in $XDG_DATA_HOME and configuration data to $XDG_CONFIG_HOME to conform to the freedesktop.org / XDG standard.

Reference: https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

$XDG_CONFIG_HOME defines the base directory relative to which user specific                                                                                                                                          
configuration files should be stored. If $XDG_CONFIG_HOME is either not set or                                                                                                                                       
empty, a default equal to $HOME/.config should be used.

$XDG_DATA_HOME defines the base directory relative to which user specific data                                                                                                                                       
files should be stored. If $XDG_DATA_HOME is either not set or empty, a default                                                                                                                                      
equal to $HOME/.local/share should be used.

To implement a painless migration for existing users, you can consider reading $XDG_CONFIG_HOME/grip/config.py first, then falling back to $HOME/.grip/. Likewise for cache data.

[denisfa]

Hey @rpdelaney! Just want to confirm something. Can't we consider grip to have partial XDG Base Dir Support? If I understood the docs correctly, you can do something like

GRIPHOME="${XDG_CONFIG_HOME:-~/.config}/grip"

Then,

cat <<EOF > ${GRIPHOME}/settings.py
CACHE_DIRECTORY = 'my-css'
EOF

Or even if the settings.py is empty. Is this enough? One improvement that I see is to make the CACHE_DIR be not relative to ${GRIPHOME}. If this could be an absolute path, I think It could be more flexible.

To implement a painless migration for existing users, you can consider reading $XDG_CONFIG_HOME/grip/config.py first, then falling back to $HOME/.grip/. Likewise for cache data.

Cache data should not be expected to be there. They are temp files after all. I am not sure if the CACHE_DIRECTORY is not actually data, since they have versions and stuff. I could be wrong about this, though. The name is not clear for me.

Also, out of curiosity, why do you split state data and configuration data? Can you show me the example from grip? Or do you mean state data as user specific data files?

[rpdelaney]

Hey, thanks for the comments.

GRIPHOME="${XDG_CONFIG_HOME:-~/.config}/grip"

Yes, work-arounds like this are possible. But that's a client side work-around, not conformity with the freedesktop.org spec. I move my dotfiles around a lot. Consequently, apps that don't support the spec force me to do stuff like this:

if [ -d "$XDG_CONFIG_HOME/gnupg/" ] ; then  
  export GNUPGHOME="$XDG_CONFIG_HOME/gnupg/"
else                                        
  echo "GNUPGHOME not found." >&2           
fi                                          

My shellrc is full of stuff like this. Your approach would work too, but it has the same problem: apps that support the spec don't force me to do that at all.

Also, they don't force me to fill up ~/.config with .gitignore files that look like this to make sure I don't commit session keys or worse:

*
!gpg.conf
!gpg-agent.conf
!.gitignore

...because the spec requires that such things be stored in a completely different directory. Since gpg doesn't conform to the spec, I have to use hacks like the one you described to help protect me from the disastrous consequences of committing a private key to source control.

Or just to get a shell open:

[ -f "$XDG_CONFIG_HOME"/tmux/tmux.conf ] && alias tmux='tmux -f ~/.config/tmux/tmux.conf'

Etc.

Maintaining all those hacks for the pile of cli tools I use that don't support the spec is overhead that interferes with getting work done using these tools that people are so kindly providing.

So the upshot of this is that yes, I can use tricks in the shell to emulate conformity to the spec, but that's extra work that would be obviated if tools like grip just conformed on their own without any manual intervention.

Cache data should not be expected to be there. They are temp files after all.

One of us is misunderstanding the other. I agree that cache data should not be expected to be there -- nevertheless, it is there. That's why I'm raising this issue.

Also, out of curiosity, why do you split state data and configuration data?

Perhaps I'm misusing the term "state", but I don't want to win support for a particular interpretation of when we should decide to use the word "state". The point is that user configuration data (excluding authentication credentials) can be safely stored in $XDG_CONFIG_HOME. Most everything else can't be, afaik.

Can you show me the example from grip?

The cache data you mentioned. Or do you mean you would like a tarball of what I found?

[denisfa]

My shellrc is full of stuff like this. Your approach would work too, but it has the same problem: apps that support the spec don't force me to do that at all.

I fully understand this. I have myself a lot of env variables to deal with this.

The cache data you mentioned.

Just to be sure about this, when you run grip you get the following files:

$ ls -lR ~/.grip
/home/denisfa/.grip:
total 3.5K
drwxr-xr-x 2 denisfa denisfa 3.5K Feb  5 17:22 cache-4.5.2

/home/denisfa/.grip/cache-4.5.2:
total 592K
-rw-r--r-- 1 denisfa denisfa 117K Feb  5 17:22 frameworks-a3b8a10d4a9e37a78f033ef4a4f525f5.css
-rw-r--r-- 1 denisfa denisfa 382K Feb  5 17:22 github-a842d1324eb4ab086590be512b951c4c.css
-rw-r--r-- 1 denisfa denisfa  86K Feb  5 17:22 site-bdd55e67f0ed3e8974c7c941589e8c6a.css

The cache-4.5.2 you consider to be really cache files. We would have something like this:

Old Path	Var Path	New XDG Path
~/.grip/settings.py	${GRIPHOME}/settings.py	${XDG_CONFIG_HOME:-~/.config}/grip/settings.py
~/.grip/cache-*	${GRIPHOME}/cache-*	${XDG_CACHE_HOME:-~/.cache}/grip/cache-*

I might suggest for the next version to just include the XDG path, warning users to do the migration themselves. We may not need the GRIPHOME anymore, but I think we should keep for legacy reasons.

Hi @joeyespo! Could provide a input here? This is a simple change, so I could submit a MR soon. Just want to be sure the dev sees this with good eyes.

[rpdelaney]

I'm not sure it's necessary to force people to migrate. You can just implement the spec and then fall back to old behavior. See this PR for mypy: python/mypy#6304

Edit: It would be a drawback to lose support for $GRIPHOME and it shouldn't be necessary to lose that to implement the xdg spec

[rpdelaney]

It looks like DEFAULT_GRIPHOME = ~/.grip is set in defaults.py. If you are OK with it I can probably get a PR together that moves that to $XDG_CONFIG_HOME/grip but falls back if not found, like with the PR above

Moving the cache, I don't see how to do that yet

[denisfa]

If you are OK with it I can probably get a PR together that moves that to $XDG_CONFIG_HOME/grip but falls back if not found, like with the PR above

Sure! No problem! The important thing is to get rid of ~/.grip.

I'm not sure it's necessary to force people to migrate. You can just implement the spec and then fall back to old behavior. See this PR for mypy: python/mypy#6304

Here is the thing. I think that since we are using a single config file settings.py, and the other files are cache, we could try to move straight to the spec. On some projects, the idea behind supporting legacy is to not break old installs (maybe giving users a time window too, but this is less relevant than the first) and be "nicer" to new ones. You would also need to set a future task with something like "remember removing legacy code after X months/versions". No reason to keep multiple locations available after some time.

Edit: It would be a drawback to lose support for $GRIPHOME and it shouldn't be necessary to lose that to implement the xdg spec

Here you need to be somewhat carefully. You can support the XDG with this like I did on my comment. But you would also change the expected behaviour if you allow this and change cache-* to $XDG_CACHE_HOME/grip. I also would like to know if someone is using this for something else other than supporting the XDG (or simply getting rid of ~/.grip).

Anyways, do as you wish. I really would like to help you more, but I am more busy now than I expected.

[rpdelaney]

@joeyespo care to weigh in? I'm inclined to maintain backward compatibility, but there are other opinions.

[joeyespo]

I'm open to it. I need to think more about it before committing though. Will revisit soon.

[alichtman]

I'd be in favor of maintaining backwards compatibility, and I do think following the XDG spec is important.

The important thing is to get rid of ~/.grip.

Agreed.

[rpdelaney]

I'm still interested in this and happy to put a PR together. I would like to get some sort of green light from @joeyespo first though, to ensure that it would have a decent chance of being accepted.

[alichtman]

I just finished a similar feature in one of my own projects. Respect XDG with built-in upgrade capability: alichtman/shallow-backup@3189723

You're welcome to rip whatever from that commit you'd like to @rpdelaney.

[rpdelaney]

Looks like there's already a PR for this in #292

[alichtman]

Oh, sweet. Any idea if/when it'll get merged? @joeyespo