Directory with an empty pyproject.toml files is built into an sdist+wheel by setuptools 64

[pradyunsg]

setuptools version

setuptools==64.0.1

Python version

3.10.6

OS

RHEL 7

Additional environment information

No response

Description

A directory with an empty pyproject.toml files is built into an sdist+wheel by setuptools 64

Expected behavior

Setuptools should refuse to build a project that does not have a name and version.

How to Reproduce

• touch pyproject.toml
• tree
• cat pyproject.toml
• python -m build

Output

❯ touch pyproject.toml
❯ tree
.
└── pyproject.toml

0 directories, 1 file
❯ cat pyproject.toml
❯ python -m build
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools >= 40.8.0, wheel)
* Getting dependencies for sdist...
running egg_info
creating UNKNOWN.egg-info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
* Building sdist...
running sdist
running egg_info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
warning: sdist: standard file not found: should have one of README, README.rst, README.txt, README.md

running check
warning: check: missing required meta-data: name

creating UNKNOWN-0.0.0
creating UNKNOWN-0.0.0/UNKNOWN.egg-info
copying files to UNKNOWN-0.0.0...
copying pyproject.toml -> UNKNOWN-0.0.0
copying UNKNOWN.egg-info/PKG-INFO -> UNKNOWN-0.0.0/UNKNOWN.egg-info
copying UNKNOWN.egg-info/SOURCES.txt -> UNKNOWN-0.0.0/UNKNOWN.egg-info
copying UNKNOWN.egg-info/dependency_links.txt -> UNKNOWN-0.0.0/UNKNOWN.egg-info
copying UNKNOWN.egg-info/top_level.txt -> UNKNOWN-0.0.0/UNKNOWN.egg-info
Writing UNKNOWN-0.0.0/setup.cfg
Creating tar archive
removing 'UNKNOWN-0.0.0' (and everything under it)
* Building wheel from sdist
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools >= 40.8.0, wheel)
* Getting dependencies for wheel...
running egg_info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
* Installing packages in isolated environment... (wheel)
* Building wheel...
running bdist_wheel
running build
installing to build/bdist.linux-x86_64/wheel
running install
running install_egg_info
running egg_info
writing UNKNOWN.egg-info/PKG-INFO
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
writing top-level names to UNKNOWN.egg-info/top_level.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
Copying UNKNOWN.egg-info to build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0-py3.10.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0.dist-info/WHEEL
creating '/tmp/pgedam/dist/tmpmpmy7cyv/UNKNOWN-0.0.0-py3-none-any.whl' and adding 'build/bdist.linux-x86_64/wheel' to it
adding 'UNKNOWN-0.0.0.dist-info/METADATA'
adding 'UNKNOWN-0.0.0.dist-info/WHEEL'
adding 'UNKNOWN-0.0.0.dist-info/top_level.txt'
adding 'UNKNOWN-0.0.0.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
Successfully built UNKNOWN-0.0.0.tar.gz and UNKNOWN-0.0.0-py3-none-any.whl

[pradyunsg]

This is the same underlying problem as #2329, and my position is the same on this topic as #2329 (comment).

[pradyunsg]

I'll reiterate: Setuptools should not build such projects, and should error out instead in situations with no build configuration (whether there's a setup.py or not) -- requiring both a name and a version to be specified.

The current behaviour is confusing, frustrating to explain to users who hit it and setuptools already breaks test configurations for projects (pip's test suite is failing, since we have a test that no setup.py + a pyproject.toml file with no build configuration should fail to build/work with editable installs). Preserving backwards compatibility of borderline non-sensical behaviour that causes user confusion, while not holding other areas of setuptools to the same level of scrutiny is a bad idea IMO.

[jonathanwang375]

One temporary solution we found in the meantime was to set the setuptools version in the pyproject.toml file as 63.0.0

[jaraco]

Since our last discussion, I've encountered other use-cases where it's been valuable not to have to specify a name or a version for a package. I was troubleshooting a case where I needed to replicate a user's experience with how the package metadata was generated (dist-info vs. egg-info) and I needed a minimal setuptools project against which to test. The name and version of the generated package were irrelevant to the investigation. It was nice to be able to create a package and not have to supply arbitrary and irrelevant concerns, especially when those concerns are dealt with by higher-level abstractions.

Maybe you're right that Setuptools should have a "strict" mode or something similar, perhaps even enabled by default, where it doesn't supply default values.

Still, like I said in #2329 (and thanks for linking that discussion), I'd like to defer this work until after the distutils merge is complete, because the factors are complicated by backward compatibility that distutils supplies.

[pradyunsg]

I'll reiterate that, while being able to omit these fields is convenient for you, a Python Packaging expert who is deeply familiar with setuptools and its failure modes, it's absolutely not clear to anyone who is not deeply familiar with setuptools and a clear error message would be vastly more obvious and is a matter of two lines of text.

those concerns are dealt with by higher-level abstractions

They aren't, and I want to push back against this rationale, which you also used in the previous issue.

You need to either have a setup.py file or a pyproject.toml file. If either exists (or doesn't exist), pip will delegate to setuptools will happily build the project. Heck, if you don't have setuptools installed in an environment which has pip installed, it will delegate to setuptools which will build an empty directory. To that end, setuptools will package up any directory. That's... bad, and not worth the convinience of allowing experts to omit two lines while writing quick-and-dirty tests.

[pradyunsg]

Is there any chance that setuptools agrees to change this behaviour?

I would appreciate if I could get a clear answer to the above. It'll help me decide whether or not it's worth my time to spend energy on this papercut in Python.