GitHub Actions Cache Pipenv Fails

Hi,

Thanks for creating pipenv, it is a great tool!

I have been using pipenv in GitHub Actions and every now and then I get a strange error that I don’t know how to resolve. It is likely related to caching the .venv but I’m not sure how.

This is the excerpt from the workflow file that caches:

runs-on: ubuntu-latest
strategy:
  matrix:
    python-version: [3.8, 3.9]
steps:
  - uses: actions/checkout@v2
  - name: set up python ${{ matrix.python-version }}
    uses: actions/setup-python@v2
    with:
      python-version: ${{ matrix.python-version }}
  - name: install pipenv
    run: |
      python -m pip install --upgrade pip
      pip install pipenv
  - name: cache pipenv
    id: cache-pipenv
    uses: actions/cache@v2
    with:
      path: api/.venv
      key: ${{ runner.os }}-${{ matrix.python-version }}-pipenv-${{ hashFiles('api/Pipfile.lock') }}
  - name: install dependencies
    working-directory: ./api
    if: steps.cache-pipenv.outputs.cache-hit != 'true'
    env:
      PIPENV_VENV_IN_PROJECT: 1
    run: |
      pipenv install --dev
  - name: run tests
    working-directory: ./api
    run: |
      pipenv run test

This usually works fine for a few weeks and then I get a mysterious error when running the command pipenv run test (which basically triggers pytest:

Traceback (most recent call last):
11
  File "/opt/hostedtoolcache/Python/3.9.1/x64/bin/pipenv", line 8, in <module>
12
    sys.exit(cli())
13
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 829, in __call__
14
    return self.main(*args, **kwargs)
15
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 782, in main
16
    rv = self.invoke(ctx)
17
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1259, in invoke
18
    return _process_result(sub_ctx.command.invoke(sub_ctx))
19
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 1066, in invoke
20
    return ctx.invoke(self.callback, **ctx.params)
21
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 610, in invoke
22
    return callback(*args, **kwargs)
23
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/decorators.py", line 73, in new_func
24
    return ctx.invoke(f, obj, *args, **kwargs)
25
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/vendor/click/core.py", line 610, in invoke
26
    return callback(*args, **kwargs)
27
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/cli/command.py", line 449, in run
28
    do_run(
29
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/core.py", line 2547, in do_run
30
    run_fn(*run_args, **run_kwargs)
31
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/site-packages/pipenv/core.py", line 2499, in do_run_posix
32
    os.execl(
33
  File "/opt/hostedtoolcache/Python/3.9.1/x64/lib/python3.9/os.py", line 542, in execl
34
    execv(file, args)
35
FileNotFoundError: [Errno 2] No such file or directory

I would expect that the command keeps working fine.

[manishlamichhanechemondis]

I would suggest to add a global ENV var as:

PIPENV_VENV_IN_PROJECT=enabled

This forces pipenv to create .venv folder inside the project root.

then you can use Cache like this:

  ```
  - name: Cache Dependencies
    uses: actions/cache@v2
    id: cache-dependencies
    with:
      path: ./.venv # since we know that .venv is gonna be created in the current working directory
      key: ${{ runner.os }}-pip-${{ hashFiles('**/Pipfile.lock') }}
      restore-keys: |
        ${{ runner.os }}-pipenv

  - name: Install requirements
    if: steps.cache-dependencies.outputs.cache-hit != 'true'
    run: |
      pipenv install --dev --verbose

[matteius]

@jshwi newer versions of pipenv have been released since your last comment.

Also I am closing this issue as the answer from @manishlamichhanechemondis makes sense and has the support of a number of people.