conda
Use Briefcase as an installer backend
Checklist
- [x] I added a descriptive title
- [x] I searched open requests and couldn't find a duplicate
What is the idea?
This issue is a summary of some recent discussions between the BeeWare and Conda teams. We're posting it in public to get feedback from the larger community.
Briefcase (part of the BeeWare project) is an open-source packaging tool which has some overlap with Constructor's functionality. It's a mature and well-tested tool that supports building Mac, Linux and Windows installers in multiple formats, including signing and notarization.
Briefcase currently combines two functions: creating a directory tree containing a Python app, and packaging it into an installer. If it had an option to use the packaging step independently, then it could create installers with arbitrary content. In this mode, Briefcase’s own Python app functionality would not be involved.
Constructor could then use Briefcase to build installers, with the following division of responsibility:
- Briefcase provides non-conda-specific installer mechanisms.
- Constructor uses those mechanisms to implement conda-specific functionality.
From the Constructor user’s point of view, very little would change: they would continue to use Constructor’s existing CLI and configuration file format. The fact that Constructor used Briefcase to build installers would only be an implementation detail.
Constructor could start using Briefcase incrementally, one installer format at a time, without disturbing the others.
Why is this needed?
As described in #646, for several years the Constructor developers have wanted to stop using NSIS because of its developer-unfriendliness. However, the effort required to produce an entirely new Windows backend has so far been too much to face.
Briefcase has an actively-maintained Windows installer implementation based on the modern WiX toolkit. Reusing this via Briefcase's high-level interface should be significantly easier than creating a WiX backend from scratch.
Longer term, Briefcase could also be used to build installers in other formats, e.g. .pkg installers for macOS, which would relieve the Constructor project of even more maintenance burden.
Remaining features required for production use
Feel free to edit this comment as necessary.
In Briefcase (add links to issues once they exist):
- Welcome screen
- With custom text and branding image.
- Conclusion screen
- With custom text, and some means of launching web pages or one of the installed applications.
- Developer configuration of default target directory.
- User configuration of actual target directory.
- This is currently always Program Files when installing for "all users", and AppData\Local\Programs when installing for "just me".
- Would require thought about how to handle multiple concurrent installs.
- Done in https://github.com/beeware/briefcase-windows-app-template/pull/78
- Logging improvements
- The install script currently runs in a separate console window, which allows better terminal animations, but is potentially confusing to the user.
- Uninstaller options
- Done in https://github.com/beeware/briefcase-windows-app-template/pull/79
In Constructor:
- Integration with existing Briefcase features (documented here and here):
- Icon in Programs control panel
- Installer options
- Uninstall script
- This currently does not exist, so everything created by the install script needs to be manually deleted after running the uninstaller.
- Integration with the new Briefcase features listed above
- Completion of install and uninstall scripts
- See #968 for discussion of how they could be written.
- Signing
- We previously talked about adding AzureSignTool support to Briefcase, but it it looks like Constructor already has a self-contained implementation of this, so it should probably stay there for now.
- Update:
- Integration testing process
- setup-miniconda GitHub Action
- User documentation