setuptools: [BUG] pyproject.toml: name, version not recognized (UNKNOWN 0.0.0)

For me it helped to update pip

python3 -m pip install pip -U

TLDR; On Ubuntu 22.04 (Jammy) ensure the environment variable DEB_PYTHON_INSTALL_LAYOUT=deb_system before installing a PEP621 compliant project with pip and setuptools.

This issue is occurring on Jammy because pip is unable to get an accurate list of system package directories to remove from its temporary build environment’s sys.path. As a result, when the temporary build env’s site/sitecustomize.py script runs /usr/lib/python3/dist-packages is left at the end of sys.path, before the overlay and normal paths are appended, thus placing it before those dirs in the search path. This means Jammy’s debian packaged setuptools (at version 59) is found and loaded ahead of whatever version the pyproject.toml requested. That version does not support PEP621 and is unable to extract name and version metadata, resulting in UNKNOWN-0.0.0.

This was not an issue on 20.04 (Focal) because the get_purelib and get_platlib logic inside pip/_internal/locations/__init__.py switched at runtime between using the older distutils and newer sysconfig modules for determining purelib and platlib paths. That choice is based on the value of sysconfig._PIP_USE_SYSCONFIG, which only defaults to False if the python version is less than 3.10. The older distuils knew how to deal with Debian’s install scheme layout, where the newer sysconfig doesn’t unless the env var DEB_PYTHON_INSTALL_LAYOUT is set to either deb or deb_system.

This means this is a distro configuration/packaging issue, but I’m posting this comment on a closed bug because this bug report comes up as the top result when googling for this issue.

I think this person had the same problem 😃 https://pypi.org/project/UNKNOWN/

Indeed, this is the problem. I’ve “fixed” it by removing the system setuptools,

sudo apt purge python3-setuptools

Now it all builds correctly.

This is a reproducer based on the issue previously reported in the pip tracker:

> docker run --rm -it debian:11 /bin/bash

apt update && apt install -y python3 python3-dev curl git
cd /tmp
curl -sSL https://bootstrap.pypa.io/get-pip.py -o get-pip.py
python3 get-pip.py --no-setuptools --no-wheel
python3 -m pip install -Uv setuptools==44.0.0
python3 -m pip list
# Package    Version
# ---------- -------
# pip        22.0.4
# setuptools 44.0.0
python3 -c 'import setuptools; print(setuptools.__path__, setuptools.__version__)'
# ['/usr/local/lib/python3.9/dist-packages/setuptools'] 44.0.0
git clone https://github.com/nschloe/setuptools-UNKNOWN-bug
cd setuptools-UNKNOWN-bug
pip install . -vv
# ...
# Successfully installed UNKNOWN-0.0.0
# ...

Note that when we update the root installation of setuptools, the project builds correctly, which indicates that the dist-packages folder is somehow leaking into the build environment:

python3 -m pip install -Uv setuptools==62.1.0
pip install . -vv
# ...
# Successfully installed foobar-1.2.3
# ...

My conclusion is that it is the same problem, and based on what @uranusjr just discussed, deadsnakes patches are either the same as upstream debian/ubuntu or not enough to workaround this issue.

I just changed back to a setup.py.

For mac users -

Turns out, there was an outdated setuptools installed in my mac too. It took me some but I finally found it and removed it -

$ sudo rm ./Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/site-packages/setuptools*

This was purportedly fixed toward the end of September 2022 in https://github.com/pypa/pip/pull/11466

Thank you very much for confirming @nschloe

Yup, that’s what this looks like. You’re almost certainly using a Debian-patched Python which behaves incorrectly with pip and how it handles build isolation.