Use absolute paths in requirements files

[mhsmith]

Fixes #813. I had to use absolute paths in the end, because the Flatpak build moves the requirements file a second time before using it.

In order to get this working with Flatpak, the following additional changes were needed:

• Add --filesystem=host to app_packages module briefcase-linux-flatpak-template#4, so local requirement paths are visible to the Flatpak build process.
• Fixed Flatpak's override of the support package install method, which was broken by If support_path is missing from briefcase.toml, don't download a support package #805. This wasn't caught by the tests because they tested the behavior of the overridden low-level method, but not whether it was actually called. So I changed the tests to call a higher-level method.

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

[freakboy3742]

Good catch on the flatpak support package refactoring problem. Add that one to the list of problems that would have been caught if we actually ran apps as part of CI (See #699).

One minor tweak regarding os.path vs pathlib which I've made on your behalf; and one larger problem with other valid inputs to requirements. I've reworked and extended the test cases to highlight the problem.

[freakboy3742]

General preference is to use the pathlib APIs rather than os.path. In this case, this has the added benefit that it resolves symbolic links at the same time.

[mhsmith]

I can't think of any benefit of resolving symbolic links here, but I can think of a potential problem. Consider the following sequence of events:

• The user adds a requirement path with a symlink, then runs briefcase update -d. A requirements.txt file is generated containing the symlink target path.
• The user changes the target of the symlink.
• The user runs briefcase build. The existing requirements.txt file is used, with the old symlink target.

The user's mental model is that their requirements list is passed directly to pip: the requirements file is just an implementation detail. So it's reasonable for them to assume that symlinks will be resolved by pip itself.

[freakboy3742]

That's a reasonable point... I defaulted to "resolving references is a good thing"; but thinking about it some more, I think you're right that we should preserve the symlink, and let the last tool to use the link do the resolution.

[freakboy3742]

This should be 813.misc.rst, not 816.misc.rst - tracking the bug that is closed, not the PR.

[mhsmith]

Thanks, I'll look over this tomorrow.

[freakboy3742]

👍 Nice work!

[codecov]

Codecov Report

Merging #816 (7d1b3c2) into main (f000a5f) will decrease coverage by 0.02%.
The diff coverage is 88.88%.

Impacted Files	Coverage Δ
src/briefcase/commands/create.py	99.33% <85.71%> (-0.33%)	⬇️
src/briefcase/platforms/linux/flatpak.py	100.00% <100.00%> (ø)
src/briefcase/console.py	100.00% <0.00%> (ø)
src/briefcase/integrations/subprocess.py	100.00% <0.00%> (ø)
src/briefcase/integrations/android_sdk.py	99.09% <0.00%> (ø)
src/briefcase/platforms/android/gradle.py	93.20% <0.00%> (+0.20%)	⬆️