Correct the hard-coding of python 3.13.

[freakboy3742]

The location of the standard library includes the Python version; however, this version has been inadvertently hard-coded to 3.13. This PR makes the Python version dynamic based on a cookiecutter variable.

Fixes beeware/briefcase#2046.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[mhsmith]

Looks fine, but a couple of questions:

• Can we improve the CI tests to stop something like this from happening again?
• Should this be merged to the 0.3.20 branch as well?

[freakboy3742]

Yes, this should be backported to 0.3.20.

As for CI testing - I'm not sure I know how we would test it. The failure mode was entirely on hardware; simulators weren't affected, which is why it wasn't picked up by the existing CI.

The best I can think of would be grepping the generated code for a Python version... but that's only going to catch a specific version that leaks in, so it's not a very rigorous test.

[mhsmith]

The failure mode was entirely on hardware; simulators weren't affected

Why was that?

[freakboy3742]

It's an intersection of 2 factors.

Firstly, the bad version int the template didn't cause a fail during the build because "python3.13" is a valid directory name - it's just a directory that doesn't exist. As a result, none of the binary modules were copied out of the lib-dynload folder and converted into framework form.

The requirement that binaries are in framework form isn't a runtime requirement on the simulator. iOS will allow a binary library to be loaded anywhere that is a valid file system location, provided the binary is signed correctly. On the simulator, all signatures are ad-hoc; and the libraries are signed indirectly when the Python framework is signed, so the app runs fine.

But when the app runs on device, an actual signature on the binary is required - and so the app fails to load the library. If you look at the original error mode, the error was a "signature mismatch", not a failure to find a module (although that surfaces as a "module not found" because "a module that could be loaded could not be found".

This discrepancy would also be picked up by the release process - when you submit an app to the App Store, it detects (and rejects) the presence of a .dylib object that isn't in a Framework.

So - I guess we could add a test that replicates the app packaging step... that would catch an app that hasn't been correctly processed. I'm not sure the best place to put that test though... it seems excessive to put it into the build script itself, but that's the only place where we have easy access to the build. I guess we could post-process the IPA file that is produced by Xcode... but that would require adding the code to Briefcase to generate the IPA as part of the publish step. This isn't currently done because the IPA is broadly not useful as an artefact... but I guess this could be the impetus.