Building asteroids with bdist_apps and setuptools>=61 gives error

[rdb]

Description

Encountering this error:

error: Multiple top-level packages discovered in a flat-layout: ['models', 'textures'].

To avoid accidental inclusion of unwanted files or directories,
setuptools will not proceed with this build.

If you are trying to create a single distribution with multiple packages
on purpose, you should not rely on automatic discovery.
Instead, consider the following options:

1. set up custom discovery (`find` directive with `include` or `exclude`)
2. use a `src-layout`
3. explicitly set `py_modules` or `packages` with a list of names

To find more information, look for "package discovery" on setuptools docs.

Steps to Reproduce

Run ..\..\built_x64\python\python.exe setup.py bdist_apps with setuptools>=61.0.0

Known Workaround

Add py_modules=[] to the list of parameters in setup().

Environment

• Operating system: Windows
• System architecture: amd64
• Panda3D version: 9508b04
• Installation method: source
• Python version (if using Python): 3.8
• Compiler (if using C++): MSVC 2022

[rdb]

This is due to pypa/setuptools#2887 and pypa/setuptools#2894 which introduce a mechanism to automatically populate py_modules/packages if they are absent in setup.py (which they are because we don't need them).

I have no idea why automatic discovery is taking place for custom commands, though. I think we have to set py_modules to an empty list, but the discovery is taking place before our custom command even gets to run. :-/

[rdb]

I see that py2app (which is a similar tool as ours) ran into the same issue: ronaldoussoren/py2app#414
In pypa/setuptools#3248 it was recommended to create a custom finalize_distribution_options entry point:
ronaldoussoren/py2app@55eb236
…but it feels very awkward. I am on the fence between that and just telling people to add py_modules=[] to their setup.py.

@abravalheri is there a more elegant way nowadays to disable auto-discovery in custom commands?

[abravalheri]

For a general package, if you are using setuptools but you don't want to setuptools to process any importable package or importable module, then you need to setup either packages or py_modules to prevent setuptools from running autodiscovery¹.
This can also be done in setup.cfg or pyproject.toml (it does not have to be done in setup.py).

If you are working on a plugin that the most common use case is to have "package/module"-less builds and to ditch completely regular setuptools-builds... then the procedure followed by py2app may make sense (there is no right or wrong really, it depends on how the tool influences the end-user workflow).

Footnotes

1. See PyPA glossary for exact definitions. ↩

[rdb]

@abravalheri We have a plug-in that adds a custom command (build_apps) to setuptools. This custom command does not need the package discovery mechanism. So, having to tell our users that they need to update their setup.py to add a dummy py_modules in order to be able to use our plug-in is a nuisance.

The py2app approach works, but is imperfect: it is not limited in scope to the use of our custom command. So, it hinders users who do want to use package discovery when not using our custom command.

If there is really no other way, we will just stick with the py2app approach, and tell users that they can't use package discovery and our plug-in at the same time in their project.

But really, why is automatic package discovery not limited in effect to the standard build and related commands?

[rdb]

Closing for now since we have a workaround. If upstream has a better solution for us then we can integrate it, until then we'll just have to put a note in the manual.