He's here, probably a venv issue more than a pip freez issue:

$ python3 -m venv pip-freez
$ ls -lah pip-freez/share/python-wheels/ | grep pkg
-rw-r--r-- 1 julien julien 113K Aug 11 14:59 pkg_resources-0.0.0-py2.py3-none-any.whl

There's other wheels here, still don't know why this one is picked by pip freeze and not the others.

This doesn't occur for me on Windows, and as far as I'm aware it's not typical for venvs to have a "share" directory containing wheels. Could this be related to how your OS vendor has packaged python/pip? (Do Debian unbundle pip's dependencies?)

Looks like so, the Debian packaged ensurepip looks to have:

_PROJECTS = [
    "setuptools",
    "pip",
    "pkg_resources",
]

While the cpython 3.5 one have:

_PROJECTS = [
    ("setuptools", _SETUPTOOLS_VERSION),
    ("pip", _PIP_VERSION),
]

OK, so I guess you'll need to report this to Debian.

I'm reading: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1220988.html and I see:

• • When ensurepip is run inside of a venv, it copies all dependent wheels from
• /usr/share/python-wheels.

So I checked if pkg_resource is copied from /usr/share as said and yes:

$ dpkg -S /usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl
python-pip-whl: /usr/share/python-wheels/pkg_resources-0.0.0-py2.py3-none-any.whl

So I checked python-pip-whl which contains in its README.debian:

pip on Debian is a crazy mess due to upstream's vendorizing of several
packages, which violates both the DFSG and Debian Policy. To resolve this
conflict, we package up these dependencies as PEP 427 wheels, essentially zip
files containing importable pure-Python code and a metadata directory. These
wheels live in separate python--whl binary packages, and are installed
into /usr/share/python-wheels.

OK, but not sure why they've created a separate pkg_resources wheel, as normally pkg_resources is part of setuptools. Looks like in doing so, they forgot to special-case that package so it doesn't show up in pip freeze (as there's no way pip can satisfy that requirement in general).

Anyway, there's clearly no pip or virtualenv bug here, it's up to Debian to make sure their "crazy mess" is consistent ;-)

Nevertheless, thanks for reporting it - it's useful to us to know what the distros do, so we can advise others in similar situations to yours.

Issue Debian side: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871790

It doesn't look like there is anything for pip to do here, so I will close this issue, but please reach out if there is something pending.