add option to respect platform's cache directories #251
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…Rather than use a static path like
~/.cache/
(via--root
) or~/.shiv
(the default).The added shiv build option
--platform-root
will enable runtime determination of the platform- and executable-appropriate cache directory:If the archive is understood to be globally-installed on the platform, and a known system-wide cache (such as
/var/cache/
) is already populated or writable by the current user, then this will be used.If the platform is understood to feature a user-dedicated cache (such as
~/.cache/
) – or specifies one via environment variable (such asXDG_CACHE_HOME
) – then this will be used.Otherwise,
~/.shiv
will be used.And, in cases (1) and (2), the cache root directory will be named according to the name of the archive – not referencing the toolset which created it (namely shiv) – for example...
Linux:
Darwin / OS X:
Windows:
I'll note that I've followed the shiv issues on this and understand that this might not be of interest to pull – particularly now that an alternative root can be specified at build time via
--root
.However, it's my impression that this functionality enables a shiv-built executable to do a significantly better job meeting the installation platform's expectations, at least on the systems I'm targeting, (and as a bonus without additional build-time configurations). As such, this is the functionality I'd prefer, by a long shot; and, I'd guess there's a not-insignificant number out there who would appreciate this, as well. Adding this as an "opt-in" feature – only enabled by build flag – seems appropriate, to me.
Cheers.
See also: #141, #142.