> It’s a desktop app for mostly non-technical users, so bundling the runtime is a deliberate tradeoff to reduce setup friction and machine-specific breakage.

That's not a very reasonable justification, considering that dynamic linking of dependencies has been industry standard in software designed for "non-technical users" for the past thirty years or so, and is basically a solved problem.

I can understand having a downloadable archive that already includes things like FFMpeg and Python for Windows users (with everything already included in appropriate locations, so no runtime downloads necessary).

But this is an especially bad practice for Linux, since most of the vendored dependencies are already installed by default on pretty much every Linux distro, and package managers are designed to sort out and install appropriate dependencies on behalf users, so that the "non-technical" among them aren't exposed to the massive risks of having application software retrieve and execute arbitrary binaries from the internet.

The only thing it somewhat makes sense for would be the AI models it's retrieving, but even that ought to be implemented via a separate download/update script and not just baked into the main application runtime without even prompting the user that it's about to download a huge dataset.

> A PR for that would be welcome, as long as it also handles the real complexity involved: platform differences, Python package compatibility, GPU backends, and missing system/compiler flags.

These are the sort of things that config scripts at build time are designed to handle. It's already using Cargo here, which should be able to handle all of this just fine, so it's very perplexing to see that it isn't being used for this purpose, and what should be build-time dependency resolution is instead being palmed off to the application itself at runtime. That is an extremely strange -- and potentially dangerous -- approach.

Such a setting will cause more headaches for the developer since it explodes their support matrix. Supporting a single version of dependencies and shipping those is a much more scalable solution for delivering high quality software.

> I really wanted an app to be as "grandma-proof" as possible, therefore I really wanted to have one binary that does the magic for you.

Probably the best way to do that is to design, build, and distribute it like any other normal desktop application, and not come up with idiosyncratic and experimental methods for invoking bog-standard libraries and language interpreters.

On Windows, just include the necessary binaries as part of the application distribution itself, in hardcoded paths, without any runtime download of executables from unclear sources.

On Linux, use system defaults resolved at build time through a normal config script -- any "grandma users" on Linux will end up installing from distro repos, AppImage, Flatpak, etc, all of which have their own methods for handling dependencies, and is definitely not something the application should be trying to do by itself post-install.

While I can understand that, why not replace python deps with wasm versions ?

Vibe coders are NOT programmers, they are leeches, feeding from the blood of the open source.