In 2023 isnt it almost always better to make a webapp through dash or something if you need a “gui”?
We tried this approach once, for this exact reason that we didn’t want an “old thick client”. Our app interacted heavily with the user’s OS and their line of business app, and it was a nightmare dealing with the customer’s IT department, wondering why we needed to run HTTP servers everywhere, causing security alerts.
We switched it to a simple Tkinter app and everyone involved was much happier.
No server admin work needed!
That can be mitigated with a token included in the browser launch URL, but it seems like a pretty unlikely vector anyway, someone would have to write code that specifically knows about SyncThing, and then convince you to install it, and then you'd have to not use password protection.
A webui for a desktop app can be made perfectly securely, though.
For example it can bind to 127.0.0.1, not do external network requests, and require a token (generated by a systray menu utility or an app shortcut for example) that will prevent automated exploits from accessing it as well as other users on a multi-user system.
PyInstaller is a good starting place. There are several others with similar capabilities.
And it will produce a single-file executable that bundles the interpreter, application Python code, extensions, and any other resources (data files, images, fonts, etc).
Both numpy and pytorch are explicitly supported, although that's not guaranteed for all extension packages.
However on Linux things kinda suck because PyInstaller will package your current interpreter, so if it's linked against things that are different on another Linux (eg no glibc) it will often crap itself. But so is the joy of distributing compiled software to Linux users :).
I typically use an older distribution as my build box: this means that the dependencies pulled in by the interpreter are older versions, and when it runs on a newer distribution, the backward compatibility for libraries will ensure it works ... usually.
I've messed about with using a completely independent build tree for this: something that depends on libc/libm/etc only from the OS, and all other dependencies are part of my build. That seems like it works pretty universally, but it's a lot of work.
I've been meaning to look into leveraging the Flatpak runtimes for this: they seem like they have pretty similar concerns.
It depends on your requirements. I still produce actual native GUIs for tools I write. They're faster, require less futzing to service, generally continue working for years if not decades, have far richer control possibilities out of the box and tend not to rely on 5000 layers of excrement slapped on top of each other.
Oh and no fucking Javascript!
* usable on pretty much any platform
* easy to distribute/update
* easily trustworthy/jailed (no need to install something that might access your data)
It makes me sad, but as far as I can see, there is no serious alternative for universal+jailed apps.
There are plenty of ways to distribute thick client apps that are usable from any client, easy to update, and which don’t have access to local resources, like Remote Desktop, VMware, Citrix, etc.
and ask your users to install those before being even able to use your app?
I haven't phrased my argument very neatly, but the point stands: anyone with an iphone/android/linux/… can easily use a web app, now, without any prerequisites. You don't have to bundle it or distribute it differently than with a webserver and it's a single codebase. That's not the case for any other tech that I'm aware, and it's a shame.
But it’s all about requirements. The benefits you describe are not universal benefits.
Mobile app stores, where users have to install apps, transact over a $1 trillion per year. Sometimes a native app provides a better experience.