[FR] Default values for packages and py_modules

[abravalheri]

What's the problem this feature will solve?

The need for explicitly specifying packages and py_modules (together with package_dir) is often criticized as a pitfall of setuptools.

Describe the solution you'd like

Setuptools could rely on the existing metadata (name of the distribution) and the conventions of the ecosystem (namely the "flat layout", "src layout" or "single script layout") to fill the missing values.

For example, given name = my_package in setup.cfg (and the values for packages and py_modules are missing):

• if the directory my_package exists, then it should be used as top-level package ("flat layout")
• if the directory src exists, then it should be scanned for packages ("src layout")
• if the file my_package.py exists, then it is a single-module package.

I believe that it is possible to make this change backward compatible, by only trying to find default values if both packages and py_modules are not given (this circumstance would usually create a distribution without packages/modules).

Alternative Solutions

No response

Additional context

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

[jaraco]

I like the way you're thinking here - striving to reduce the amount of redundant information required to build a basic project.

I too have this goal and in #2329 (comment), I describe some ideas I've had recently about a zero-config project. I imagine a world where one could have nothing more than a module or package and declaration of an appropriate backend and that's sufficient to build an installable package.

In that world, the design above is problemmatic, because once the package discovery is dependent on the name, you can no longer infer the name from the packages discovered. And remember, the packages/modules are the essential contribution of the author. That is, the author must give the package a name for it to exist.

In that case, it makes sense for Setuptools to derive the name of the distribution from the name of the Python package that it supplies.

I'm thinking I'd like this package/module discovery to take a slightly different tack:

• by default discover all modules and packages present in src/ (if it exists) or ..
• if discovered in ., exclude all common modules/packages that are unlikely to be correct (tests, setup.py, docs, ...).
• allow for additional modules/packages to be excluded or included (e.g. if setup.py is really meant to be installed).

From there, if the discovery mechanism found exactly one module or package, use that as the default name for the distribution, unless specified.

WDYT?

[jaraco]

I'd go one step further to support namespace packages. If a (series of) namespace package(s) is (are) discovered and it contains exactly one package/module, then the inferred name should be both the namespace package(s) and the sole child.

[abravalheri]

Hi @jaraco, thank you very much for the comments.
I am fine with both approaches to be sincere, and would be happy to pursue this alternative you proposed.

There is one point that I feel should be discussed: PEP 621.
(I suppose that eventually the intention of setuptools is to support PEP 621, and one of my objectives of implementing this change first is to make it easy for the transition to PEP 621 in the future).

In PEP 621 the name parameter is supposed to be statically specified.

I have also seen other issues (#1580) discussing how some forms of auto discovery can be problematic. The advantage of matching name against the entries file system is that we can implement this change in a more controlled way, without the drawbacks and in a relatively safe/backward-compatible way.

[abravalheri]

Hi @jaraco, I implemented 2 PRs, one for the original proposal and one addressing your comments.

Please feel free to consider my comments about PEP 621 and close the PR you find less appropriate.