(TestPyPI) "ERROR: No matching distribution found for setuptools" if pyproject.toml is present in a very basic package

[normanius]

Environment

• pip version: 19.x, 20.x
• Python version: py>=3.6
• OS: any (preproduced on macOS, Win)

Description
As demonstrated in this minimal reproducing project, the presence of pyproject.toml breaks its installation later through pip via PyPI/TestPyPI.

I've tried several things, which didn't change my observations described here:

• Removing the --no-deps flag
• Adding/removing setuptools and wheels in setup.cfg as install_requires and setup_requires
• Use package pep517 to build the project: python -m pep517.build .

By now, I understand that pyproject.toml triggers build isolation, and that the sdist package somehow misses the wheels for wheel and setuptools to install those packages during isolated installation. Removing pyproject.toml from the project or installing the sdist (.tar.gz) simply uses the packages setuptools and wheel that python can find. Consequently, the installation works when using pip install ...... --no-build-isolation. But this disables build isolation.

I found a possibly related issue #5402, but I got the impression that this is not exactly the same situation, since I am not using the pip flag --no-index.

Expected behavior
Following the (still pretty scarce) material in the web, most notably PEP517/PEP518, I understood that the default choice for pyproject.toml is as follows.

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

Expected behavior:

• No error when installing from PyPI following the "default choices", as suggested in the PEPs and some tutorials
• A more readable error message that makes it easier for the beginner to adapt to the new paradigms

I think the build isolation is certainly a good thing for a healthy Python ecosystem. But for me as rookie package publisher, it cannot be that after 3 days reading about packaging and the PEP517/518 initiatives, I came only this far. :)

How to Reproduce

git clone https://github.com/normanius/pyproject-problem.git
cd pyproject-problem
./run.sh

Sources:

• run.sh
• setup.cfg
• setup.py
• pyproject.toml

Related question
How to bundle the package such that the additional --no-build-isolation flag is not required? I'd wish that a usual pip install <package_name> will work for my packages also in the pep517-style projects.

Output
Output of my script is found in this pastebin.

[uranusjr]

I think the problem here actually has little to do with PEP 517 and pyproject.toml, but simply that TestPyPI does not serve setuptools and returns 404 when you route index traffic to TestPyPI.

So essentially this is the same as #5402 in that pip is not “smart enough” when populating the isolated environment, and rely too much on the index being redily available. Your package should install fine if uploaded to PyPI, where setuptools is available.

[normanius]

As I constantly question my own expertise in this area, it never occurred to me that this might be due to a limitation of TestPyPI... :)

What's the proposition for those who verify the integrity of a new distribution release via TestPyPI? I thought TestPyPI should be used for release validation before flooding the official PyPI with immature releases.

Plus, I can imagine that there will be others running into similar problems. I assume there should something be done about it, when build isolation becomes the new standard.

[uranusjr]

Personally I feel the simplistic fix would be to have setuptools available on TestPyPI. But that proposal needs to be raised to setuptools maintainers. pip likely should be smarter when populating the build environment (i.e. use the seuptools installation available in the runtime environment instead of fetching again), but that’s a broader enhancement that needs more discussion.

If you need to test the installation right now, the easiest fix available without involving others would be to serve your own setuptools copy instead. Something like

pip wheel setuptools wheel -w ./wheels
pip install --find-links ./wheels --index-url https://test.pypi.org/simple ...

[normanius]

I can confirm that releasing directly to PyPI does not exhibit those problems. Thanks @uranusjr for pointing this out. In other words: my release has always been functional and I spent 1d to figure this out 😅

The workaround is useful and works.

Is removing the folder ./wheels enough to clean up?

[uranusjr]

Is removing the folder ./wheels enough to clean up?

Yup.

[gbdlin]

Personally I feel the simplistic fix would be to have setuptools available on TestPyPI

That will only work for projects requiring only setuptools. I think better option is just to use --extra-index-url or --find-links to point pip to additional locations from which build requirements can be fetched from.

[uranusjr]

Are there outstanding issues remaining here? I feel we have addressed the problem, and there’s nothing further actionable for pip.

[no-response]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[normanius]

@uranusjr I agree. I think pip cannot do much here. Let me know in case you know a better place to address this issue.

The transition to "new-style" build system specification is a bit bumpy for a common user like me. It's probably good if the failure was a bit more specific and some more resources were available.

For example, a note in the popular packaging tutorial could be helpful. Generally, the tutorial could be updated with a couple of notes and links about PEP 517. Where would you request such an improvement?

[normanius]

I informed the maintainers of setuptools about this issue.