`briefcase run` fails after `briefcase create` when using stub app templates

zhenzi0322 commented 3 months ago

Describe the bug

When running an app on macOS or Windows, briefcase run will fail if a build step hasn't been executed.

On Windows, the error manifests as:

SystemExit: stub: No module named stub

On macOS, it is

The application cannot be opened for an unexpected reason, error=Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x158e246f0 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed}}}

Steps to reproduce

$ briefcase new -Q app_name=foobar
$ cd foobar
$ briefcase create
$ briefcase run

Expected behavior

App should start without error. The run should imply the need for a build on the macOS/Windows app templates, but because the template and binary both exist, the need for a build isn't detected.

Screenshots

No response

Environment

Operating System: macOS, Windows
Python version: All
Software versions:
- Briefcase: 0.3.17+

Logs

Traceback (most recent call last):
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\runpy.py", line 183, in _run_module_as_main
  File "D:\obj\windows-release\37amd64_Release\msi_python\zip_amd64\runpy.py", line 136, in _get_module_details
runpy._Error: No module named stub

During handling of the above exception, another exception occurred:

SystemExit: stub: No module named stub

---------------------------------------------------------------------------
Application quit abnormally (Exit code -1)!
stub: No module named stub

Unable to start app helloworld.

Additional context

The briefcase dev is normal, but the briefcase run is abnormal.

If you invoke briefcase run on a clean project, the app works.

If you invoke briefcase build before invoking briefcase run, the app works.

This only affects the app targets; the Xcode/VisualStudio templates do the right thing, because they require an explicit compilation step to create the binary.

freakboy3742 commented 3 months ago

When reporting a bug, it's really important that you provide full reproduction instructions. You've given 3 commands - but haven't provided any details about the other inputs you've used (such as the name of your app), or the system where you're running (including operating system versions, briefcase versions, etc). The bug template asks for these details for reason - if you don't provide these details, it can be very difficult for us to diagnose the problem. I've updated your report to include some of the details you've omitted.

In this case, the problem is that the build step has been missed. A Windows app needs a build step to set some metadata on the binary. This should be picked up automatically, but it appears it isn't.

As a workaround, you can manually run:

briefcase build

This will only be needed on the initial build. Once the metadata has been set once, no additional builds will be required.

I believe the specific issue is caused because you did run briefcase create. If you invoke briefcase run without invoking briefcase create first, this triggers the create, which then causes a build to occur. However, if you invoke create, the template and the binary both exist, so Run assumes no build is required.

The same problem exists for both the macOS app and Windows app template, for the same reason - they're both stub apps that require additional modifications after the template is rolled out.

One fix would be to modify the app template so that the stub binary generated by the template is literally stub.exe; then the "build" step would be "rename stub.exe to .exe", which would be detected by a create/run sequence as an update that will be required on the first run, but not subsequent runs.

zhenzi0322 commented 3 months ago

Thank you

rmartin16 commented 2 months ago

I believe this is the same issue as https://github.com/beeware/briefcase/issues/807. Nonetheless, this should be resolved by https://github.com/beeware/briefcase/pull/1714 since running the build step would no longer be dependent on the presence of the app binary.

beeware / briefcase