Move logic to determine support revision from templates #1943
Conversation
|
@freakboy3742, explicitly tagging since I normally open draft PRs that aren't ready for review; is this a change you support? I can probably finish rolling this out tomorrow if so. |
|
@rmartin16 I see the direction your heading here, and I think I understand the motivation, but I'm not 100% on board. I'm not fundamentally against it - I'm trying to get the consequences straight in my head. Some of the following will be me thinking out loud. What I'm trying to wrap my head around comes down understanding where Briefcase's responsibility ends, and the template responsibility starts. While bumping a support revision does require multiple PRs, I don't fundamentally see that as a problem. Yes, it's more work, but it's fairly straightforward work, and I think there is something to be said for explicit per-template CI verifying each change is current. I agree that at the moment, there's a weird split of responsibilities around the support package - the base URL for the support package is defined in Briefcase, but the revision is defined in the template, with both being overridable on a per-project basis in Moving the URL definition the other way would have the additional benefit that generating a template in support of an alternative support package would be much more plausible. For example, you recently made the suggestion about switching to the Standalone version of the Windows and macOS support packages. If the base URL was defined in the template, that would make it possible for an end-user to maintain a Standalone set of templates without requiring per-project configuration. That said - I guess the change you've proposed here actually makes both possible. The default is computed in Briefcase, and it's encoded in the template when the template is generated - but a custom template could define its own logic for computing the desired support revision. I guess, if anything, my argument would be that this PR doesn't take the suggested change to its logical conclusion. If we're going to do this for the support revision, we should also do it for the support URL, and probably also for the stub binary revision and URL. In addition, if there's any variable that we are using to compute the URL or revision (such as target architecture), that variable should also be passed to the template. That way, we keep testable defaults in a single source of truth (Briefcase itself); but everything that Briefcase is doing could be replicated by a third-party template, should there be a need to do so. Doing this likely means more changes to how the support package URL and stub binary URL are computed, but I think the end state will be more consistent. As a broader topic; it's worth keeping in mind how this sort of change interacts with this sort of landing sequence. In the case of that PR, we're bumping the support revision on macOS templates, and bumping the template epoch, which has complicated the landing sequence. I don't think the changes you've suggested here would change anything - but if we're able to make changes that would simplify things, that's definitely something we should consider. |
|
nooo, not my beautiful scope 💥 💥 💥 🥹 😉 Makes sense, though; I'll see what this might take. |
This comment was marked as spam.
This comment was marked as spam.
High-level design
New output format template context fields
Currently assumed paths
Structure of
|
|
Looking at how this might work for the support package URL, there's a lot of existing parameterization... However, most of the information is not expected to change; or, at least, if the information changes (such as the Python version), then the user is expected to re-rollout the output format template. Therefore, it should be safe to simply derive these values at the time the template is rolled out and hardcode them in For instance, if we consider BeeWare's first-party support packages, the URL is: f"https://briefcase-support.s3.amazonaws.com/python/{self.python_version_tag}/{self.platform}/{self.support_package_filename(support_revision)}"Here, The support revision is special, though; it can currently change without expecting the user to re-rollout the whole template. Because of this, I am thinking of templating the URL in For instance, it could look like this: [support]
package_url = "https://briefcase-support.s3.amazonaws.com/python/3.12/macOS/Python-3.10-macOS-support.b{package_revision}.tar.gz"
package_revision = "2"Then, when Briefcase goes to install or update the support package, it would just call support_url = package_url.format(package_revision=package_revision)This could even be extended to allow templating other values in the future. For instance, it will probably be necessary to incorporate the concept of a support package "release" for Standalone Python: [support]
package_url = "https://github.com/indygreg/python-build-standalone/releases/download/{package_release}/cpython-{package_revision}-x86-64-unknown-linux-gnu-install_only_stripped.tar.gz"
package_revision = "3.10.14+20240726"
package_release = "20240726"This is kinda makes me want to just call Anyway, some initial thoughts....feedback welcome as I get in to the implementation. |
Agreed on these as general principles.
...
Do we maybe want to call these
So - a template overriding these is definitely an edge case. It would mean you are (for example) building macOS app bundle whose structure is fundamentally different to the default app template (say, pushing the .app folder down into a subfolder or similar). If we're being completely consistent, then I guess that should be exposed to
I can see how this might help with organisation and keeping keys shorter; my only question is how these new tables interact with the existing configuration. What's the plan for backwards compatibility? We have historical usage of
We need to be careful about how we choose the fields that are "meta-parameterised" in this way, and how we document the feature; but I think it potentially makes sense for some of these configuration items to be explicitly "parameterised", at least to some extent. A (possibly unintended, possibly beneficial?) side effect of this is that |
Since I was planning to introduce a new
Right; organization is my primary impetus for this since putting everything under
Yeah; I was basically planning to set a new template epoch for most of the output formats. As for uses of Also, on a related note, have you thought about how the template epoch will work once we transition to calendar versioning? Seems like it'll be a bit harder to know what the epoch should be... |
👍 . In which case, naming and structural changes are essentially moot, as any template epoch can essentially adopt whatever format it wants.
Is there any reason that calver wouldn't work? One of the nice things about effects of calver is that YY.MM.DD version numbers are both logically sortable and evaluate as "newer" than 0.3, 1.2, etc. And, for that matter, make more sense when read - you've essentially got a value in the template that says "This was updated in August of 2024". It's no harder than knowing that 0.3.15 is the current template epoch for Android, except you also have a date to work with. |
Oh, not that it wouldn't work mechanically. Just, at dev time, it seems to present a procedural conundrum. Mostly, how would I know, at dev time, what the epoch should be? I feel like this would require either a set release schedule (like pip or pillow, for instance) or a process to adjust the epoch when cutting the release. I could be missing something....but I was thinking about and figured I'd bring it up. |
I mean... yes... but that's true today as well. How does a new template developer know that their Android template is in the 0.3.15 epoch - other than the template they forked was 0.3.15? And how do they know that their template needs to be updated, other than the error message when the epoch is bumped tells them that the template is no longer epoch-appropriate? Calver doesn't change anything - it just changes the number. |
|
I don't think I'm explaining this very well; let me elaborate. I'm actually talking about us, the developers of Briefcase and its first-party templates. To play out a scenario, let the current version of Briefcase be Since the epoch is tied to the versions of Briefcase, in the pre-calver world, I would simply extrapolate the current version of Briefcase to the next one; so, Hopefully my thought process makes more sense now....or I'm just missing something altogether. |
|
Oh! Now I see what you're saying! 🤦 Good question. I don't know. 😀 Moving to a simple integer version would be one option; another would be to use the same version but interpret it as "version must be >", rather than >=. Neither of those are very appealing, though... |
Proposal
pyproject.tomlchangesWiP Changes
PR Checklist: