deps: node-gyp@8.0.0

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.

[imatlopez]

Pretty sure this will get closed, but worth a try. Seems it needs deduping with run-script (npm/run-script#26)

v8.0.0 2021-04-03

• [0d8a6f1b19] - ci: update actions/setup-node to v2 (refactor deprecate command and add tests #2302) (Sora Morimoto) #2302
• [15a5c7d45b] - ci: migrate deprecated grammar ([BUG] <title>npm ERR! cb() never called! #2285) (Jiawen Geng) #2285
• [06ddde27f9] - deps: sync mutual dependencies with npm (DeeDeeG) #2348
• [a5fd1f41e3] - doc: add downloads badge (error cb() never called! #2352) (Jiawen Geng) #2352
• [cc1cbce056] - doc: update macOS_Catalina.md (test: add lib/shrinkwrap.js tests #2293) (iMrLopez) #2293
• [6287118fc4] - doc: updated README.md to copy easily ([BUG] cb() never called! #2281) (மனோஜ்குமார் பழனிச்சாமி) #2281
• [66c0f04467] - doc: add missing sudo to Catalina doc (Karl Horky) #2244
• [0da2e0140d] - gyp: update gyp to v0.8.1 (remove some unused modules #2355) (DeeDeeG) #2355
• [0093ec8646] - gyp: Improve our flake8 linting tests (Christian Clauss) #2356
• [a78b584236] - (SEMVER-MAJOR)gyp: remove support for Python 2 ([BUG] npm config removes _auth from .npmrc #2300) (Christian Clauss) #2300
• [c3c510d89e] - gyp: update gyp to v0.8.0 (Error when running 'npx cypress open' #2318) (Christian Clauss) #2318
• [9e1397c52e] - (SEMVER-MAJOR)gyp: update gyp to v0.7.0 ([BUG] Config environment variable forwarding breaks with false config values #2284) (Jiawen Geng) #2284
• [1bd18f3e77] - (SEMVER-MAJOR)lib: drop Python 2 support in find-python.js (Release/v7.1.2 #2333) (DeeDeeG) #2333
• [e81602ef55] - (SEMVER-MAJOR)lib: migrate requests to fetch ([BUG] postpack script runs BEFORE the tarball has been generated and moved to its final destination. #2220) (Matias Lopez) #2220
• [392b7760b4] - lib: avoid changing process.config ([BUG] NPM UPDATE removes dependencies #2322) (Michaël Zasso) #2322

[silkfire]

Opened an issue at run-script: npm/run-script#25

[wraithgar]

Dependency/subdependency updates tend to be taken care of by the npm cli team itself during releases (which is usually thursdays, so that should be today)

[imatlopez]

@wraithgar knew it was gonna get closed, hopefully at least I brought attention to this :) (please close the PR in run-script too)

[DeeDeeG]

I suppose this issue is closed. So there is apparently no action being taken right at the moment.

But I wanted to say: please ping some of the node-gyp folks, at least @rvagg, before merging node-gyp 8. I think he's hoping node-gyp version 8 has more time in the wild before being merged into npm. There were big changes around dropping Python 2, not just the request deprecation warning going away.

(I contributed a bit to some of the changes as well, so I wouldn't mind staying in the loop, personally. I will try to keep my eye out for any such PRs for bumping node-gyp in npm.)

[wraithgar]

@DeeDeeG Yes we now plan on first evaluating what the update would mean. Y'alls expertise is very appreciated. This update was NOT part of the latest release, as I had originally assumed when I made that comment. Since looking at the changes there were two things that gave us pause, one was changing how some windows cli args were handled (a situation that is already something in which we are trying to squash bugs in the cli) and of course the update to gyp itself.

[DeeDeeG]

Veering very mildly off-topic to a general comment:

Although I'm not an official member of the node-gyp team, so I don't want to get out ahead of them in remarking on process considerations, as a recurring open-source contributor to that module I extend an extra-warm welcome to anyone who maintains npm to stop by and take a look at any of my PRs there while they're open, or to drop a comment with your thoughts even after they have closed.

I am always trying to create general solutions that work for all the users. And it is always something in the back of my mind "hmm, how will this be for npm users? Does this meet the industrial-strength quality needs of Node/npm? Have I failed to anticipate something that would affect them?" And so on. Direct comments from npm maintainers would be much appreciated for when changing things that might affect npm users... (Which means basically all of node-gyp.)

Of course I try to do my best without such feedback, but when it comes to review, the earlier the better I think.

If I might be so bold as to suggest the communication between npm and node-gyp be more frequent and proactive, potentially before a new node-gyp release is cut. But I don't really know the relationship, or how much under an independent direction node-gyp is meant to be or not. (And yet of course there is the always-present reality of time constraints and limited bandwidth for communication in open-source. Nevertheless, I thought I would propose it.)

[DeeDeeG]

@wraithgar If the team has any specific concerns about the node-gyp code, I'd be interested to hear it. Especially if it involves areas of the code that I touched. For example, I'm working to improve the Python detection on Windows, which I was already the last person to update, and I'm not sure if the "changing how some windows cli args were handled" you refer to has anything to do with that?

I already heard from someone that the existing code in that area from node-gyp v8.0.0 can fail for their use-case, so while I'm working on the fix it would be great to hear from more stakeholders what they think needs to be changed or improved.

(I personally am not as familiar with the underlying gyp code, though, and I'm not super well-versed in Python. I'm not afraid to take a look at it, but no promises there. The person who did much of the gyp re-write is fairly active so they might be able to address any concerns there as well. And I'm good with manual QA testing, so if there are usage scenarios you'd like to see tested, I can try and report back some results.)

Best Regards.