atom-community / atom

:atom: Community build of the hackable text editor
https://atom-community.github.io/
MIT License
720 stars 29 forks source link

Arch Linux: Settings, Check for Updates does not work #387

Open DAC324 opened 2 years ago

DAC324 commented 2 years ago

Hello all,

having atom 1.63.0 installed and running, I just looked at Settings, Check for updates. The command for this check seems to have issues:

Fetching outdated packages and themes failed.Hide output…
spawn /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/bin/apm ENOENT
meadowsys commented 2 years ago

I think I've had this problem before while building atom. I think what the problem is is that the apm executable file is not marked as executable? maybe try running chmod +x /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/bin/apm as a workaround?

DAC324 commented 2 years ago

Looks like this feature is indeed broken to some extent:

/usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/lib/command.js:148
            throw new Error('Could not determine Electron version');
            ^

Error: Could not determine Electron version
    at /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/lib/command.js:148:19
    at /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/lib/command.js:166:20
    at /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/lib/apm.js:95:20
    at processTicksAndRejections (internal/process/task_queues.js:79:11)
DAC324 commented 2 years ago

Error: Could not determine Electron version

This can be fixed by inserting

"electronVersion": "11.5.0",

in the package.json file for apm.

--- /usr/lib/electron11/resources/app/apm/node_modules/atom-package-manager/package.json    2022-06-22 16:19:31.560885452 +0200
+++ apm/node_modules/atom-package-manager/package.json  2022-06-22 15:36:20.738929944 +0200
@@ -40,6 +40,7 @@
     "url": "https://github.com/atom-ide-community/apm/issues"
   },
   "bundleDependencies": false,
+  "electronVersion": "11.5.0",
   "dependencies": {
     "@atom/plist": "0.4.4",
     "asar-require": "0.3.0",
DAC324 commented 2 years ago

For now, I have installed the apm package separately which avoids that electron version error as well as some other glitches trying to install / update the plugins.

DeeDeeG commented 2 years ago

usr/lib/electron11/... This path will not be used in the official builds. This strikes me as an Arch-specific thing again.

The official Atom builds bundle an electron binary that becomes renamed to be the atom binary. The Arch build attempts to use Electron and apm as separate packages. This is all a custom departure from the official build process specific to the way they are trying to package it for Arch.

Official builds will have a path like /usr/share/atom/... for the location of the atom binary and all the app's resources.

And indeed, official apm will not attempt to use npm 7 or newer, as it does break apm. I have a branch of apm set up to use npm 7, but there's not a ton of benefit to that, IMO, and I didn't want to have to debug possible quirks from the major re-write of npm that happened in npm 7.x, so I personally didn't push for moving to npm 7. As you mentioned before an edit, it looks like npm 8 won't be usable in apm, at least without a major re-architecturing of apm to only spawn npm as a sub-process rather than importing its bits into apm's JS code.

You might consider making one issue for all Arch-related issues you are having. If it doesn't also apply to Debian, Ubuntu, Fedora or other RPM-based distros, we can assume it is Arch-specific. And as of before the sunset, neither upstream/official Atom nor this fork made serious efforts to build on Arch. It takes a lot of effort, splitting things apart into multiple packages isn't how the Atom repo is designed to be built, and there aren't as many users of Arch as, say Ubuntu and Fedora. Arch has always required Arch-specific patches to build as separate packages and depend on the system Electron package like that. So Arch-specific efforts should be clearly marked as such so Arch users can find them and pool efforts in one place. And so it's not confused as being an issue across other Linux distros or even a Mac+Windows thing as well.