Revisiting the launcher

[dae]

Just wanted to give you a bit of an update/some background.

The decision to go with a launcher approach was partly due to feeling overwhelmed, and wanting to reduce the overhead of making releases. I figured it'd get users something close to auto-update support at the same time, so it seemed like a win-win. But between uv edge cases and users' eyes glazing over the moment a terminal window appears, it hasn't been as smooth as I'd hoped.

A launcher GUI is the logical next step. It should solve a bunch of pain points/be more user-friendly. But it doesn't solve all problems (e.g. #4151), and some users want to be able to do a single download without subsequent extra downloads.

Months back Andrew floated the idea of using Briefcase instead, which is closer to our old PyOxidizer setup. We have extra hands at our disposal now, making maintenance less of a concern, so that may be more practical now. I think we might want to explore that path in more detail (only a very basic PoC so far), and then decide whether to persist down the launcher path, provide both in parallel, use some hybrid approach, or switch over to a more conventional packaged build.

Originally posted by @dae in #4390 (comment)

Related:

• Consider integrating Python in the launcher #4151
• feat: launcher gui #4390 (comment)
• feat(launcher): embed python #4414 (comment)

At this point I figure we have the following options:

• Persist with the launcher, optionally merging the launcher GUI @iamllama has worked on
• Revert to a more traditional bundle, using something like Briefcase or PyInstaller.
• Do both, leaving the launcher around for power users
• Do a hybrid model, where Python (and possibly Qt) is shipped with the 'base', but we use something like 'uv' to update our code and other deps.

If we switch to a traditional bundle, we'll lose the easier/faster version upgrades/downgrades. But the people appreciating that probably doesn't justify the number of users that struggle to get Anki installed. Automatic updates would still be possible, but would presumably require downloading an entire new package for each version bump.

Keeping both is appealing in that it doesn't throw away previous work. I don't know if there enough power-users to justify keeping both though, especially since the launcher is basically just a convenient wrapper around manual uv invocations.

The hybrid approach offers some benefits. My main concern is that users may struggle when some updates (those that don't touch Python/Qt) are turn-key, and others require a manual download.

Thoughts?

[abdnh]

Linking the AnkiHub POC for reference: https://github.com/AnkiHubSoftware/anki-briefcase-test

My impression about the uv launcher is that it's too much custom code for something that was mostly a "solved problem" with PyInstaller/PyOxidizer. Users don't expect the installation process to fail, but this is unfortunately the case at the moment for a good number of users, according to forum posts. @iamllama's work brings great improvements, but I agree it's worth reconsidering the whole approach before sinking more time into it.

Keeping both is appealing in that it doesn't throw away previous work. I don't know if there enough power-users to justify keeping both though, especially since the launcher is basically just a convenient wrapper around manual uv invocations.

Power users can already install Anki from PyPI to get most benefits of the launcher.

Revert to a more traditional bundle, using something like Briefcase or PyInstaller.

We're exploring Briefcase, but I wonder if going back to PyInstaller would be the better choice since it's likely to have better support? Something to consider.

[user1823]

I am in favor of doing both. Arguments:

• The launcher allows easier/faster version upgrades/downgrades
• The launcher provides an easy way for users to selectively upgrade/downgrade some dependencies (e.g. Qt) if they encounter an issue on the version shipped with Anki.
• The packaged version is easier to install for the general users and meets the need of those who require a single package (such as for offline installs)
• The launcher is already being used by several people without major issues. So, maintenance would probably not require much work. If someone encounters an issue, they can use the packaged version anyway.
• If there are no launcher changes in a particular release, the release process is not any different from releasing the packaged version alone.
• Yes, the launcher is mostly just a wrapper around uv. But, user ability is distributed on a spectrum. Someone may be technical enough to understand how to use the launcher but running uv from the command-line might look daunting.
• Lastly, if Anki is installed using uv from the command line (without the launcher), the user will need to go to the command line to open Anki every time they want to use it or create a .bat file (and equivalent on macos/linux). The launcher makes this easier for the user by providing a convenient anki.exe.

[ES-NC]

Hi,
Just chiming in from an Education/Enterprise perspective on macOS.

The new Anki Launcher opens in the Terminal. This is blocked.

In our education environment, Terminal is blocked unless a student is actively doing programming subjects. While this doesn't prevent all students from running scripts on their computer, it does significantly decrease the likelihood of students running something they don't understand and causing issues they can't explain, aside from the students trying to actively achieve nefarious goals.

So from that perspective, Anki is now "blocked" as the launcher tries to open a blocked app and there is no way forward.

[Neribr]

last Anki versions have that terminal popup? pls dont lol