chore: add npm support

[XadillaX]

Someday we may import gyp-next as an npm package. just like clang-format. Even, we can replace this in node repo.

[gengjiawen]

Actually node-gyp got the full clone, maybe redundant for npm package. https://github.com/nodejs/node-gyp/tree/master/gyp

[XadillaX]

Actually node-gyp got the full clone, maybe redundant for npm package. https://github.com/nodejs/node-gyp/tree/master/gyp

After making it an npm package, node-gyp may simply depend on it in "dependencies" field.

[cclauss]

@ryzokuken Why are so many tests failing? Do we need to work on our tests? Rerunning failing tests... Still fail.

[cclauss]

What is the relationship between detect-python-interpreter and find-python.js ? Do they both have the same kind of test coverage because gyp gets run on a lot of esoteric hardware and OSes these daze.

[XadillaX]

What is the relationship between detect-python-interpreter and find-python.js ? Do they both have the same kind of test coverage because gyp gets run on a lot of esoteric hardware and OSes these daze.

detect-python-interpreter only simply tests python* one by one and returns the first succeeded one on python* -v.

Maybe we can improve to pass the priority in detect-python-interpreter.

[targos]

What issue does it solve?

[XadillaX]

What issue does it solve?

1. Projects depend on it can remove the hard copy, and use it in a package.json. E.g. Node.js (like tools: update clang-format 1.6.0 to 1.7.0 node#42724)
2. node-gyp may replace the hard copy with a dependency.

[targos]

I don't know if it something that node-gyp wants, but from the Node.js perspective, it is unlikely to happen, as node needs to copy so we can build it offline from the tarball.

[ryzokuken]

@ryzokuken Why are so many tests failing? Do we need to work on our tests? Rerunning failing tests... Still fail.

@cclauss Looks like changes were made to gyp in Node without properly being upstreamed here first: nodejs/node#40735.

@targos I am sympathetic to the use-case of building Node.js from a tarball but how could we keep gyp-next in the tree and avoid this from happening over and over again? Perhaps include it as a git submodule instead?

[targos]

how could we keep gyp-next in the tree and avoid this from happening over and over again?

The same question applies to all our bundled dependencies. I don't have a perfect solution, but for now reviewers should pay attention to this.
BTW, I tried to do nodejs/node#40735 myself, but the changes are really non-trivial and I'm afraid to introduce them here and break node-gyp users.

[targos]

node-gyp integration errors should be fixed in the node-gyp repo: not ok 2 - request to https://localhost:49373/ failed, reason: certificate has expired

Edit: I opened nodejs/node-gyp#2645

[XadillaX]

@targos https://github.com/nodejs/node/tree/master/tools/node_modules/eslint

ESLint stays in node_modules and be added to repository tree. Maybe we can do it for gyp-next either?

[targos]

@targos https://github.com/nodejs/node/tree/master/tools/node_modules/eslint

ESLint stays in node_modules and be added to repository tree. Maybe we can do it for gyp-next either?

Maybe, but I don't see any advantage to doing so. And if we merge this, we need to manage npm releases, which is more burden for a project that has almost no maintainer.

[ryzokuken]

the changes are really non-trivial and I'm afraid to introduce them here and break node-gyp users.

fair point.

And if we merge this, we need to manage npm releases, which is more burden for a project that has almost no maintainer.

I agree. This is the opposite of what we want, we should be instead reducing the maintenance cost of this project as much as possible.

[richardlau]

I don't think this is going to make things any better for Node.js core.

For node-gyp though it might make maintenance of node-gyp easier (albeit slightly increasing the maintenance burden here) -- at the moment there is a lot of confusion over gyp-next vs node-gyp and we frequently get PR's opened in node-gyp that are actually gyp changes that should be made here. Doing this and then making gyp-next a dependency for node-gyp would allow us to remove the gyp copy in node-gyp so the only code left there would be the Node.js wrapper.

[ryzokuken]

@richardlau would we need npm for that? Couldn't that also be done with a git submodule for example?

[richardlau]

@richardlau would we need npm for that? Couldn't that also be done with a git submodule for example?

Other package managers are available 🙂. The point would be to make, from node-gyp's point of view, gyp-next the same as any other dependency node-gyp currently has. You already need to npm install (or your package manager's equivalent) node-gyp in order to use it or run its tests if maintaining it. We do not, for example, vendor in the tar module into node-gyp. The main reason gyp was vendored into node-gyp was that when gyp was maintained by Google it was not versioned or published to a package repository.

[targos]

I won't object to this PR, but keep in mind that if we merge, someone's going to have to setup and maintain the npm release.

[cclauss]

Sorry but I am going to object to this PR.

detect-python-interpreter only tells us if some version of Python 2 or 3 is installed. It does not tell us what that version is and if that version meets our build requirements. We do not need additional support requests from users who are attempting to build with legacy Python.

Also, let's fix the tests before approving a bunch more PRs with failing tests.