Wrong ._pth is written in Windows MSI when using an explicit support package that does not match the local python version

[wtfuzz]

The version number for the pythonXX._pth is written determined here:

https://github.com/beeware/briefcase/blob/8cedd42a235ff3365c486c3c014c16476f9932e2/src/briefcase/platforms/windows/msi.py#L108

This is using the local interpreter version, regardless of the specified support package version.

[freakboy3742]

Thanks for the report - but I'm not sure I understand the use case you're describing. The support package should (in normal usage) always match the current interpreter version - this is to ensure basic parity between dev and run modes.

How are you causing this error to manifest? The only way I can think that this would happen is if you're manually specifying a support package; if the support package doesn't match your environment version, there will be a conflict. Is that how you're causing this problem, or is there another way to trigger it?

[wtfuzz]

Yes, in this case I specified an explicit support package version in pyproject.toml to pin the production build at 3.10, but the local installed version on the CI build nodes was 3.9. The MSI was created and can be installed successfully, but the installed app had a python39._pth file and the app fails to start.

I've updated my local interpreters to 3.10 to fix this, but it's somewhat confusing as there's a way to specify a specific support package, but it silently breaks the final MSI.

[freakboy3742]

Thanks for confirming. The complication here is that we don't provide the windows support package, so we can't add metadata to the support package itself. I guess we could look for a glob, rather than a specific filename (or look for a glob of a different file that we know will exist).

I would suggest any discrepancy between the local interpreter and the support package should be raised as an error; otherwise, discrepancies between template version and support package version could cause problems.

[freakboy3742]

I believe this is no longer an issue, as we no longer use the .pth file to control app startup.