Consider supporting downloadable frameworks #848
I would like to gather feedback about it, especially to understand if this is something that people would use (I searched in the past issues, and I cannot find any request for such a feature :-) ).
The text was updated successfully, but these errors were encountered:
Our credo is "one app = one file". No external dependencies, nothing to care about than one single file per application. Disk space is cheap, and updates are cheap, too, when using https://github.com/AppImage/AppImageUpdate with its binary delta updating.
Any sort of "external dependencies" requires some additional user and developer efforts. You suggest to solve the problem of lack of frameworks by providing some "installer". That goes against anything AppImage stands for: we want self-containedness, installer-free experiences, everything must "just work". Applications should start up immediately after having been downloaded. When having external dependencies, how could you "easily" copy AppImages to a USB disk any more? Using more "assistants"?
Then, who's going to "ship" those additional dependencies? The only viable way seems to me to re-use some existing distribution systems. Maybe something like conan, which already provides some sort of "library download and distribution system". But that'd add a dependency to such a service.
Also, size-wise, most applications link to their very own libraries or a hell lot of different versions. I guess you overestimate the advantage of reducing redundancy overhead.
I don't think that will ever be supported officially. It'd break with our most important concet: "one app = one file".
Thanks @TheAssassin for your valuable comments (especially I didn't know about conan.io, I'll have a look!).
However it looks like you misunderstood my idea, or didn't read my blog post carefully -- or I just failed to express myself. The installer would be part of the AppImage; so, if you move the AppImage to an USB stick and open it in another PC, it will either work out of the box (if the target PC already has the dependency installed) or try to download the missing libraries. Is it more hassle than a single AppImage file? It certainly is, especially if you don't have an internet connection in the target PC :-)
Also, the system I describe is decentralized; it allows for central repositories, but at the end the final decision on where to fetch the dependencies from lies on the application developer.
But other than that, I agree with your analysis. And for the record, PhotoTeleport is not an electron app :-) It's just that I need the browser to perform the OAuth authentication -- I've thought the possibility of using the user browser, but that makes the experience rather worse for the user, in that he needs to copy and paste codes from the browser to the app. Or maybe the problem is that QtWebView on Linux does not make use of the user browser, but uses its own QtWebEngine...
I've read through most of your blog post, I've seen it's a Qt app which needs Qt's webengine. My words on the Electron and other web browser apps were more like for the next person to suggest something to make their bloat "more efficient". I see that you don't have any other choice.
That means you're depending on an internet connection. With AppImage, it is possible to download an AppImage in some place, and then go to a disconnected computer and run the applications there. You'd have to manually copy "cached frameworks", which is very counterintuitive. That's a lot more hassle. That use case would have to be supported by your project, which adds more and more complexity to the "simple" system you might have in mind.
Our rule "one app = one file" is "simplicity in person". There have been lots of attempts to break with it, but all of them lead to a lot worse UX.
But hey -- AppImage is free software, and if you want to go that way, sure! But it can never be part of AppImage. I'm pretty sure @probonopd agrees.
No need to reduce the size. We have seen way larger AppImages.
The main point about an AppImage is that it has no dependencies besides the target system (= least common denominator of default installation of most Linux distributions).
If we would allow for dependencies, then the user would need to be online to download additional stuff, would likely need a package manager (or installer) of sorts, and the whole advantage of AppImage ("it just works") would be gone.
People who like this are imho served just fine by Snap.
Our target user experience is: Go to an Internet Cafe, download one single file, take it home to your Linux computer, run it. No installation, no downloading of additional stuff, no package manager, no installers, no installation, no dependencies, nothing complicated. Just one file that contains everthing the app needs to run on most Linux desktops. The fact that your application is 100 MB (or a gigabyte) is fine.