Running scripts with `/usr/bin/env` and `2021.11.5.post0` fails to find correct python

Issue description

This is another regression of the recent release. The problem is running scripts using a she-bang + /usr/bin/env python to reference python. For example:

#!/usr/bin/env python

import sys

print(sys.version)

Running this as executable with the recent stable version of pipenv yields what is expected:

> pipenv --version
pipenv, version 2021.5.29
> pipenv run ./test.py
3.7.9 (default, Nov 16 2020, 11:56:37)
[Clang 12.0.0 (clang-1200.0.32.21)]

With the new version, it keeps the “default” environment (here 2.7 on a mac)

> pipenv --version
pipenv, version 2021.11.5.post0
> pipenv run ./test.py
2.7.17 (default, Dec 23 2019, 21:25:34)
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.16)]

[danielpoonwj]

I think it might be because pipenv run does not add the virtual env to $PATH.

This was what I got running in a python:3.8-buster docker container.

2021.11.5.post0

$ pipenv run printenv
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

2021.5.29

$ pipenv run printenv
PATH=/root/.local/share/virtualenvs/app-4PlAip0Q/bin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Regardless, this definitely looks like a regression and is causing some issues for me too.

[wjmelements]

We are experiencing the same issue. Seems the PATH is broken for pipenv run.

Your deployment broke our CI. Since this breaking change made it into your release, I want to see integration tests verifying the PATH. @frostming