Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deps: node-gyp@8.0.0 #3030

Closed
wants to merge 1 commit into from
Closed

deps: node-gyp@8.0.0 #3030

wants to merge 1 commit into from

Conversation

imatlopez
Copy link

@imatlopez imatlopez commented Apr 5, 2021

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

@imatlopez imatlopez requested a review from a team as a code owner April 5, 2021 13:12
@darcyclarke darcyclarke added semver:patch semver patch level for changes Release 7.x work is associated with a specific npm 7 release Needs Review labels Apr 7, 2021
@silkfire
Copy link

silkfire commented Apr 7, 2021

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

@imatlopez imatlopez changed the title node-gyp@8.0.0 deps: node-gyp@8.0.0 Apr 8, 2021
@wraithgar
Copy link
Member

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)

@wraithgar wraithgar closed this Apr 8, 2021
@imatlopez
Copy link
Author

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

@DeeDeeG
Copy link

DeeDeeG commented Apr 9, 2021

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
Copy link
Member

@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
Copy link

DeeDeeG commented Apr 9, 2021

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
Copy link

DeeDeeG commented Apr 11, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release 7.x work is associated with a specific npm 7 release semver:patch semver patch level for changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants