The GYP issue: where, how and who to maintain

[rvagg]

So we have https://github.com/refack/GYP, I don't know what its current state is but I know things have been merged here straight into gyp/ that probably conflict with it so I assume we're in a messy out-of-sync state.

nodejs/admin#247 was closed, I guess @refack doesn't want to transfer it to the org. IMO that's in no way a prerequisite to using it as our GYP upstream so I don't consider that a problem if @refack wants to continue maintaining it under his own name.

I'd just like clarity on where GYP changes are going, who approves them, how we keep things in sync here, with an upstream and with nodejs/node.

@refack do you still have the stomach to continue with maintaining it?

@nodejs/python some input from you folks too would be great. This is well outside my comfort zone and I'd rather node-gyp be concerned with wrapping GYP, not being the primary place it's maintained. That separation of concerns would also make issues and PRs here easier to manage and we have an appropriate place to point people who want to make GYP changes instead of everything getting tangled.

[sinloss]

The nodejs/node#26620 is on progress... So I think we should wait for it?

[rvagg]

I think @refack may have lost interest in helping maintain this tooling and we might be needing an alternative solution. We also have gyp.js and ninja.js in the picture, I'm about to put up a pull request for including gyp.js (the 3rd pull request to date) and see if we can work toward an opt-in for it and gradually work to full compatibility. But we need a strategy for maintaining it too, I don't believe @indutny is interested in pursuing these two projects and it'd be good to have a collective space for a group of people to maintain them.

For now I was thinking that setting up a new lightweight github org to maintain a collection of gyp and gyp-related tools might be a good approach, at least for the short term. Pull in GYP / GYP3 (or some synthesis of what's been done here, in nodejs/node and refack/GYP), gyp.js and ninja.js if @indutny wants to give them up, and use it as an upstream for node-gyp and anything else using gyp (nodejs/node, libuv?). I'd love to hear others' thoughts on this.

[sinloss]

LGTM

[indutny]

I'd be happy to transfer both gyp.js and ninja.js to nodejs org upon request.

[bnoordhuis]

My preference would be to put our efforts into gyp.js and get rid of the python-based gyp, at least for add-ons.

TBD how to deal with Node's build system. I regret I didn't push my cmake-based fork but I ran out of time. If someone wants to dust it off and take all the credit, you're welcome. :-)

[cclauss]

Also related to nodejs/build#1789

[zuohuadong]

use GN

[zuohuadong]

@bnoordhuis
https://github.com/electron/node

Chrome has given up gyp, we should use GN. like electron.

[rvagg]

There's less than zero interest in investing in another Google produced, maintained, and gatekept tool, only to have it abandoned once an entire ecosystem is invested in it, like GYP. This goes especially for one that is only supported on a limited number of platforms. Our preference is toward more open and broadly supported and understood tools

[zuohuadong]

@rvagg
Node-gyp is a legacy of history that has been cast aside.
Just like callback, we need time to transition to async/await .
We want node.js to be better, not just usable.

Learn from Dart, deno advantages to make it even better.

[zuohuadong]

If it is not because of ecology, what language would you choose?
.net core / Dart / Go /Rust is better.
However, if node.js can do better, then does backend development also consider node.js as the first choice?

[richardlau]

@zuohuadong There's nothing mandating the use of node-gyp for addons and right now if you were writing a new addon you have other choices such as cmake-js.

We were discouraged by Google from using GN (see nodejs/TSC#648 and preceding nodejs/TSC#464).

For the thousands of existing addons that do use node-gyp this project will still need to exist (whether continuing to use the Python based gyp or transitioning to a JavaScript based implementation).

[zuohuadong]

@richardlau
We should recommend developers to use cmake or others.
The alternative node-gyp became the official recommendation.

Such as node-bazel, node-gn, node-cmake one of them.

[richardlau]

@richardlau
We should recommend developers to use cmake or others.
The alternative node-gyp became the official recommendation.

Such as node-bazel, node-gn, node-cmake one of them.

@zuohuadong I'd suggest you raise an issue over in the main Node.js repository (or PR directly against the addons docs in the main repository). This issue/repository isn't the place to discuss that.

[cclauss]

So... To get back to the issue at hand. My vote is that we pull the GYP3 changes into node-gyp. There are many solid decisions and fixes that went into GYP3 and with the inclusion of pyenv, it will make a more stable platform for continuing our Python 3 compatibility work. In the long run, we should drop the need for Python but in the near term, GYP3 is a better platform for getting to Python 3 compatibility before yearend.