beeware / briefcase-macos-xcode-template Goto Github PK

Describe the bug

The stub binary used to start an app is an effective replacement for the python binary; however, it isn't a perfect replacements. multiprocessing in spawn mode will try to invoke sys.executable to spawn a child; it's also common to use subprocess or os.spawn to try and start sys.exectuable to run other Python code as a subprocess. However, the stub binary doesn't support this kind of execution.

Steps to reproduce

1. Generate a stub macOS app
2. Add a call to call multiprocessing.Process() and start it with .start()

The subprocess will call the parent process entry point, and fail.

Expected behavior

The function targeted by Process() should be invoked with the provided arguments.

Screenshots

No response

Environment

• Operating System: All macOS
• Python version: All
• Software versions:
  • Briefcase: 0.3.12

Logs

n/a

Additional context

See beeware/briefcase-macOS-app-template#7 for the original report on macOS; the fault is with the stub binary, so the fix needs to be on the Xcode template. Any fix here will be inherited by the app template.

One possible solution would be to add some logic to the stub binary to inspect to see if the parent process is "self"; if so, the execution of the app should be modified to behave as if it were a normal Python binary.

Any solution should also be ported to Linux (beeware/briefcase-linux-flatpak-template#10) and Windows (beeware/briefcase-windows-VisualStudio-template#8).

This project and the whole beeware ecosystem are great.

I think it would definitely benefit from a cmake-based template. Would that be something viable?

Describe the bug
Currently, retrieving the traceback from an unhandled Python exceptions and displayed it in an error dialog relies on sys._traceback being set. sys._traceback is set by the nslog pyhton script which is no longer required by briefcase since fixing beeware/briefcase#675. If a user chooses not to install it, any Python exceptions will generate the unhelpful error message Could not access sys._traceback.

To Reproduce
Steps to reproduce the behavior:

1. Create a briefcase project without the std-nslog dependency.
2. Trigger an unhandled exception.

Expected behavior
Show the actual traceback instead.

Environment:

• Operating System: macOS
• Python version: 3.7 to 3.10

Additional context
Ideally, we would use the CPython API to retrieve and format the traceback even when std-nslog is not installed.

Describe the bug
Now that Python is initialised with an isolated config, it seems to now longer read the LC_CTYPE environment variable which we set in the Info.plist. As a result, it is initialised with Ascii encoding instead of UTF-8.

To Reproduce
Steps to reproduce the behavior:

1. Create and build a default briefcase app with the newest template.
2. Try to print a non-ascii character to the console from the app.

Environment:

• Operating System: macOS
• Python version: 3.11
• Software versions:
  • Briefcase: 0.3.12.dev188+g4cac510

Additional context
We should probably tell Python to use UTF-8 using in the pre-config:
https://docs.python.org/3/c-api/init_config.html#c.PyPreConfig.utf8_mode

What is the problem or limitation you are having?

The stub app currently sets a PYTHONPATH that includes the app and app_packages paths, plus the stdlib.

These paths are all inside the application bundle, which is a code-signed location.

If a user wants to add additional files to the PYTHONPATH (e.g., if you were building a "Jupyter Notebook" app, and wanted the user to be able to access user-installed packages), you can't install that code into app or app_packages.

Describe the solution you'd like

The stub app should include an Application Support folder as part of the standard app path.

Following the guidance of this document, this should be something like:
~/Library/Application Support/com.example.myapp/user_packages

Describe alternatives you've considered

Don't allow user-installed packages.

Additional context

Looking in an actual application support folder, there's some variation between the use of Formal Name and bundle as the app-specific identifier - i.e., ~/Library/Application Support/My App/user_packages. Using the bundle ID seem least likely to cause collisions.

Once this feature lands, the app template will need to be updated with a new binary.

On iOS, it makes sense to redirect all stdout and stderr to NSLog because this output can otherwise not be captured. On macOS, there may be some circumstances in which stdout should not be redirected, for instance in case of a command line tool which is distributed as an app bundle.

Would it make sense to only redirect stderr to the NSLog? Or are there particular use cases where it would be valuable to have stdout printed to the logs? AFAIK, all Python errors and warnings are printed stderr anyways.

Describe the bug
The main.m program which initialises the Python runtime sets PYTHONHOME here:

This is does not work as intended. As documented in https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHOME, the home is suffixed with /lib/python3.11, resulting in the Python runtime believing that

Contents/Resources/support/python-stdlib/lib/python3.11

is the location of its stdlib.

In practice, this is not a problem because we later explicitly include the stdlib in the Python path:

This does mean however that the initially quoted lines currently are not useful at all.

To Reproduce

1. Build the Xcode project.
2. From the Python program, inspect ``.

Additional context
We could do either of the following:

1. Completely rely on the PYTHONPATH to contain the stdlib.
2. Set the stdlib dir correctly, if possible, and omit it the PYTHONPATH.
3. Change the location of the stdlib directory to Contents/Resources/support/lib/python3.11