Test various combinations of build dependencies (Node, npm, and so on)

[DeeDeeG]

Real-world testing to see what combinations of build dependencies work under a clean install scenario.

All results should be obtained by running the following commands (Unix) or their Windows equivalents (with \ backslashes):

script/clean
script/bootstrap
script/build --no-bootstrap [ --create-debian-package | --create-rpm-package | --create-windows-installer ]

[DeeDeeG]

Working builds:

Upstream

Ubuntu 20.04

2ae2ef1 (with Node 10 on the system PATH)

System build dependencies (printed by script/lib/verify-machine-requirements.js during the bootstrap process):

Node:	v10.22.0
Npm:	v6.14.6
Python:	v2.7.18rc1

apm build dependencies (printed by CONFIG.getApmBinPath/apm --version during the bootstrap process):

apm  2.5.2
npm  6.14.8
node 12.4.0 x64
atom 1.50.0
python 
git 2.25.1

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0

Screenshot (click to expand):

Passing CI: https://dev.azure.com/atomcommunity/atomcommunity/_build/results?buildId=666&view=results

2ae2ef1 (with Node 10.12.0 and npm 3.10.7 on the system PATH)

System build dependencies (printed by script/lib/verify-machine-requirements.js during the bootstrap process):

Node:	v10.12.0
Npm:	v3.10.7
Python:	v2.7.18rc1

apm build dependencies (printed by CONFIG.getApmBinPath/apm --version during the bootstrap process):

apm  2.5.2
npm  6.14.8
node 12.4.0 x64
atom 1.50.0
python 
git 2.25.1

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0

Screenshot (click to expand):

Passing CI: https://dev.azure.com/atomcommunity/atomcommunity/_build/results?buildId=727&view=results

2ae2ef1 (with Node 12.16.3 on the system PATH)

System build dependencies (printed by script/lib/verify-machine-requirements.js during the bootstrap process):

Node:	v12.16.3
Npm:	v6.14.4
Python:	v2.7.18rc1

apm build dependencies (printed by CONFIG.getApmBinPath/apm --version during the bootstrap process):

apm  2.5.2
npm  6.14.8
node 12.4.0 x64
atom 1.50.0
python 
git 2.25.1

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0

Screenshot (click to expand):

Passing CI: https://dev.azure.com/atomcommunity/atomcommunity/_build/results?buildId=668&view=results

Windows 10

2ae2ef1 (with Node 10 on the system PATH)

System build dependencies (printed by script/lib/verify-machine-requirements.js during the bootstrap process):

Node:   v10.22.0
Npm:    v6.14.6
Python: v2.7.15

apm build dependencies (obtained by running C:\Users\[User]\AppData\Local\atom-dev\bin\apm-dev.cmd --version after installation):

apm  2.5.2
npm  6.14.8
node 12.4.0 x64
atom 1.52.0-dev-2ae2ef1f5
python 2.7.18
git 2.27.0.windows.1
visual studio 2015

Visual Studio install info from Settings --> Apps (click to expand):

Screenshot (click to expand):

Passing CI: https://dev.azure.com/atomcommunity/atomcommunity/_build/results?buildId=666&view=results

[DeeDeeG]

Failing builds:

Upstream

Ubuntu 20.04

2ae2ef1 (with Node 12.17 on the system PATH)

System build dependencies (printed by script/lib/verify-machine-requirements.js during the bootstrap process):

Node:	v12.17.0
Npm:	v6.14.4
Python:	v2.7.18rc1

apm build dependencies (printed by CONFIG.getApmBinPath/apm --version during the bootstrap process):

apm  2.5.2
npm  6.14.8
node 12.4.0 x64
atom 1.50.0
python 
git 2.25.1

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0
$ g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0

Error:
[Error [ERR_PACKAGE_PATH_NOT_EXPORTED] [ERR_PACKAGE_PATH_NOT_EXPORTED]: No "exports" main resolved in /home/[user]/atom/out/app/node_modules/github/node_modules/@babel/helper-compilation-targets/package.json (atom#21091)

[DeeDeeG]

Other:

-- Reserved comment --

[DeeDeeG]

Notes:

• See also: Document common build issues and errors (and their solutions) #116

[DeeDeeG]

Reserved:

-- reserved comment --

[aminya]

These should be tested in the CI environment with all the tests passing. Simply building does not mean that it works.

[DeeDeeG]

I have added links to passing CI runs with Node 10.22 on the system PATH, and with Node 12.16 on the system PATH.

(Node 10 with npm 3.10.7 builds and runs successfully for me on both Linux and Windows, on my local machine, but fails in CI for macOS and Windows.)

[DeeDeeG]

Update: Node 10.12 and npm 3.10.7 is passing CI testing on all operating systems.

[aminya]

This should be tagged as a low priority activity. This is not a sustainable activity, does not help the end-user experience, and has little benefit for Atom users. If you want to help in this regard, try to work on a script runner or a docker image so we can fix #111. Or instead, try to bump the dependencies (by adding them to package.json, CI, etc) so we get the latest fixes in our single working configuration which all users download and use.

We are just a user of the dependencies. Node, npm, Electron, and others are among them. We don't care about the range of the versions of the dependencies. We are concerned with a single configuration that promises the behavior we want.

Study this to know more:
https://ponyfoo.com/articles/immutable-npm-dependencies

With these being said, nothing discourages you to continue working on these on your personal fork and merge them to the upstream documentation repository, but please don't think that we consider this as our high or medium priority todos.

[DeeDeeG]

This testing is what proves we don't need to have a script runner. That's why it's high enough priority for me to work on. If you follow my (rather high standard of evidence) argument, the logical conclusion is: No script runner needed. And luckily, there's nothing left to test. I already did the needed tests for Node 10 and 12. To a reasonably high standard of evidence, Node 10 (10.12+) and Node 12 (Node 12.0.0 thorough 12.16) on the system can be used with no problem.

I would rather not help with the script runner, because I can't reproduce the failure modes it is designed to fix, so I have no way of knowing if it's helping.

our high or medium priority

Respectully, don't mark my higher priority todos as your lower-priority ones. This isn't your personal repo, it's a shared one. Treating it like your personal repo is defeating my attempt at collaboration, discussion, some level of consensus decision-making. Please stop overriding me in only one direction (what you say goes, what I say gets overruled). It's not constructive or conducive to collaboration.

I took your marking my high-priority task as "low-priority" as a personal slight and a sign of disrespect, at minimum toward my work, and at most toward me as a person. Please consider the impact of your actions toward a collaborator and contributor.

We can talk about what we do, and base our decisions or logic and evidence, on shared values and priorities, and consensus. We don't have to be two "lone wolves" working "individually but in parallel" in what is a supposedly team effort. There is such a thing as open collaboration and consensus-making.

The way things are now, if I want to contribute here, I have to do it over you telling me what to do and what not to do. Please work on your collaboration and communication skills. Your approach shows you don't value me as a contributor. And from the beginning I expected to be co-admin. The only reason I keep contributing is because I want Atom to succeed. But IMO you're taking me for granted and sidelining me. You can do better, but I'm not seeing it from you yet.

In summary: The work on this issue is done for now. And I don't like your choice to dismiss and devalue my work.

[aminya]

Sorry if this sounded harsh or anything, but there is a disconnect between what this organization is meant for and what you consider as your goal. This organization is named atom-ide that is "an executable" that users download which gives them an integrated development environment. This means any "feature" or "performance" improvement is along with the goal of the organization. We don't want to try to duplicate @atom organization here which is a much bigger organization with a broader goal. Any other thing that is not considered a "feature" or "performance" improvement is a low priority task.

For sure, we had to set up a CI that helps us to build and test the whole thing before we can apply our improvements, and those were priority in the beginning, but now this is mostly done, and the final important thing that affects the user experience is in-app upgrades #86.

I never think that the things you contribute to have less value, but they are not along with the goals of this organization.

Considering this specific case, you have been insisting on your points everywhere and trying to give proves for them, while at end of the day none of these is considered something that affects the final executable we want to pass to the users. It only affects the Atom developers if they are adventurous in building and like dealing with dependency hell. This pattern has been repeated in the hack Atom core issue, executable versions issue, terminal issue, test various combination versions issue, build documentation issue, etc.

If you consider the overall goal of this organization, "something" that makes the "executable" is enough for us, and anyone who wants to quickly contribute to a part of the Atom. Be it a script runner or a pinned npm version. We want a "repeatable experience" which allows us to compare the performance and features over time. The fact that some node version "works" does not help us track our goal.

Because I value your time and efforts, I suggested you work on something that is along with the goal of the organization, but it is up to you to choose. If I did not respect or value your work, I didn't care about all of these. Atom developers' circle is small now, and everyone's time can be extremely helpful if it is spent along with the overall goal.

If you want to help in this regard, try to work on a script runner or a docker image so we can fix #111. Or instead, try to bump the dependencies (by adding them to package.json, CI, etc) so we get the latest fixes in our single working configuration which all users download and use.

If you don't see your goals the same as the goal of this organization, I suggest you contribute more to @atom itself. They have a documentation repository which suits all of these.

[DeeDeeG]

I suggested this fork could be started so there was somewhere for folks to get together and work on Atom faster than the upstream maintainers were able to. I'd be sad if this fork got started, and yet despite that happening I still would have nowhere to go to collaborate with others.

If it's limited to things needed by the atom-ide-community org then there is no place for me to contribute other than a personal fork and waiting for upstream maintainers to respond. It's not what I meant when I suggested the fork.

If our goals are really that different then I'll have to stop contributing here, which I obviously don't want to do.

If you can find a place for the work I want to do (proving out basic and somewhat conservative improvements that are suitable for upstreaming), then you should be aware a head of time that that's the kind of work I want to do. If you genuinely don't want that to happen here I'll do it somewhere else. Otherwise, please, let's find a way to work together. If that's the work I'm going to contribute, then don't label it low-priority.

I'm not a highly talented programmer. Some of the features you want are not easy for me to do. But I'm great at understanding the ecosystem in ways that help me upgrade core infrastructure effectively and safely. That's what I'm good at. So that's what I tend to want to work on.

[aminya]

I think I was quite clear about the goals, and the name of the organization is self-explaining. The description of the repository also says community "builds" of Atom. There is no talking about how this is done. Atom is not a young project and we only have a limited time until GitHub decides to leave the Atom altogether. The important things that Atom needs are its "features" and "performance". We should bring Atom to a new level, but it does not matter how we get there.

That's what users care about and how people judge software in action. Rarely, some enthusiasts may be found that likes to improve something in Atom, but that is rare especially now that many of the ex-Atom developers and users have moved to other platforms.

If you feel like this does not fit your interests, it is totally fine, and you can contribute to the upstream repository. If you merge something to Atom itself, it will show up here.

[DeeDeeG]

On the narrow subject of this issue: I can close this now. The point has been made. Atom can build on lots of different dependencies and pass all tests. Specific build failures/their solutions and workarounds can go in #116.

(Slightly off-topic regarding #116: Once that documentation has been stable for a bit I might try to get it into the flight manual, but my other PR for the flight manual/docs repo has taken months now to review, so the value to me to be able to document this stuff immediately without waiting for upstream is tremendous.)

---

Regarding the broader topics that are being brought up: The problem of Atom in my view is lack of maintainership resources and lack of energy/excitement/enthusiasm. (As long as the maintainers stay active, there will be Atom. But maintainers get burned out when it's all just a backlog of PRs and issues and no activity). Our activity eases maintenance burdens and raises the level of activity and excitement around Atom. It proves the community cares and is willing to pitch in to do the work to keep Atom alive.

This fork adds further excitement by being willing to add new features more quickly and try things out. (I value that, but I can't contribute much to new features, because I'm not super talented with programming. I'm more of a build scripts/dependencies/maintenance/bug fixes person).

I don't have authority at the upstream Atom repo to review anything or merge PRs. Doing it on my own personal fork would carry no weight or clout whatsoever. Why should upstream pay attention to me, just one person, over everyone else who posts dozens of PRs a month? In contrast, having this work done in a fork that is a team effort by "the community" lends legitimacy to the work we are doing. Not waiting for upstream means they have to keep up with us, not that we have to wait for them. In a way. It puts the fire under their feet/adds urgency. (It also means we are waiting in the wings should the main repo die. Not that I ever want to see that. We are the backup team if GitHub cancels Atom development.)

And I do value your reviews of my PRs. And I try to review yours when I have somethig to add. Together, the quality of our contributions to upstream (and to this fork, too) are higher because we are able to review each-other's work. That adds more credibility to our PRs to upstream. It should keep this fork on a solid track. We have some other folks from this org pitching in with reviewing and discussion as well.

I didn't choose for you to fork atom in this org. I didn't choose to not have equal admin access as you have been given. I didn't direct things in the direction things are going. I'm just trying to go with the flow without losing my ability to shape Atom altogether. This is my only option to make big impact while not being a GitHub employee. And I'm not expecting to get hired anytime soon, so here's where it's going to be.

On that note, if I post a specific PR you can always say "I don't want this" and I'll either do it at my personal fork or at upstream. If I'm taking an angle of working on something that you know you're not going to merge, you can let me now early and I'll try to place that work at another appropriate repo. I think I can work within the framework of what you're looking to do. Whether I like it or not, you are the de-facto maintainer of this repo. I'm just doing my part to help it be a success. (I appreciate your work, and I think we collaborate well, but I wish formal control of the fork was shared more equally, and I wish you saw my vision and yours as more compatible).