Noisy first run
Quite a few people have voiced concerns about the terminal output being too technical/daunting for the average user. The Mac and Linux launchers already attempt to lessen this a bit by adding some leading/trailing text:
One potential change we could make is to to lead with a brief explanation, and require the user to confirm first. E.g: “Anki needs to download its program files. Press the enter key to continue.”. It makes install/updates a bit more cumbersome for experienced users, but would avoid a wall of text all of a sudden.
We can’t easily replace the output with a GUI progress bar, as the underlying tool we’re using for this does not support that. We could hide all output and show an indeterminate spinner, but that offers no insight into how much progress is being made, and how much is being downloaded.
On subsequent updates, fewer packages are likely to change, so it will be less of a wall of text.
Offline installers
Internet is only required for the first run, or after explicitly agreeing to update. Once installed, you can copy the AnkiProgramFiles folder onto a flash drive or across to other computers as you please (preserving modification times), and the launcher will use them instead of downloading the files again. Or you can skip the launcher and open Anki directly from that folder.
Third-party packages
Linux distros take multiple approaches to packaging Anki, with the most common being:
- building everything themselves (uses system Qt)
- using the aqt/anki wheels we distribute on PyPI with their system’s Qt/other Python packages
- a thin wrapper over our old PyOxidizer bundles (uses PyPi Qt)
Linux distros are predominately using approach #1 or #2. Package tools like homebrew and winget tend to use #3.
The first and second approach can continue to function like before, though distros that use #1 may need to make some minor tweaks to deal with the new uv.lock file and changes to the build.
#3 will no longer work, since we’re no longer providing those bundles. But since that approach did not use the system libraries, the only real advantage over downloading Anki’s packages directly was that you got access to automatic updates. And as this new approach has built-in support for that, I don’t think this will be a big deal in practice.
Unlike Windows and macOS, the Linux/BSD desktop environment is fairly heterogenous, and that makes it difficult for binary packages to fully integrate with each system, leading to theming issues, broken keyboard input methods, etc. From an “integrates well into the desktop” perspective, using the system’s Qt is a better approach if the distro has relatively up-to-date Qt libraries.
It might be possible to in the future to give the launcher an option to use the system Python/Qt. Uv doesn’t have support for something akin to --system-site-packages, but it may be technically possible with sys path hacks.
Other feedback
I’ve logged some of the reported issues on Assorted minor issues with new launcher · Issue #4107 · ankitects/anki · GitHub
Replying to some of the above posts:
I can’t reproduce this - perhaps related to an add-on you have installed?
Does it persist with the latest update?
That doesn’t surprise me - our old packaging process stripped out some Python modules Anki itself wasn’t using, and some documentation/support files. The flip side of this is that sometimes add-on authors couldn’t use an add-on module that would normally be available.
If the cache were removed, uv would need to download everything again each time Anki got an update, even a tiny one. I think it makes sense to keep on by default, but users could remove it themselves if they wished (run ‘uv cache clean’).
This was a recent regression in the development code, and unrelated to the installer. Thank you for the report!
That doesn’t happen for me - does it still occur for you if you remove the AnkiProgramData folder and try again?