ankitects
feat: launcher gui
To run, install tauri's system dependencies, cli (cargo) and then, in the repo root, cargo tauri dev with .\yarn ld in another window
- [ ] Error handling and display
- [x] Check if os/glibc ver. is supported
- [x] Uninstall isn't implemented yet
- [ ] Refactors
- [ ] The uv code was almost wholesale transplanted from the old launcher (with modifications for pty) and is in dire need of a cleanup but I didn't want to spend time on major changes without checking if any of this is acceptable (😅) and if we still want to keep the cli around?
- [x] UI state needs reworking, versions should be queried on app launch, not on svelte mount
- [ ] CI
- [ ] svelte-check action for the launcher
- [ ] target for installing tauri cli tool
- [ ] UI design Tentatively based it on the options pages (i probably won't be of much help here)
Closes #4152
EDIT: CI is missing some of tauri's needed system deps
This is impressive work llama! I'll need a bit more time to review the current code properly, but I wanted to give you some quick feedback to unblock you.
- Happy with the general direction, and don't think we'll want to keep around the terminal-based approach with this in place, subject to the next point. Given that, it might be nice if the code for this lived in qt/launcher, as that'll also make it easier to track any changes made to the old launcher code.
- We'll probably want to get an alpha build of this into the hands of testers as soon as basic functionality is working on all platforms, so we can identify any unanticipated compatibility issues that might prevent us from switching away from the terminal approach.
- Not urgent, but it would be nice if our build system eventually provides a target that takes care of installing the cli tool (like we do for cargo-nextest).
- Your pty approach saves us a bunch of work, and may end up being our best approach. Downside is that we won't be able to show overall progress to users who might be daunted by the per-package output. It might be worth starting a discussion with uv about possible alternatives, such as a flag that restricts progress to a single overall bar, or exposes progress events over a socket or the network. If they're amenable to something like that and we decide it's a good idea, we could send through a PR to make it easier for them to accept.
- I wasn't able to test the install process on a Mac, as I get the following during startup:
thread 'tokio-runtime-worker' panicked at qt/launcher-gui/src-tauri/src/commands.rs:140:58:
called Result::unwrap() on an Err value: Read "/Users/dae/Local/rust/Resources/.python-version"
The existing code expects the launcher binary to be run from within an app bundle. This is how the layout looks like for the terminal version:
$ ls -aR ../../../out/launcher/Anki.app
. .. Contents
../../../out/launcher/Anki.app/Contents:
. .. Info.plist MacOS Resources
../../../out/launcher/Anki.app/Contents/MacOS:
. .. install_name_tool launcher uv
../../../out/launcher/Anki.app/Contents/Resources:
. .. .python-version Assets.car pyproject.toml versions.py
build.sh in qt/launcher/mac takes care of the building that folder after compiling. If you don't have access to a Mac, I can take care of this before the alpha test.
Should hopefully have more comments in the next few days!
Pushed changes i made over the past week (sorry for the massive diffs!)
Given that, it might be nice if the code for this lived in qt/launcher, as that'll also make it easier to track any changes made to the old launcher code.
I'd like to move it over after getting uninstall done, just to have it as a reference. The refactors i did will probably make tracking changes harder, as it included changing some of the fns to methods. But i'll likely revert that as it adds indentation for no gain
It might be worth starting a discussion with uv about possible alternatives, such as a flag that restricts progress to a single overall bar, or exposes progress events over a socket or the network. If they're amenable to something like that and we decide it's a good idea, we could send through a PR to make it easier for them to accept.
I actually did look into this after encountering problems with pty on windows early on and was able to patch [email protected] to output parseable progress on stdout (pushed it here: https://github.com/astral-sh/uv/compare/0.7.13...iamllama:uv:sync-progress)
uv uses the indicatif crate to render those fancy progress bars on stderr, and if it isn't given a tty it doesn't show progress at all. I don't think uv uses stdout for anything so maybe we could use that instead of sockets/etc? It'd be best to @ zanieb to see what's acceptable (there's work being done on a JSON output format, but it doesn't include progress)
I wasn't able to test the install process on a Mac, as I get the following during startup:
I don't have a mac, so help would be appreciated here 😅 I reckon a quick sanity check would be building the gui with cargo tauri build, modifying these paths in the old launcher's mac build script to point to launcher-gui instead:
https://github.com/ankitects/anki/blob/321e23acb2b02d657ca08727546c016d7ef27381/qt/launcher/mac/build.sh?plain=1#L28-L29
and then running the output of that script as per normal
I probably won't have a chance to circle back to this until late this week/early next week :-( If you're blocked on anything, please let me know and I'll try to get to that earlier.