-
-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add an option to use local electron binaries #187
Comments
+1 |
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 |
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 |
FYI, you can download via the |
What if I don't want to use one of the official releases? What if you want to use your own build of Electron? |
This comment has been minimized.
This comment has been minimized.
@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 |
@craxal Run Electron Packager with |
@craxal Set |
@malept OK, it seems to work for a Linux machine, at least. It can see the .zip, and I saw no download progress bar. |
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.
By the way, I'm now using a custom build based on Electron 1.7.2, which I think is still in beta. Also, |
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. |
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, Either way, this should not be deleting my cache if the checksum fails! This sounds like a very bad bug to me. |
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. |
That would be ok if It seems |
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). |
This comment has been minimized.
This comment has been minimized.
@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. |
so how is this 'cache-only' feature now? wish to use a local electron version which is custom make |
I've decided to add an |
The feature is in pull request #1094. |
It does not fully fix this. That still requires a electron zip, we would like to use the local electron installed on the system. |
The comment I raised earlier also applies to that:
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. |
As I stated previously.
It is not something a lot of users will use, but it is something distributions will use. |
Can you define what "distributions" are? |
Linux distributions. Archlinux, Gentoo, Ubuntu, Debian, etc. |
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. |
… electronZipDir option, electron/packager#187
@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 "<installer> install electron-packager". 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. |
This comment has been minimized.
This comment has been minimized.
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 If 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:
|
That is just not true, but sure.
You might want to move it out of the @electron namespace then. |
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.
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. |
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.
Okay then.
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. |
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. |
As I said above:
|
Right now
electron-packager
can only be used with official releases (dowloaded withelectron-download
). I would be interested in using it with locally built binaries (instead of specifyingversion
, we would specifybinary-path
?).The text was updated successfully, but these errors were encountered: