builds proceed with zero configuration

[hroncok]

Hello, my understanding is that the build_meta:__legacy__ backend should behave like python setup.py ... calls.

However, I've realized that it proceeds fine without any setup.py / setup.cfg files:

$ mkdir empty
$ cd empty/
$ pip list
Package    Version
---------- -------
packaging  20.4
pip        20.2.2
pyparsing  2.4.7
setuptools 49.6.0   # also happens with 41.6.0 and probably anything in between
six        1.15.0
wheel      0.35.0
$ python
>>> from setuptools.build_meta import __legacy__
>>> __legacy__.build_wheel('.')
running bdist_wheel
running build
installing to build/bdist.linux-x86_64/wheel
running install
running install_egg_info
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'
Copying UNKNOWN.egg-info to build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0-py3.8.egg-info
running install_scripts
creating build/bdist.linux-x86_64/wheel/UNKNOWN-0.0.0.dist-info/WHEEL
creating '/home/churchyard/tmp/empty/tmpy86e5sx4/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
'UNKNOWN-0.0.0-py3-none-any.whl'
>>> ^D
[empty]$ ls
build  UNKNOWN-0.0.0-py3-none-any.whl  UNKNOWN.egg-info

This might be a problem in scripted environments. I would have expect an error here. Is this behavior deliberate or accidental?

[pganssle]

It should indeed work the same as any pyproject.toml. It's probably unfortunate that a project with a bare setup() call and no setup.cfg succeeds, but it's not specific to the legacy backend (which shouldn't be used anyway).

[uranusjr]

setup() without any arguments has “worked” for a very long time, so it’s sort of an unfortunate accident. Since it is good in basically no situations at all, would it be possible to block a setup() call if it receives zero arguments and setup.cfg does not exist? Preferrably I would want to apply this to both PEP 517 and legacy invocations, buit just changing the PEP 517 behaviour would be very helpful as well.

[pradyunsg]

Can the legacy backend enforce that a setup.py file must exist?

The language in PEP 517 seems to imply that the expectation is for the file to exist, in projects built with the legacy backend:

If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:__legacy__ backend).

[pradyunsg]

Moving further, can the non-legacy backend enforce that setup.py or setup.cfg exist?

A source tree without either can be basically... well, anything. It could be a user's home directory or whatever.

[henryiii]

What about when PEP 621 support lands? I'd hope eventually you could configure setuptools (for pure Python, at least) entirely from pyproject.toml. For __legacy__, sure. And if no configuration is present, that seems like it should always be an error, rather than producing UNKNOWN.

[pganssle]

I think the __legacy__ part of this is a red herring. We should probably raise an exception when no configuration information is present, regardless of the backend used. Once that's done, the rest of it won't matter.

Can the legacy backend enforce that a setup.py file must exist?

The language in PEP 517 seems to imply that the expectation is for the file to exist, in projects built with the legacy backend:

I think that language is at best ambiguous, but I read it as saying, "You can invoke setup.py if it's there, or use the legacy backend".

It seems like a pretty niche situation, though, for someone to be relying on PEP 517 behavior but unwilling to create a well-formed pyproject.toml file. Still, I'm inclined to just leave things as they are and simply start raising exceptions when required metadata like name are left unspecified.

[pradyunsg]

Right now, an empty directory is a valid setuptools package if you use the PEP 517 backends. Surely, we don't want that to be the case?

[pradyunsg]

Note that the medium-term plan very much is to enforce PEP 517 by default, and this issue is one of the blockers to doing that.

[pganssle]

Right now, an empty directory is a valid setuptools package if you use the PEP 517 backends. Surely, we don't want that to be the case?

I'm saying this is a problem to be solved regardless of the __legacy__ backend. If we get zero configuration (including in PEP 517 builds), we should raise an exception. I can't think of any situations where doing something else would be useful (except possibly when someone is using setup.py to invoke custom build commands but doesn't actually want to build packages, in which case.. uh... that is not a supported use case).. If we start raising exceptions instead of just populating the data with UNKNOWN, it will no longer be the case that an empty directory is a valid setuptools package.

It's not like we want a directory with just a pyproject.toml file specifying the build backend to be a valid setuptools package.

Note that the medium-term plan very much is to enforce PEP 517 by default, and this issue is one of the blockers to doing that.

Assuming we fix #2799 (which is basically this bug, but not scoped to __legacy__), is this still considered a blocker?

[pradyunsg]

Nope, that's good enough. :)