Using the existing example, cargo install will error out after restoring a cache:
```
cargo install cargo-tarpaulin
Updating crates.io index
error: binary `cargo-tarpaulin` already exists in destination
Add --force to overwrite
Error: Process completed with exit code 101.
```
`--force` is undesirable because it will recompile the binary. Cargo is scared of the existing binary because it doesn't have enough information about it. Including `~/.cargo/.crates.toml` coaxes it into being okay with the situation.
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
Tommy G
Jan T. Sott
Bassem Dghaidi
Oleg A.
todgru
Tommy G
Michael Vorburger ⛑️
Michael Vorburger ⛑️
David Bernard
Josh Soref
Tanuj Kumar Mishra
uhooi
SIGUI Kessé Emmanuel
A. Pascual
Deepak Dahiya
ysato
Shivam Arora
Mike Pilgrem
Leandro Ostera
Tim Perry
Vipul
Ashwin Sangem
Peter Mescalchin
Yuichi Yogo
Malo Bourgon
Hiroki Noda
Jheyson Saavedra
Joachim Breitner
Manuel Roth
andrewdotn
Alex Tokarev
Daniel Kuschny
kalin
Wojtek Mach