Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support AppImage as a target for Linux #428

Closed
probonopd opened this issue Jul 26, 2016 · 11 comments
Closed

Support AppImage as a target for Linux #428

probonopd opened this issue Jul 26, 2016 · 11 comments
Labels
enhancement Feature request wontfix ❌ Maintainers have decided not to pursue this issue

Comments

@probonopd
Copy link

It would be great if electron-packager could support AppImage as a target for Linux. AppImage is a distribution-agnostic format for distributing Linux applications.

For example, it would be great if we could generate an AppImage from, e.g., https://github.com/Thomas101/wmail/blob/master/package.json

electron-builder already has AppImage support but some projects use electron-packager rather than electron-builder.

@develar
Copy link
Contributor

develar commented Jul 26, 2016

Duplicates #33 ? #33 (comment)

@malept malept added enhancement Feature request wontfix ❌ Maintainers have decided not to pursue this issue labels Jul 26, 2016
@malept
Copy link
Member

malept commented Jul 26, 2016

Similar to #33, providing installers (or OS-specific packages in this case) is outside the scope of electron-packager.

@malept malept closed this as completed Jul 26, 2016
@probonopd
Copy link
Author

probonopd commented Jul 29, 2016

I think this is a misunderstanding. AppImage is not an "installer", rather it is the direct equivalent of an ".app.dmg" in macOS. It is an executable file that runs directly on most Linux distributions without the need for installation.

The stated purpose of electron-packager is to "Package and distribute your Electron app with OS-specific bundles (.app, .exe etc)". AppImage is exactly such a bundle format for Linux.

Please reconsider.

@malept
Copy link
Member

malept commented Jul 29, 2016

In my opinion, the main problem with your argument is that upstream Electron already provides an Electron.app template for us to customize for your app, so all we're doing is replacing values (and files, for example the icon). This is true of all of the platform/architecture combinations. The only extra processing step that we do is create ASAR archives, and even that is outsourced to the asar module.

(Also, we don't create .dmg files, electron-builder does, but I suspect that was just a typo on your part.)

Adding AppImage support just doesn't make sense given the current architecture of Electron Packager.

@develar
Copy link
Contributor

develar commented Jul 29, 2016

  • AppImage is a distributable format, electron-packager produces only non-distributable formats.
  • "the main problem with your argument is that upstream Electron already provides an Electron.app template" electron-packager just package.
  • In any case, when user wants to build in distributable format, he will use or custom build scripts, or electron-builder.

@probonopd
Copy link
Author

Adding AppImage support just doesn't make sense given the current architecture of Electron Packager.

In my experience, Electron projects either use electron-builder or Electron Packager, where the former can do AppImage and the latter can't. This makes some projects consider to switch from the former to the latter.

@malept What exactly is it about the current architecture of Electron Packager that leads to "Adding AppImage support just doesn't make sense"?

@MarshallOfSound
Copy link
Member

@probonopd This is from me not @malept but I see Electron Packager and targets such as AppImage, MSI, EXE and other such build results as separate goals. Electron Packager's only goal is taking your code and packaging it into a generic folder that will run on the given platform. Supporting targets like AppImage is the role of tools such as electron-installer-* modules, electron-builder or electron-forge. It is separation of concerns IMO 👍

@MarshallOfSound
Copy link
Member

Tbh what @malept said is pretty much on point

Similar to #33, providing installers (or OS-specific packages in this case) is outside the scope of electron-packager.

@probonopd
Copy link
Author

@MarshallOfSound thanks for the explanation, that clarifies it for me. So you are saying one can use a combination of Electron Packager and electron-builder?

@MarshallOfSound
Copy link
Member

@probonopd electron-builder made the decision a long time ago to stop using electron-packager internally (wasn't really paying attention when that happened so not sure why). But electron-forge does use -packager internally and can use the AppImage target from -builder if that's the user preference.

And I believe you can use -packager and -builder together using the Electron Builder "pre-packaged" target.

Basically there are options for everyone 👍

@develar
Copy link
Contributor

develar commented Apr 8, 2017

So you are saying one can use a combination of Electron Packager and electron-builder

Yes. Please see https://github.com/electron-userland/electron-builder#pack-only-in-a-distributable-format

electron-forge does use -packager internally and can use the AppImage target from -builder if

Using electron-forge-maker-appimage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request wontfix ❌ Maintainers have decided not to pursue this issue
Projects
None yet
Development

No branches or pull requests

4 participants