Electron-packager: Add an option to use local electron binaries

[romaincointepas]

Right now electron-packager can only be used with official releases (dowloaded with electron-download). I would be interested in using it with locally built binaries (instead of specifying version, we would specify binary-path?).

[Silvercast]

+1
I know we can use cache option but maybe it's better to have ability to specify where to download electron files

[malept]

If you run your own local mirror (via a simple file-serving HTTP server), electron-download provides a way to do this via environment variables.

Apart from that, I'm not sure what the advantage of not using the cache parameter is.

[Mauricio3000]

You can copy the binary file to /home/user/.electron and electron-packager will use that file, as long as it's the latest version. I assume you can direct it to use an older cached file if you specify the version and it finds that version in the cache directory (/home/user/.electron)

It's the default behavior of electron-download. You'll notice once you download, it will use the .zip in /home/user/.electron afterwards as it stores it there

I had same concern so I could work/build offline.

You can get latest builds from: https://github.com/electron/electron/releases
Info for electron-download, used by electron-packager, here: https://www.npmjs.com/package/electron-download

[malept]

FYI, you can download via the electron-download CLI instead of downloading manually via the releases page.

[craxal]

What if I don't want to use one of the official releases? What if you want to use your own build of Electron? electron-packager (or perhaps electron-download) doesn't appear to handle this at all. I've tried putting a prebuilt package in various places mentioned above (which won't work in distributed build systems) and setting the cache option, but it always hits the electron repository and ignores my local package.

[develar]

@craxal Issue marked as help-wanted :) You can try to use electron-builder electronDist .

[malept]

@craxal it should work if you pin your Electron version to an exact version (that already exists) and create one or more zip files (depending on which targets you're packaging for) that are formatted and named the same as the official releases. I just tried it with electron-quick-start, with a zipped electron file named electron-v1.2.0-linux-x64.zip and using Electron Packager with a custom download.cache directory I specified with said custom zip ran without errors. You may be interested in a similar issue in electron-prebuilt: https://github.com/electron-userland/electron-prebuilt/issues/192

[craxal]

@develar I looked into it, but the macOS only caveat is a serious deterrent.

@malept How can I tell if electron-packager is in fact using my local .zip (which is, in fact, named exactly the way an official Electron package is named)?

[malept]

@craxal Run Electron Packager with DEBUG=electron-download. One of the debug lines is "zip exists" with the full path to the cached zip file, if it uses a cached zip file.

[malept]

@craxal Set process.env.DEBUG = 'electron-download' before you require('electron-packager'), I think. This seems related: https://github.com/visionmedia/debug/issues/275

[craxal]

@malept OK, it seems to work for a Linux machine, at least. It can see the .zip, and I saw no download progress bar.

[craxal]

I need to revisit this issue. There must have been some significant changes between 8.5.1 and 8.7.1, because my builds are now failing checksums against custom Electron builds.

Tue, 13 Jun 2017 22:34:07 GMT electron-download info { cache: 'E:\\A',
  filename: 'electron-v1.7.2-win32-ia32.zip',
  url: 'https://github.com/electron/electron/releases/download/v1.7.2/electron-v1.7.2-win32-ia32.zip' }
Tue, 13 Jun 2017 22:34:07 GMT electron-download zip exists E:\A\electron-v1.7.2-win32-ia32.zip
Tue, 13 Jun 2017 22:34:07 GMT electron-download Verifying zip with checksum
E:\A\_work\8\s\src\Standalone\gulp\gulpfile.package.js:222
            throw (err);
            ^

Error: Generated checksum for "electron-v1.7.2-win32-ia32.zip" did not match expected checksum.

By the way, I'm now using a custom build based on Electron 1.7.2, which I think is still in beta.

Also, electron-packager also appears to be obliterating my local cached copy of the package after it fails the checksum. In it's place, there's a SHASUMS256.txt-1.7.2 file.

[malept]

I don't think there are any download-specific changes between 8.5.1 and 8.7.1, you can check the NEWS file.

You need to set the checksum file as well in the cache directory, though.

[craxal]

Yeah, just tried it again with 8.5.1, and I still have the same problem.

How do I set the cache file location? I don't see any documentation on how to do that. Also, I don't have a checksum file for 1.7.2. I assume that if the checksum file isn't specified, electron-download tries to pull it from the publicly available one with the matching version. Since this Electron version isn't out yet, I'd rather skip the checksum step.

Either way, this should not be deleting my cache if the checksum fails! This sounds like a very bad bug to me.

[malept]

It's by design. It assumes that if the checksum doesn't match, the download is corrupt and should be deleted so that it can be re-downloaded.

Perhaps what should happen is that someone should provide a pull request to completely bypass electron-download, but in that case you would only be able to package one platform/arch at one time, so it may be a bit too complex to be added.

[craxal]

That would be ok if electron-download was actually downloading something. In this case, I'm just telling it to look somewhere. It shouldn't delete things from someone's machine that it didn't put there on its own.

It seems electron-packager is not well suited for custom Electron builds, which is something a lot of teams require. Since this sounds like a different issue than the one listed here, should I open a new issue?

[malept]

Electron Packager works better when a team provides a download mirror that "looks" like the official Electron download location (i.e., zipped binaries plus checksum files) instead of trying to pre-seed a cache without checksum files.

I'm not saying that I won't accept a change to allow local electron binaries (which is why this issue isn't closed), but I haven't seen a good proposal for it that doesn't require a lot of complexity to be added to Electron Packager (nor have I come up with one yet).

[develar]

I looked into it, but the macOS only caveat is a serious deterrent.

Windows and Linux are supported now (contributed) in the electron-builder and this functionally is used by users. You can use electron-builder 19.2.7 (recently some bug in this area was fixed).

[craxal]

@malept Sorry, not to sound picky, but if cache is set, I'd rather electron-packager not default to downloading from the default URL.

@develar Something to consider, but not an option for us at the moment.

[malept]

@craxal a "cache-only" feature sounds like what you want, but it's more of a feature request for electron-download, because that handles cache management.

[javaxiu]

so how is this 'cache-only' feature now? wish to use a local electron version which is custom make

[malept]

I've decided to add an electronZipDir option. Adding a single option to specify a path to a ZIP file doesn't work when you're using Packager to build multiple platform/arch combinations at once.

[malept]

The feature is in pull request #1094.

[FFY00]

It does not fully fix this. That still requires a electron zip, we would like to use the local electron installed on the system.

[malept]

we would like to use the local electron installed on the system.

The comment I raised earlier also applies to that:

Adding a single option to specify a path to a ZIP file doesn't work when you're using Packager to build multiple platform/arch combinations at once.

If you can build Electron from source, you should also be able to generate a ZIP file of the built files so you can use it with Packager. Another problem with the "locally built electron" proposal is the maintenance cost is pretty high for a feature that a very small percentage of users will use.

[FFY00]

As I stated previously.

It does not fully fix this.

Another problem with the "locally built electron" proposal is the maintenance cost is pretty high for a feature that a very small percentage of users will use.

It is not something a lot of users will use, but it is something distributions will use.

[malept]

Can you define what "distributions" are?

[FFY00]

Can you define what "distributions" are?

Linux distributions. Archlinux, Gentoo, Ubuntu, Debian, etc.

[malept]

Those that are Linux distribution package maintainers are unfortunately an extremely tiny percentage of consumers of this package. I maintain this package in my spare time, so I'm not currently willing to maintain a feature for so few users, especially if it depends on being able to have a source copy of Electron (& building it) available. I think that generating a zip file via the build scripts in the Electron repository is a reasonable tradeoff.

That being said, I have recently joined the GitHub Sponsors program, so I'm willing to maintain features that are needed by a smaller percentage of the userbase in return for monetary compensation.

Alternatively, I'm willing to accept a pull request for exactly what you're looking for (with the appropriate documentation & tests that it only works with one specific Electron platform/arch combination), on the condition that the person submitting the request is willing to maintain the feature.

[blshkv]

@malept your last reason does not make much sense. You should work with Linux maintainers to push your package into each Linux distribution and ask users to run a standard command "

it's better to deal with 10 linux distros maintainers (who know what they are doing) instead of zillions users (who should not install it without a packet manager (installer) anyway).

P.S. Thanks for the option. It's just a workaround but allowed me to fix a script.

[FFY00]

It's fine, if the maintainers don't care why should we? I've fought too much to try to get upstreams like this to make some kind of resemblance of sane decisions. Coincidently, this has always been with electron upstreams, in fact, I don't think I have ever had a positive interaction with them.

One of the greatest things about modern Linux distributions is that you have a great system to distribute projects. You have packages managers that will pull and manage all the required dependencies. Instead of using that, everyone in the electron ecosystem decided that is best if they just ship their own electron build, together with all the dependencies. This is how things work on Windows, which we are becoming closer and closer each day. Apart from being plain stupid to have 10 copies of electron and all its dependencies on a system, it is also a security issue -- when electron or one of the dependencies gets a CVE the users are not going to update your binary install.

Either way, this is me... giving up. Have a great life, I wish you the best success.

[malept]

@blshkv

You should work with Linux maintainers to push your package into each Linux distribution and ask users to run a standard command " install electron-packager".

To reiterate from my last comment, I maintain this package in my spare time. First, it's already in the npm registry, available to be installed via npm and yarn. Second, the idea of trying to add an electron-packager package to a Debian-based distribution is extremely daunting, given all of the dependencies (and I try to limit the number of dependencies). Electron Packager is meant to be installed in an Electron application as a devDependency and run as an npm script, although you are given the freedom to run it globally (either by npm install -g or npx, in the case of npm). Trying to get it into package managers is an implicit endorsement of the "install it globally" method, which has led to a lot of incorrect issues being opened, which I've been trying to avoid.

If electron-packager ends up being added as a package in a Linux distribution, great. But I'm not going to push for it.

---

I would like to remind folks that commenting about the current decisions about a "runtime mode" is off-topic for this issue and this repository. Please direct your (constructive) comments to the appropriate issue in the Electron issue tracker.

---

Finally, to reiterate another point in my last comment, so it's clear:

There's currently only one person actively working on features for this package: me, in my spare time. I personally work on adding features to this package that will benefit the most users, as that is the best use of my limited time. Most folks on Linux (I am one of them, and have been for 17 years - I was even a Gentoo user for about a decade) will download/install an Electron app from the app author. That being said, there are two options at this point:

1. Sponsor me to write and maintain the feature you're asking for. This has actually happened before with the electron-installer-snap module that generates Linux distributables for Snap stores.
2. Have either yourself or someone you've found to write _and maintain_ the feature. Remember, Electron is a community-driven project, and this module is no exception. I do not want to have a feature in this module that will bitrot because it isn't maintained. I am more than happy to help someone get their change into this module if they'll help maintain their feature.

[FFY00]

Most folks on Linux (I am one of them, and have been for 17 years - I was even a Gentoo user for about a decade) will download/install an Electron app from the app author.

That is just not true, but sure.

There's currently only one person actively working on features for this package: me, in my spare time.

You might want to move it out of the @electron namespace then.

[malept]

That is just not true, but sure.

It is true, but that's mostly because many of the popular Electron apps are proprietary. This is why stores such as the Snap store & Flathub exist. Additionally, several distributions prohibit distributing binaries that weren't built by their own infrastructure, which is kind of the point of this issue anyway.

You might want to move it out of the @electron namespace then.

Features are primarily written by me, but maintenance is by the Ecosystem WG.

Your comments are on the verge of being unproductive, I would advise that you think carefully about any further responses.

[FFY00]

It is true, but that's mostly because many of the popular Electron apps are proprietary. This is why stores such as the Snap store & Flathub exist. Additionally, several distributions prohibit distributing binaries that weren't built by their own infrastructure, which is kind of the point of this issue anyway.

I don't really have any data to back me up but from my experience, most users usually install distribution packages that just contain the prebuilt binaries provided by the upstream.

Features are primarily written by me, but maintenance is by the Ecosystem WG.

Okay then.

Your comments are on the verge of being unproductive, I would advise that you think carefully about any further responses.

What do I need to say for you to re-open the issue? Or do you want me to create another issue? I understand you don't want to work on it, but it is still a valid request.

I would love to be able to sponsor you, I would, but unfortunately I don't have the means. I think that making me feel invalidated because I don't sponsor you is not a correct position to have, especially in a upstream like electron.

Maybe this was just miscommunication but what I am trying to say is simply that I think my request is valid and, as such, this issue should not be closed.

[blshkv]

We all do what we do here (writing code and even report bugs) in spare time. We are in the same boat. @FFY00 i think the best option is to create a pull request at this point.

[CabuxaMapache]

You have it! See https://electron.github.io/electron-packager/master/interfaces/electronpackager.options.html#electronzipdir

[FFY00]

As I said above:

It does not fully fix this. That still requires a electron zip, we would like to use the local electron installed on the system.