Pipfile adds incorrect entry for package with local identifier, possibly leading to bad residual dist-info in site-packages

[ipstech]

Issue description

Our internal package build system uses the following PEP 440 compliant (as far as I can tell) versioning scheme for local package builds:

major.minor.patch+local.########
1.0.1+local.5d8761t
5.2.0+local.99e45qw

When such a package is built and installed directly from a git repo, it installs correctly, and pipenv graph (as well as pip list) displays the correct version, however, the entry in the Pipfile lists the package entry as just the hash value:

[packages]
...
5d8761t = {path = "/local/path/to/project/repo"}
...

This breaks some pipenv commands, since the package is not listed by its actual name. It also seems like it might be related to some odd residual dist-info files that end up in the site-packages directory sometimes (possibly after running pipenv update):

~ompany.app.tools.cool_tool-1.2.0+local.a41e1e8.dist-info
(the "~" chops off the first character, and pipenv graph shows this file with a "-" instead of a tilde)

The properly installed version of the above package would look like this:

company.app.tools.cool_tool-1.2.0+local.a41e1e8.dist-info

Expected result

I would expect the package name logged in the Pipfile to be accurate to the actual name of the package.

Actual result

Described above.

Steps to replicate

Create a package where the version follows the scheme described above and try to install it via pipenv.

---

$ pipenv --support

Pipenv version: '2018.11.27.dev0'

Pipenv location: '/usr/local/lib/python2.7/site-packages/pipenv'

Python location: '/usr/local/opt/python@2/bin/python2.7'

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '16.7.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 16.7.0: Thu Jan 11 22:59:40 PST 2018; root:xnu-3789.73.8~1/RELEASE_X86_64',
 'python_full_version': '2.7.15',
 'python_version': '2.7',
 'sys_platform': 'darwin'}

Pipenv–specific environment variables:

• PIPENV_VENV_IN_PROJECT: 1

Debug–specific environment variables:

• SHELL: /usr/local/bin/bash
• EDITOR: nvim
• LANG: en_US.UTF-8

[ipstech]

I've experimented with the local identifier some more and have found some strange results:

setup.py name field: company.app.tools.cool_tool

setup.py version field: 1.0.0+local.1234567
PKG-INFO version: 1.0.0+local.1234567
Pipfile package name: 745d7b6 (some hash, seems to be unrelated to the package?)

setup.py version field: 1.0.0+local#1234567 (invalid version warning when building)
PKG-INFO version: 1.0.0+local-1234567
Pipfile package name: 745d7b6 (some hash, seems to be unrelated to the package?)

setup.py version field: 1.0.0+local-1234567
PKG-INFO version: 1.0.0+local.1234567 (normalization warning)
Pipfile package name: 745d7b6 (some hash, seems to be unrelated to the package?)

setup.py version field: 1.0.0+local1234567
PKG-INFO version: 1.0.0+local1234567
Pipfile package name: 745d7b6 (some hash, seems to be unrelated to the package?)

It also seems to randomly work sometimes, but all of my recent tests have failed when using a local identifier...

[ipstech]

I think I finally understand what is going on a little better:

• Installing a local package directly from a project repo correctly updates the Pipfile entry if it is a new package or already installed top level package
• Installing a local package directly from a project repo that is a dependency of an already installed package leads to a short hash instead of the name entry for the package (everything else about the installed package reports and works correctly).

However, because the name entry in the Pipfile is wrong, it leads to issues with uninstalling the local development version and changing back to a package that has been deployed via a pypi server. I think this also ties in to the strange residual "dist-info" files that seem to appear occasionally.

[frostming]

@ipstech From your conclusion, I wanna know the result of below commands.

1. Only install the local package from a project repo from a clean environment.
2. Install the local package together with the package depending on the former.
3. Try a normal version specifier such as 5.2.0.

I don't know what leads to the failure but the Pipfile entry is just correct when I install from a local repo.

[lpsinger]

It also seems like it might be related to some odd residual dist-info files that end up in the site-packages directory sometimes (possibly after running pipenv update):

ompany.app.tools.cool_tool-1.2.0+local.a41e1e8.dist-info
(the "" chops off the first character, and pipenv graph shows this file with a "-" instead of a tilde)

The properly installed version of the above package would look like this:

company.app.tools.cool_tool-1.2.0+local.a41e1e8.dist-info

That directory name looks like it is a temporary directory created by pip when it tries to uninstall or update a package. See pypa/pip#6327.