In Clojure, Lein tool is used to generate template for various projects.
Lein project metadata (including project dependencies) are stored in
prject.clj (in root directory) file. Lein downloads dependencies in
classpath (~/.m2/repository). So here I am caching ~/.m2/repository path
for reusing cache in subsequent builds.
The default `STACK_ROOT` is `~/.stack` only on Unix-like operating systems. On Windows, the default is `%APPDATA%/stack` (usually `%HOME%\AppData\Roaming\stack`).
On Unix-like OSs, Stack stores GHC and other tools in a `programs` directory in the `STACK_ROOT`. On Windows, Stack stores those tools and MSYS2 in `%LOCALAPPDATA%\Programs\stack` (usually `%HOME%\AppData\Local\Programs\stack`).
* Fix bugs in example of how to use with pipenv
The current example of how to use `@actions/cache` with pipenv has two
problems:
1. The cached virtualenv that pipenv creates has `bin/python` as a symlink
into paths like `/opt/hostedtoolcache/Python/3.7.11` that explicitly
include the patch version of python. When the cache is restored onto a
machine running a slightly different version of python, e.g., when
GitHub upgrades its runners from python 3.7.10 to 3.7.11, then any
attempt to run python in the workflow mysteriously fails with errors
like `Failed to load paths: /bin/sh: 1: /home/runner/.local/share/virtualenvs/myrepo-sOIMCiTO/bin/python: not found`.
Therefore the patch version of python should be included in the cache
key.
2. `pipenv --install` has the unfortunate behaviour of not cleaning out
any pre-existing packages. That is, if the `Pipfile` first contains
dependencies on `foo` and `bar`, and then you remove `bar` from the
`Pipfile` and run `pipenv install` again, `bar` is still included in
the virtualenv.
This can cause false-positive test failures: when a dependency is
removed from the `Pipfile` but there is still code that relies on the
removed dependency, tests can still pass if the dependency comes from
the cache based on a previous revision of `Pipfile.lock`.
Therefore `restore-keys` should not be set.
This PR attempts to address both of these issues.
* Explain why setup-python is included in example
pip's documentation explicitly states to not use `import pip`:
> While it is implemented in Python, and so is available from your Python code via
> `import pip`, you must not use pip’s internal APIs in this way.
This example is in direct contradiction with the documentation's guidance and, thus, has
been removed.
Jan T. Sott