Alias for Executing CLI Apps

[john0isaac]

What is the problem or limitation you are having?

To execute command line apps I have to write the name of folder that contains my main.py as is with underscores

Normally for CLI apps you'd have an enter script or alias to execute the main function.
for example:

[project.scripts]
markdown-checker = "markdown_checker:main"

then you'd execute it using markdown-checker not markdown_checker

Describe the solution you'd like

Add alias just like the project.scripts

Describe alternatives you've considered

I changed the names of everything to not use underscores but it seems that you are detecting this from the folder name and it wouldn't seem right for me to change the folder name to use dashes instead of underscores

Additional context

No response

[john0isaac]

I was able to use markdown-checker instead of the underscored folder name when I changed this line:
[tool.briefcase.app.markdown_checker] to [tool.briefcase.app.markdown-checker]

maybe add docs for that?

[freakboy3742]

If you're referring to using markdown-checker as the app name, rather than markdown_checker; I agree there might be a need for additional docs here. This name is referred to as a the "app name"; and it needs to be PEP 508 compliant. Both - and _ forms are PEP 508 compliant (and considered equivalent names), but they're converted automatically into underscore format to create the Python app modules (because you can't import markdown-checker). If it's not clear that this app name is the literal text that will be used on CLI aliases (the wizard help text definitely doesn't mention this), then we should clarify this in the docs.

As for the bigger feature suggestion: I agree that using the PEP 621 project metadata to define [project.scripts] and [project.gui-scripts] would be desirable, but those settings aren't entirely compatible with how Briefcase operates. PEP 621 assumes there's a single codebase to be installed, and then has a single top-level [project.scripts] setting to define all the entry points that are possible. Briefcase, however, can define multiple output artefacts from a single project - so you can generate multiple output binaries from a single codebase.

That said - we are on a broader push to use PEP 621 standard configurations wherever we can; maybe there is a way that we could use PEP 621 configurations in a way that is compatible with Briefcase. Off the top of my head, one approach might be to interpret a project.scripts definition as a console app of the same name (and [project.gui-scripts] as a GUI app). Individual apps could then define a [tool.briefcase.apps.my-app.scripts] to define multiple entry points that would then be exposed by the console app installer.

I'm not sure how this would map to gui-scripts, though, as there's a fairly close correspondence between the "bundle" and a single icon in the operating system GUI. We might have to enforce a "one GUI script entry point per app" limit.

At the very least, the one detail that PEP 621 [project.scripts] definitions have that is useful is the ability to define entry points. As it currently stands, Briefcase requires that an app called markdown_checker has a markdown_checker main module. That's not an especially onerous condition, but it would be nice if the entry point were configurable. The general entry point syntax that [project.scripts] defines would be nice to preserve, even if we don't use full PEP 621 syntax for the Briefcase feature.