Restore support for symlinked Pipfiles creating venvs based on their symlink location, rather than dereferenced location

[jaydub]

So Debian Buster and Ubuntu Focal ship an old version of pipenv as system packages that pre-dates the resolution of #3842, and in that version, if you symlink a Pipfile from another location, pipenv considers the venv it will create as being based in the symlink's directory. In later versions, everything is dereference to the original location of the Pipfile, eg:

Expected result

cd bar
ln -s foo/Pipfile 
pipenv --venv
/home/jwm/.local/share/virtualenvs/bar-pAtHhAsH

Actual result

cd bar
ln -s foo/Pipfile 
pipenv --venv
/home/jwm/.local/share/virtualenvs/foo-hAsHpAtH

Focal/Buster version of pipenv is 11.9.0, while I'm running 2020.08.13 on an Ubuntu Bionic desktop, for the record, though it's quite obvious the project.py _normalized function patch is what caused the change in behaviour.

I have a crude fix that involves identifying the last item of the path as 'Pipfile', and in that case only applying resolve() to the parent, but give the existence of #4115 I suspect I need to do more things to make it well behaved, assuming this is a desired behaviour.

My use case is providing a Pipfile in one repository that allows a set of people to set up an environment containing the openstack tool set, so they can use scripts in that repo, but also invoke a bash script that sets up an authentication token for Terraform/Ansible etc to use. Symlinking it out of the repo directory into a shared base path means pipenv shell works from where ever they happen to be when they need it.

[matteius]

@jaydub To help traige, can you confirm if this behavior you describe of symlink resolution of the Pipfile is the same in latest version pipenv==2022.1.8 as well?

[jaydub]

Can confirm; 2022.1.8 exhibits the same behaviour.