feature: Automatically retrieve the highest available version of flet-build-template

[Creeper19472]

Duplicate Check

• I have searched the opened issues and there are no duplicates

Describe the requested feature

For some time now, Flet's behavior in finding and fetching build templates has been disastrous. While this disastrous situation could be avoided with human intervention, as we've seen, it's common for flet-build-template to lag behind the development version iterations. Whenever this happens, developers have to manually check the upstream code repository to see what's wrong and—if they want to build their applications using the latest development version—fork a repository and manually create the missing branches.

This is a disaster for both upstream and downstream developers. On the one hand, given the current situation, we cannot expect upstream developers to always remember to add branches corresponding to new versions; on the other hand, we cannot expect downstream developers to fork a repository and manually fix the problem every time.

Considering that flet-build-template hasn't been updated much in recent versions, I think it's quite possible that we can implement an automatic retrieval system that allows searching downwards when the default query branch doesn't exist, until the first usable branch is found.

Suggest a solution

This mechanism is triggered only when all of the following conditions are met:

1. The user did not explicitly specify in some way which branch of flet-build-template to use;
2. Flet failed to find a branch corresponding to the version number based on the default behavior.

If the above conditions are met, Flet will attempt to parse the names of all branches in the target repository and match those branches that conform to the naming pattern vX.Y.Z.

Flet will explicitly display a notification to remind developers to update the required branch when appropriate, but in this case, the branch with the latest version number will be used for the build.

Screenshots

No response

Additional details

No response

[FeodorFitsner]

we cannot expect upstream developers to always remember to add branches corresponding to new versions.

This is the purpose of CI. We need to add checks on CI level.

Considering that flet-build-template hasn't been updated much in recent versions...

That is not exactly true. Templates from previous versions has pinned flet package version in pubspec.yml, so it's not guaranteed it will work with more recent Python library. That will give your weird errors in runtime.

[Creeper19472]

That is not exactly true. Templates from previous versions has pinned flet package version in pubspec.yml, so it's not guaranteed it will work with more recent Python library. That will give your weird errors in runtime.

Consider this: even if an error occurs, the situation won't be worse than it is now—the only thing to watch out for is its impact on troubleshooting. But if there are enough clues (by showing clear warnings) to make people realize that the problem is likely to originate here, then I don't think there should be too much of a problem.

[FeodorFitsner]

A more elegant and right solution to this entire problem would be adding a simple git branch checkout from flet-build-template into "Build Flet Flutter package" job (or separate job) in ci.yml. Falling back to older templates is wrong and does not improve maintainability or troubleshooting.

[FeodorFitsner]

But the issue you brought here is valid. It's just we need a better solution.

[Creeper19472]

A more elegant and right solution to this entire problem would be adding a simple git branch checkout from flet-build-template into "Build Flet Flutter package" job (or separate job) in ci.yml. Falling back to older templates is wrong and does not improve maintainability or troubleshooting.

Using this approach, I suspect we'll need to automate the pinning process of flet package dependency as well, especially for the development version. This issue was primarily raised to address the problem of checkout speed of flet-build-template lagging behind the development version's update speed.

[FeodorFitsner]

Now we are talking! Yes, top-to-bottom pinning is the solution.

We need to pin flet Flutter package and release its pre-release version along with flet Python packages. From that page: "Later, when you release version 2.0.0, it takes precedence over all 2.0.0-XXX prereleases." - this is what we need.

Next, we should pin flet-build-template branches as well, so releasing Flet v0.82.3.devXXXX would have a corresponding 0.82.3.devXXXX branch in flet-build-template with flet: 0.82.3.devXXXX dependency in pubspec.yml. I think CI could ensure 0.82.3.devXXXX branch exists (pre-created manually with some fixes?) or create if it doesn't.

Another way to deal with "app" and "build" templates, I've just figured out, would be uploading them to GH release artifacts - all in one place (example).

[FeodorFitsner]

On a second thought, I like the idea of pulling "app" and "build" templates from releases as it would ease requirement to have Git to use flet build. What do you think?

[Creeper19472]

Good idea, if we can ensure every version has its corresponding artifact. I've done a quick research and found that cookiecutter can read from .zip files.

However, I'm wondering where we should upload these template files. We probably need a CI workflow across code repositories, but after making this change, we need to consider whether the difficulty of customizing the template will increase (because of the added steps of packaging and uploading)?

[FeodorFitsner]

It's great it could take a template from a zip!

We can archive the repo later, sure.

Storing build template in releases also gives us an ability to easily reupload it in case of "oh shit" situations.

[FeodorFitsner]

Do you want do come up with an updated plan for this improvement (all things we discussed) and then re-do PR?