Follow XDG cache directory standard by default

[rightaway]

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.

https://github.com/vercel/pkg/issues/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[bot]]

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

[rightaway]

What's the point of this?

[github-actions[bot]]

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]

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 spec[^1], 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 :money_with_wings:.

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 :smiley: Cheers!

[^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]

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

[github-actions[bot]]

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

[btsimonh]

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.