Skip to content
This repository has been archived by the owner on Jan 13, 2024. It is now read-only.

Follow XDG cache directory standard by default #1225

Closed
rightaway opened this issue Jun 17, 2021 · 7 comments
Closed

Follow XDG cache directory standard by default #1225

rightaway opened this issue Jun 17, 2021 · 7 comments

Comments

@rightaway
Copy link

The cache directory by default should use ~/.cache/pkg according to the XDG Base Directory Specification rather than ~/.pkg-cache which doesn't follow any standard. Most applications today use this standard and pkg should do the same to be compliant and keep the home directory clean.

#222 from many years ago also requested it.

It would be great if this module followed the XDG Base Directory Specification. Instead of placing the cache directory in the home directory it should be placed in the OS specific appropriate directory. Getting the correct directory is easy with a module like env-paths. This, among other things, allows a user to specify a directory in which they want all applications to look for their user configurable setting files and keep their home directory clean.

@github-actions
Copy link

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

@github-actions github-actions bot added the Stale label Sep 16, 2021
@rightaway
Copy link
Author

What's the point of this?

@github-actions github-actions bot removed the Stale label Sep 17, 2021
@github-actions
Copy link

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

@gerardbosch
Copy link

gerardbosch commented Jan 14, 2022

I'd like to show my support to this change. A common consequence of not following such conventions, in this case the Freedesktop (aka XDG) basedir spec1, are messy backups.

As an example, my backup system works on $HOME and ignores the ~/.cache directory (among others). Applications not following the Freedesktop base directory spec, force users to add ad-hoc exclusions for their backup systems. Besides that, one of the pain points is actually realising that some new directory/cachedir needs to be excluded –what usually happens after the backup has been done, adding extra unnecessary MB/GB to your usually cloud storage 💸.

As this seems to be cached data that can be fetched again, it would be better placed under $XDG_CACHE_HOME/pkg || $HOME/.cache/pkg directory by default, to benefit from the above points and to keep a more structured, clean and predictable homedir.

Hope this helps 😃 Cheers!

Footnotes

  1. https://specifications.freedesktop.org/basedir-spec/latest/ar01s02.html and https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html: The $XDG_CACHE_HOME should be honored or when undefined fallback to $HOME/.cache/

@jesec
Copy link
Contributor

jesec commented Jan 28, 2022

Noted, but can't be implemented before the next major release.

@github-actions
Copy link

This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label

@github-actions github-actions bot added the Stale label Apr 28, 2022
@jesec jesec added no-stale and removed Stale labels Apr 28, 2022
@jesec jesec mentioned this issue Jun 14, 2022
@btsimonh
Copy link

btsimonh commented Jul 7, 2022

Notes on my experience of extracting stuff from a VFS for use as dependencies, pkg style:

On Windows, I use ProgramData// to cache pkg-like files from a virtual FS.
This works fine on most systems. It breaks down in two specific circumstances:
1/ multiple users. If the first ever launched app creates the folder, other users have read/write/create but NOT UPDATE rights. This then means that if the app is run by a different user, and needs to change a file, it will fail. The solution is to ensure that at folder create (from pkg), it is created with update rights for all users, so that cached application specific files can be updated by any user.
2/ Officious IT rules. In some corporate cases, ProgramData is not a valid executable location by default. e.g. I bring down ffmpeg, and it will not execute from this folder. The easy solution is to add a rule to allow files in folder to be executed. Note that .node and .dll files seem not to need extra rules to work.

I was using temp, and that also worked fine except on linux and OSX, where it got cleaned periodically (i.e. I lost my dependencies whilst the app was running!). The programData equivalents work fine on linux and osx now without issues.

For pkg, I would suggest something like .cache/pkg/appname/ as the root for a certain app, just to separate possibly conflicting data?

The use of a written standard like the one mentioned above seems a good solution, but we'd need a humanised description detailing where it would be on Windows & OSX.
BUT. in my case my data is application specific, not 'user specific' which is what the above spec defines. For MOST people, there would be no difference, and disk is cheap.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants