What is the problem or limitation you are having?
Briefcase uses an assumption that an app will always be started using the app name as a module (i.e., the analog of python -m <app name>).
However, PEP 621 provides for entry point definitions - the ability to define what public entry points should be defined when a package is installed. This also allows for both GUI scripts and console scripts.
Briefcase should
Describe the solution you'd like
It should be possible to use a PEP 621 entry point definition for an app. The current Briefcase default behavior should be the equivalent of an explicit:
[project.gui-scripts]
my-app = "my_app"
(or an even more explicit)
[project.gui-scripts]
my-app = "my_app/__main__:main"
"Invoke the app name as a module" should be retained as a default behavior. However, if the user defines a PEP 621 entry point matching the app name, that would override the default behavior.
This would also supersede the console_app definition. If the app name is defined in [project.scripts], it would be assumed to be a console script. Defining the same app in both gui-scripts and scripts would be considered a configuration error. Defining console_app at all if an entry point is explicitly provided would also be a configuration error.
An app should also be able to define a scripts or gui-scripts key, defining the list of entry points that this app will expose. The default behaviour would effectively be the equivalent of:
[project.gui-scripts]
my-app = "my_app"
[tool.briefcase.app.my-app]
gui-scripts = ["my-app"]
As a first pass, this list should be limited to a single entry (and may always be limited to a single entry on some platforms - macOS, iOS and Android only allow a single GUI entry point in an app), with longer lists raising an error. However, in time, we may be able to accommodate multiple entry points in a single "app".
Describe alternatives you've considered
Status quo.
What is the problem or limitation you are having?
Briefcase uses an assumption that an app will always be started using the app name as a module (i.e., the analog of
python -m <app name>).However, PEP 621 provides for entry point definitions - the ability to define what public entry points should be defined when a package is installed. This also allows for both GUI scripts and console scripts.
Briefcase should
Describe the solution you'd like
It should be possible to use a PEP 621 entry point definition for an app. The current Briefcase default behavior should be the equivalent of an explicit:
(or an even more explicit)
"Invoke the app name as a module" should be retained as a default behavior. However, if the user defines a PEP 621 entry point matching the app name, that would override the default behavior.
This would also supersede the
console_appdefinition. If the app name is defined in[project.scripts], it would be assumed to be a console script. Defining the same app in bothgui-scriptsandscriptswould be considered a configuration error. Definingconsole_appat all if an entry point is explicitly provided would also be a configuration error.An app should also be able to define a
scriptsorgui-scriptskey, defining the list of entry points that this app will expose. The default behaviour would effectively be the equivalent of:As a first pass, this list should be limited to a single entry (and may always be limited to a single entry on some platforms - macOS, iOS and Android only allow a single GUI entry point in an app), with longer lists raising an error. However, in time, we may be able to accommodate multiple entry points in a single "app".
Describe alternatives you've considered
Status quo.