Closed rmartin16 closed 2 months ago
Briefcase normally achieves this by not updating an existing installation of requirements but by removing all installed requirements and installing everything again.
Chaquopy also does this.
The potential edge case here is that Briefcase's direct installations will do this "false eager" update on every run with a -r update; whereas Chaquopy/Android only does the update if the contents of the requirements have changed. If a transitive dependency that isn't explicitly mentioned in the requirements has an update, a Briefcase-installed update would install the update, but Chaquopy wouldn't.
The catch is how "requirements have changed" is detected. Unless Chaquopy detects a change in requirements, it won't do a "false eager" update. Is Chaquopy's mechanism based on a file hash, or a comparison of the literal requirements?
A file hash, so including a comment with a timestamp would be enough to make it run pip again.
Describe the bug
The use of
-r/--update-requirements
should force the build of a project to install the app's requirements. This is currently true for all output formats except Android Gradle. When a Gradle project is built, the step to install requirements only runs the first time an app is built or if therequirements.txt
file changes.Therefore, running
briefcase build android -r
is not guaranteed to update the requirements in the Gradle build unlessrequirements.txt
file generated from the app's requirements is different from the last time it ran.Steps to reproduce
briefcase build android
briefcase build android -r
and see requirements are not installed againExpected behavior
The app's requirements are installed whenever the
-r/--update-requirements
flag is used. As noted in https://github.com/beeware/briefcase/pull/1719#issuecomment-2039631356, any change to the content ofrequirements.txt
will trigger the requirements to be re-installed during the next Gradle build; so, simply adding a timestamp to the file would achieve this, for instance.Furthermore, this installation should effectively eagerly update the app's requirements and their requirements and so forth. While
pip
can be configured to do this with--upgrade-strategy=eager
, Briefcase normally achieves this by not updating an existing installation of requirements but by removing all installed requirements and installing everything again.Screenshots
No response
Environment
0.3.18.dev162+g9b284776
Logs
briefcase build android
- briefcase.2024_04_05-11_46_02.build.logbriefcase build android -r
- briefcase.2024_04_05-11_46_50.build.logAdditional context
No response