Reconsider a new explicit-package-bases setting

[siddharthab]

This issue is mostly requesting for one of the options mentioned in #1817 (comment).

We use a monorepo for our own internal use (nothing gets packaged and distributed), and so we don't really have a major objective reason to use regular packages over namespace packages. Something to note here is that our code organization might have deep nested directories with no .py files in the intermediate directories. All our tooling (black, isort, mypy, Bazel, Python toolchain itself) works with this setup except for ruff. Because everything almost works, new members are not in the habit of creating empty __init__.py files, which leads to some unexpected sharp edges in ruff that are not obvious to troubleshoot.

To help enforce regular packages over namespace packages, we could enable INP (implicit-namespace-packages) ruff linter, but it works only on .py files, and as mentioned above, we may have many intermediate directories with no .py files in them. This use case is also mentioned in mypy docs (screenshot in the comment linked above) as an example for when --explicit-package-bases is useful.

We are currently making do with adding entries to known-third-party, but it does add some friction.

[siddharthab]

Our issue could also be solved with using a setting that defines implicit namespace packages, rather than the current explicit list of namespace packages (option 2 in the mypy docs screenshot in the linked comment above).

A simple use case for reproduction:

Filesystem:

% tree
.
└── mypkg
    └── requests
        ├── __init__.py
        └── module.py

mypkg/requests/__init__.py:

# Some package initialization code.

mypkg/requests/module.py:

import requests
import urllib3

_ = requests
_ = urllib3

% isort --check mypkg/requests/module.py   # No issues.
% ruff --select=I001 mypkg/requests/module.py # Thinks 'requests' is a top-level first-party package.

[charliermarsh]

I think adding an explicit-package-bases could make sense.