Nativefier: Support bundling apps under linux as AppImage / Flatpak

Created on 28 Aug 2016  路  14Comments  路  Source: jiahaog/nativefier

AppImage is a format for portable, distribution-agnostic binary software deployment for Linux without needing root permissions or installation. (Wikipedia)

Here is an example for Atom in AppImage format:
https://bintray.com/probono/AppImages/Atom/_latestVersion#files

And here is the script which produced it:
https://github.com/probonopd/AppImages/blob/master/recipes/atom/Recipe

While it is relatively easy to package an Electron-based app as an AppImage, it would be nice if this could be automated in nativefier.

electron-builder, a tool that performs similar tasks as nativefier, has already made AppImage the default format for Linux: https://github.com/electron-userland/electron-builder/issues/504

feature-request linux

Most helpful comment

I know how to create an AppImage, I will make some tests and see if it will work with the files create with nitivefier

All 14 comments

I would really love to see nativefier have the ability to package builds as an AppImage because it would increase the power of nativefier exponentially on Linux.

I know how to create an AppImage, I will make some tests and see if it will work with the files create with nitivefier

@DanielRios549 Any progress?

so showing support for an idea on this project is Spam? good to know Lol

so showing support for an idea on this project is Spam? good to know Lol

@MichaelTunnell hassling people about things they said they'd do, but _obviously_ didn't do (for whatever reasons that belong to them) is spam, yes.

Well, it's not exactly spam, but I do want to hide these comments not contributing anything to the discussion, and the options offered by GitHub's "Hide" feature are: [Spam, Abuse, Off-Topic, Outdated, Duplicated, Resolved]. Spam is the closest to the sentiment I have to express.

At any rate, asking "hey is this done?" is definitely not "showing support" in an acceptable way, it's just noise that degrades the readability of the discussion for potential contributors.

And no, such comments won't motivate someone who promised something to finish & ship what they promised; I know it because I've seen it tons, here in this project and elsewhere. People get busy, maybe no longer have the time, maybe they're in trouble with their work, maybe their kids, who knows and I don't blame them, it's fine. "Showing support" is one of:

  1. You just want the thing done and have nothing to contribute: add a thumbs-up reaction.
  2. You have an idea that might help implementation: express it clearly, with references and links and all that can help a potential implementer.
  3. You see it's still not done but think you can do it: do it, and submit a PR.

I would like this as well. Tried in bash, but had no success so far in building AppImage. :(

"hassling people about things they said they'd do, but obviously didn't do (for whatever reasons that belong to them) is spam, yes."

Sending 1 message of support over the course of 2.5 years is not at all hassling someone.

"asking "hey is this done?" is definitely not "showing support" in an acceptable way"

Asking if something is done yet or if there is progress on something isn't technically support. However, what is support is what I said. I didn't ask if it was done or for a progress report.

I merely commented that I think its a great idea and it would improve the value of Nativifier on Linux exponentially. This is support and I left that message 2.5 years ago. I didn't follow up with it in anyway until I noticed it was for some reason marked as spam. That's when I made the snarky comment because I see no way what I said could be construed as spam.


With that said, I also don't consider asking for an update as spam either . . . not useful sure but also not spam. I think the better option is to just ignore it or mark as off-topic and here's why.

The potential issue here is I don't know how GitHub handles people being marked as spam but depending on how they treat accounts, this could possibly affect people negatively as being marked as spammers.

If you want to hide it then thats fine but please use Off-Topic because I don't think there would be a punishment for that. I don't know if Spam has a punishment or not but just in case I'd request Off-Topic.


As for your suggestions as to showing support:

  1. my comment was from 2.5 years ago and I dont think GitHub had the thumbs up piece at the time of the comment. It might have, I don't remember. However, I still think my comment would still be valid due to the expression of how valuable it would be not just to have another feature but to incorporate a great way to distribute on Linux.

    • I do agree that I do hate to see comments of just simple "+1".

  2. of course that's helpful but thats more contribution than just support
  3. that's not support, thats simply doing it. Of course, this is ideal contribution but not everyone is a developer, such as myself as a designer / marketer.

anyway, please mark as off-topic just in case, including this message as it's totally off topic. :D

Have a great day and stay safe from this crazy madness we're in.

I tried to write a simple script for doing that:

https://github.com/probonopd/linuxdeployqt/issues/437

But it has failed for no apparent error. Any input is appreciated.

@MichaelTunnell you have a valid point about Spam potentially having adverse consequences to a GitHub user account. Hadn't thought about that; will definitely use Off-Topic from now on. Thanks.

As for the rest of your response, I can sympathize with what you say, but it stops flying when you receive tons of such comments. Your comment may be innocuous, but dozens of those across issues starts to be a pain for maintainers and folks trying to digest the thread. This happened in a few issues here, and since then I use GitHub's "Hide" feature.

Rant time: GitHub / Microsoft and their army of data scientists could do much better with AI / sentiment analysis, and for example automatically collapse such comments (or at least mute them with a bit of CSS if collapsing is considered too strong) and convert them into thumbsups. That would go a long way to 1. aggregate interest (as thumbsups, which are a great metric to gauge user interest) and 2. keep the thread readable. End of rant.

Have a great day too! Marking your/my comment as Off-Topic, agreed.

I have made a proof-of-concept AppImage, please test it:
https://github.com/probonopd/nativefier-test/releases/tag/continuous

AppImage

medium

But it has failed for no apparent error. Any input is appreciated.

You were using an -unsupported-.-. flag, that may well have caused that issue.

Consider Flatpak as an alternative because since it uses OSTree the various Electron apps can share most of the engine and reduce the used storage. Because let's be honest, wasting so much storage for duplicated stuff really defeat the purpose of Nativefier. There is already an Electron base app for Flatpak, see:
https://docs.flatpak.org/en/latest/electron.html

Consider Flatpak as an alternative because since it uses OSTree the various Electron apps can share most of the engine and reduce the used storage. Because let's be honest, wasting so much storage for duplicated stuff really defeat the purpose of Nativefier. There is already an Electron base app for Flatpak, see https://docs.flatpak.org/en/latest/electron.html

@alxlg both have advantages and drawbacks, and I'll accept patches for both.

  • Flatpak: as you said, better resources sharing.
  • AppImage: fully static, independent from the rest of the system.

Hi @ronjouch

I'll accept patches for both.

I am not sure how you would like to integrate it into nativefier, but here is my work - feel free to incorporate it:

https://github.com/probonopd/nativefier-test/blob/master/nativefier.bash

Was this page helpful?
0 / 5 - 0 ratings