Open rpdelaney opened 5 years ago
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
?
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?
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.
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
: https://github.com/python/mypy/pull/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
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
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.
@joeyespo care to weigh in? I'm inclined to maintain backward compatibility, but there are other opinions.
I'm open to it. I need to think more about it before committing though. Will revisit soon.
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.
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.
I just finished a similar feature in one of my own projects. Respect XDG with built-in upgrade capability: https://github.com/alichtman/shallow-backup/commit/3189723c06f6e64799bca25eb707a650ca66a2d8
You're welcome to rip whatever from that commit you'd like to @rpdelaney.
Looks like there's already a PR for this in #292
Oh, sweet. Any idea if/when it'll get merged? @joeyespo
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
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.