"pip check" influenced by Python package in current working directory

[The-Compiler]

Environment

• pip version: 19.2.3
• Python version: 3.8.2
• OS: Arch Linux

Description
When I'm inside the qutebrowser repository and run pip check with . in sys.path (e.g. via python3 -m pip), even with a totally unrelated virtual environment, pip complains about qutebrowser dependencies not being installed:

$ python3 -m venv /tmp/newenv

$ /tmp/newenv/bin/pip check
No broken requirements found.

$ /tmp/newenv/bin/python3 -m pip check
qutebrowser 1.10.1 requires attrs, which is not installed.
qutebrowser 1.10.1 requires jinja2, which is not installed.
qutebrowser 1.10.1 requires pygments, which is not installed.
qutebrowser 1.10.1 requires pypeg2, which is not installed.
qutebrowser 1.10.1 requires pyyaml, which is not installed.

Running pip with --isolated doesn't change anything about it either.

Unfortunately, I have not been able to reproduce with a new clean clone of the qutebrowser repository - before I go dig in further, I was wondering if someone had an idea of what could be going on.

Expected behavior

pip check shouldn't be affected by the current working directory, or by a Python package there which isn't installed.

[The-Compiler]

Oh, just after submitting the issue, I found out how pip freeze also thinks qutebrowser is installed, despite that not being the case:

$ /tmp/newenv/bin/pip freeze --all
pip==19.2.3
setuptools==41.2.0

$ /tmp/newenv/bin/python3 -m pip freeze --all
pip==19.2.3
qutebrowser==1.10.1
setuptools==41.2.0

[sbidoul]

@The-Compiler can you confirm you have a qutebrowser.egg-info directory in your current directory?
That would be the cause of the problem, and explain why it does not happen with a fresh clone of the qutebrowser repo.

[The-Compiler]

Thanks for the fast answer - I do indeed! So where is that coming from, and what's going on exactly?

[sbidoul]

where is that coming from

It's a metadata directory, and a byproduct of many setup.py commands (install, bdist, sdist etc).

what's going on exactly

Having that metadata directory in sys.path makes pip believe the package is installed.
And the current directory is introduced in sys.path via python -m, as you noted.

This is being discussed in #7731 and related PR. The solution is not entirely clear yet.

[sbidoul]

@The-Compiler do you mind if we close this as a duplicate of #7731?

[The-Compiler]

Sounds reasonable, thanks for the explanation!