Snippet for automatic installation of `import` itself

[isotes]

It would be great to have a further alternative installation method: a snippet that uses a locally installed import script if available but also downloads and installs it if necessary. I would prefer to have the import script at a predefined location - probably in the cache itself - rather than as a global command. This would also solve name clashes such as #22.

It looks to me like finding out the cache location is the biggest part of this snippet, especially if OS-specific default locations for the cache folder are taken into account (https://github.com/importpw/import/issues/36#issuecomment-660370606). I.e., with support for XDG_CACHE_HOME, the following (not very pretty) one-liner works (at least in bash):

__i="${IMPORT_CACHE:-${XDG_CACHE_HOME:-$HOME/.cache}/import-cache}/import" && [ -r "$__i" ] || curl -sfLSo "$__i" --create-dirs https://import.pw && . "$__i" && unset __i

This provides the zero-configuration convenience of the curl + eval method without incurring the HTTP request overhead on each script invocation.

I assume some uname wrangling is necessary to take OS-specific default folders into account, which would require an even bigger snippet. However, for the provided convenience, I could live with a 10-liner.

This approach works also with different locations for the cache and the script, but I would prefer having one common directory. I would be happy to take a stab at a PR for the installation docs, but #36 should be decided first and its logic should be duplicated for this snippet.

Small side note: I would also propose changing the cache directory name from import-cache to importpw in order to have a clearer association with the project.

[TooTallNate]

There actually was previously a more verbose bootstrapping snippet included in the readme that tried to achieve the same advantage.

I came to the conclusion that having to copy+paste the snippet in every script was inconvenient (and also impractical, because for example the old snippet wasn't even taking into consideration the XDG_CACHE_HOME that we'd like to add, so prescribing a snippet like these prevents new features from being added).

Having a simple and memorizable one-liner to bootstrap is what I want to focus on. Since this is basically just a documentation change, feel free to open a PR and perhaps you can convince me otherwise, but like I mentioned I think it's difficult to get a snippet that will be 100% future-proof.

[isotes]

What I like most about this project is that it (almost) solves the problem of giving a bash script to someone else while still being able to use and build a library of bash functions. The one step missing from the scripts being fully self-contained is the automatic provision of the import script itself. And while the curl + eval approach solves that, an HTTP request on each run is a no-starter for me. On the other hand, having a more complicated snippet to add to each script is a trade-off I would happily accept. Especially because I already use a template for bash scripts that contains the all-important set -euo pipefail line and some other snippets I use often (finding out the script directory, a skeleton for command line processing, ...). So adding another snippet to this template would not make any difference for me.

I was not aware of the older snippet. I like the approach of looking in multiple directories (although the current form won't work on Windows with ':' as the separator). However, for me the key idea is to automatically cache the script itself.

Future-proof: certainly, no solution would be 100% future-proof, but as noted this snippet does not have to be compatible regarding the cache location. I prefer having it in the same place, but even if it is downloaded somewhere else, it would still work. It just would not reside in the cache.

I'll take a stab at a PR.