Setting PYTHONHOME when initialising Python does not work as intended

[samschott]

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

briefcase-macOS-Xcode-template/{{ cookiecutter.formal_name }}/{{ cookiecutter.class_name }}/main.m

Lines 53 to 56 in fdcbf96

	python_home = [NSString stringWithFormat:@"%@/support/python-stdlib", resourcePath, nil];
	NSLog(@"PythonHome: %@", python_home);
	wtmp_str = Py_DecodeLocale([python_home UTF8String], NULL);
	status = PyConfig_SetString(&config, &config.home, wtmp_str);

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:

briefcase-macOS-Xcode-template/{{ cookiecutter.formal_name }}/{{ cookiecutter.class_name }}/main.m

Lines 121 to 124 in fdcbf96

	path = [NSString stringWithFormat:@"%@/support/python-stdlib/lib-dynload", resourcePath, nil];
	NSLog(@"- %@", path);
	wtmp_str = Py_DecodeLocale([path UTF8String], NULL);
	status = PyWideStringList_Append(&config.module_search_paths, wtmp_str);

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

[freakboy3742]

Well that's... annoying. Can't argue with the logic, but it's going to require a bunch of changes to accomodate it - the support package will need to be updated to produce the "lib/python3.11" rather than "python-stlib" location. The good news is that the recent change to Briefcase version-based branching and support package version pinning means we can introduce this change without breaking anything.

I'd say option (3) is probably our best option; if nothing else, it would allow for other code to be added to the lib folder. In the interests of avoiding hideously deep directory structures, it might also be worth exploring whether the support subfolder is needed, or whether we could use lib as the support folder.

[samschott]

I agree, Contents/Resources/lib/python3.11 or equivalent paths on other platforms would work just as well.