That said, an optional “use system environment if available” mode could make sense for advanced users. 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.
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.
So it has, and I've been hating the excess complexity it brings for most of that thirty years! I'm glad to see the recent swing back toward self-contained executables. Where this author went wrong was not in vendoring the app's exact dependencies, which is a good idea, but in trying to download them and install them separately on first launch, rather than including them in the app bundle, where they can remain isolated from the rest of the system.
It reduces complexity compared to the administrative and security mess of every application having its own version of every library, let alone its own version of external tools and interpreters.
> I'm glad to see the recent swing back toward self-contained executables.
I wish there was one. Static linking is a great solution for this. Instead, we're seeing dynamically linked libraries being bundled alongside of executables in a way that increases complexity vastly.
> Where this author went wrong was not in vendoring the app's exact dependencies, which is a good idea, but in trying to download them and install them separately on first launch, rather than including them in the app bundle, where they can remain isolated from the rest of the system.
Agreed. Dependency resolution at build time is normal. Dependency resolution in user mode at runtime is crazy.
"Normal" users wouldn't even encounter anything here, as they'd just install prebuilt binary packages with all of the dependencies already sorted out. As things stand, the application trying to install its own dependencies at runtime is creating a whole new class of user-facing issues to generate escalations (such as the app's failure to locate the Python interpreter it itself had just installed).
There is more risk in the shenanigans people who package software for distros do. Kdenlive suffered from big damage to their reputation due to all of the crashes packagers added by using incorrect versions of dependencies.
>"Normal" users wouldn't even encounter anything here, as they'd just install prebuilt binary packages with all of the dependencies already sorted out.
That's the benefit of just shipping what the developer released instead of swapping out dependencies under developers' feet.
thanks for your feedback and reports, I'd be happy if they are added as issues on github.
as said in the separate comment, 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. it's a karaoke app, not a tool that is aimed at engineers.
we can indeed look at the local packages before downloading an executable, it's just not done yet but might be added in the future.
I've built this project out of passion and it's 100% open-source and free, so please keep this in mind when criticizing.
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.
I'm not experienced in building desktop apps per-se, so I went with the thing that looked reasonable to me. all your comments are valid tho. I'll take a look how can I resolve this in the future.
cheers!
If someone on here would direct at me the insinuation that a flaw in my software was the result of me having "no idea" about what I am doing, we would not be having a civil discussion.
In my view personal attacks should be flagged, but I don't have that ability because my account does not have enough Karma.
If you can't tell AI slop from handwritten code, that's your problem. I won't censor myself because of your opinions.
Personal attacks are still against the rules of this site, and that's why you, or in this case the commenter before you, should have censored themselves. This is not a matter of opinions.
Besides, even before LLMs, it's not like anyone ever said "you shouldn't have open sourced this, we can't learn from your code". We just didn't bother reading that code.
Telling off people who contribute is not OK.
It's a useful tool and I built it myself, with my own ten fingers, using my brain. That's more than vibe coders will ever do.
Meanwhile, your blog says in big text "I don't care for the joy of programming", so I don't consider your opinions on software development anywhere near relevant.