[FR] Add some warnings if the package has entry-points which don't appear to resolve anywhere

What's the problem this feature will solve?

It's easy to create an entry-point which doesn't actually resolve in the installed package

Describe the solution you'd like

Suppose you have a package with an entry-point:

# pyproject.toml
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[project]
name = "mypackage"
version = "0.0.1"

[project.scripts]
hello = "mypackage:hello_world"

source:

# mypackage/__init__.py
def helloworld():
	print("hello, world!!")

Can you spot the bug?

The build/packaging/install all works normally but the script will be unusable:

...
Successfully installed mypackage-0.0.1
$ hello
Traceback (most recent call last):
  File ".venv/bin/hello", line 5, in <module>
    from mypackage import hello_world
ImportError: cannot import name 'hello_world' from 'mypackage' (.venv/lib/python3.11/site-packages/mypackage/__init__.py)

It would be nice if the build backend would log a warning saying that mypackage:hello_world doesn't appear to exist, to catch these kind of issues at packaging time.

Alternative Solutions

No response

Additional context

• The wrapper script is auto-generated, so it's an area that is easy to miss in unit tests. You can have 100% test coverage and still publish a broken package this way.
• Also easy to do when the "script" target is in a subdirectory and this wasn't included in packaging (i.e. not found by automatic discovery patterns, or forgot to add explicitly in the toml e.g. packages = ["mypackage", "mypackage.subpackage"]
• Detecting whether the entry point target exists is very difficult (impossible?) in the most pathological cases (e.g. it could be dynamically generated by a module __getattr__). It doesn't have to catch all pathological cases to be useful, just logging a WARNING would be helpful most of the time. The code could reuse the existing AST parsing code which attempts to find a __version__ attribute in the source.

Code of Conduct

• I agree to follow the PSF Code of Conduct

Start by tracing how setuptools processes [project.scripts] entry points from pyproject.toml, then inspect the existing AST parsing code mentioned in the issue. Determine where a best-effort target check could run without rejecting dynamic cases. Done means unresolved targets produce a warning while valid or dynamically provided targets continue to build normally.