Create new project with Positron template (Django or Static)

[Cheukting]

What is the problem or limitation you are having?

Right now creating the Positron app is very hands-on, need to start with the Toga template and then paste the example

Describe the solution you'd like

Adding options when calling briefcase new to use the Django Positron or Static Positron template

Describe alternatives you've considered

Not yet, please let me know if you do

Additional context

No response

[freakboy3742]

I definitely acknowledge "Generate a Positron app" as a use case; while I'm not personally a huge fan of "web interface as app GUI" as an approach, I can't deny it's both popular, and an easy way to get into app development (for those that already have web skills).

However, I have a some concerns about this pair of PRs as an approach.

My first concern is the overlap with #392. Introducing this feature has required modifying both Briefcase and the briefcase template; ideally, we'd only need to change the template; and, if the questions were being generated from the template, any third party could manage their own Briefcase template without needing to have changes to a static list in Briefcase itself.

My second concern is the complexity of the bootstrap. The template is now injecting a non-trivial amount of code - and web server code at that. This is a potential attack surface for the app; if someone were to identify a vulnerability in this bootstrap code, every Positron app would have that vulnerability - and we'd have no good way to effectively communicate a mitigation or fix. The existing GUI frameworks don't really have this surface because they're the minimal "display a window" app.

On that basis, I'd argue that positron should be a standalone Python package on PyPI (although the positron name is already taken on PyPI...), defining a subclass of toga.App. From Briefcase's perspective, Positron then becomes a "normal" GUI framework - the template only contributes the "create a bare bones window" code, where the user content for the window is configured by pointing at a Django project or static web code. If a vulnerability was found, we could publish a new version of the Positron package, and all users would get the fix.

My final concern is almost a synthesis of the first two. Ideally, BeeWare and Briefcase don't want to be in the game of picking "winners" when it comes to GUI frameworks, and being responsible maintaining support for every possible GUI framework. The maintenance burden of supporting Toga, PyGame, PPB, PySide2 and Pyside6 is already more than I'd prefer.

Ideally, adding support for a new GUI framework shouldn't require any changes to Briefcase itself - Briefcase should define enough extension points so that a new GUI framework should be able to add itself to the list of available templates.

How would this work?

1. Briefcase would define a briefcase.wizard.frameworks entry point.
2. Briefcase would define a base interface, and implementations of that interface for the "built in" GUI frameworks
3. A third-party package (like positron) could register against this entry point, and define it's own implementation (or implementations)
4. An end user wanting to use Positron would pip install briefcase positron[django], installing positron in the local environment (and the Django dependency), and registering the Positron wizard entry point.
5. When briefcase new runs, it builds the list of GUI frameworks from the packages registered against the entry point, rather than a statically defined list.

The "GUI framework" interface could provide customisation points to control the URL of the template (or possibly even refer to a file path that is packaged with the app as a resource); as well as potentially injecting additional questions into the Wizard after the GUI framework has been selected. It might not even be necessary to make the template URL customisable - if the base Briefcase template has enough extension points, it should be possible for a GUI framework implementation to define the packages that are needed as a Python list, and the bootstrap code as a multiline string, and have those injected into a common template.

This is somewhat akin to Django's approach to database backends - they provide a Sqlite, MySQL and Postgres backend as a matter of practicality, but they provide a robust extension interface so that Oracle, MSSQL, or any other database vendor could provide an ORM backend if they chose to do so.

In the extreme case, Briefcase could even entirely devolve GUI frameworks support to the GUI packages themselves. Briefcase itself would contain no support for GUI frameworks, but Toga would define how it is supported by Briefcase support interface.

Does that make sense? Any thoughts?

[Cheukting]

Sure, this sounds more like a future-proof approach. I like the idea of having a plugin and giving the flexibility for the community to develop more 3rd party GUI connections.

[Cheukting]

One thought about the 3rd party plug-in, I think it will be great to have more community engagement (just like Django). I am on board with this great idea. Thank you 🙏🏻