-
Notifications
You must be signed in to change notification settings - Fork 134
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
Node.js Foundation Technical Steering Committee (TSC) Meeting 2018-07-18 #571
Comments
@ChALkeR thanks, added. |
I personally added the tsc-agenda label to this Docker WG issue: Image without npm nor yarn Definitely seems like the Docker WG is going down a path that I've heard discussed quite a bit both within the project and from developers outside of the project in various communities within the ecosystem. Since there's some demand for it at the Docker WG level and some work has already been done to achieve it, I'm curious about a few things:
Tried to follow the guideline that @addaleax described in the issue, so don't hesitate to tell me if I've done something out of order here! ❤️ |
I was not aware of a difference in the binary when built without npm. What is the difference? |
@targos to the best of my understanding, it's largely around the size of the binary – if I recall correctly, npm is about ~45mb (please, someone correct me if I'm wrong!) which is why an npm-less binary is good for the use cases I mentioned (Serverless, containers, and IoT). |
@bnb The way I see it, there are:
Both are part of the default distribution, but I don't think the |
Added nodejs/Release#341 as a reference to the issue on "Image without npm nor yarn". One thing I'd still like to have better data for is the "why". I'm guessing its the download of the image and somehow there are use cases where this happens all the time. Otherwise once an image is installed and is used for the base of other images I think the cost is shared. Added to agenda for this weeks meeting as well, adding into the issue specifics of what you'd like the TSC to discuss (as requested in the issue by @addaleax would be helpful as well) |
Regarding The Docker WG is officially chartered with the responsibility of maintaining the official Docker images. I have no qualms with them deciding (if they do) to ship a version of the image that does not bundle a package manager. I don't think there's anything for the TSC to do or worry about on this one, although I'm happy to hear things out if other TSC members disagree. Regarding the specific questions asked by @bnb:
Ignoring the "slice out npm from the binary" (we get to it below), the Docker WG is fully capable of surfacing work that the project can do to help assist and can ask the TSC or anyone else at any time. I'm not terribly concerned about trying to figure out any of that stuff for them.
If by "binary", you mean "node executable file", then there is no difference in the binary.
Again, if by "binary", you mean "node executable file", then there is no additional binary. It's the same binary. If by "binary", you mean something else, please clarify.
It may be a bit ambiguous, but in my reading of the Docker WG chartered responsibilities, the decision to support a particular Docker image is essentially delegated to the Docker WG. This is not the TSC's decision to make, IMO. If we wish to override the Docker WG on this, we'd need to de-charter them. (I'll concede that reasonable people may disagree. I tend to read delegations of responsibilities in charters as broadly as I can reasonably do so, but that may not be everyone's inclination.) In short, I don't think there's anything for the TSC to do here. (And if there is, I'm not sure it really needs to be discussed at a meeting, at least not yet. That said, I'm not suggesting that we remove it from the agenda. But if we all agree more-or-less with my assessment above, we can simply state so at the meeting and move to the next item.) |
I'd be interested in talking about whether there is interest in shipping the binary on its own or if there are people who are opposed. While the docker WG can deliver a stripped down version, them having to figure out what is safe to strip out is sub-optimal. Having said that we can have that discussion in github (nodejs/Release#341) but if we do have time to poll peoples opinions in the meeting that would not be a bad thing either. |
In a private conversation, someone pointed out that TSC doesn't seem to be terribly aware of Docker WG activities. I generally agree with this assessment. Remedies might include:
|
@Trott apologies for my lack of context on this. Most of what I mean is "shipping npm with Node.js by default". My assumption was that it gets baked into the binary, but it seems that guess was wrong. Could you clarify for me how npm gets installed on machines when you install Node.js? Whatever the answer to that question is what I meant by "binary" 😅 |
@bnb The Node.js installer (or version manager you're using or whatever) installs Similarly, if you use ls ${HOME}/.nvm/versions/node/`node -v`/bin You should get a directory listing with |
@bnb While we're at it, I'll also point out that while |
@Trott So I guess, with that framing, my questions would be something along the lines of:
That is effectively what the Docker WG is trying to do – and aligns with the other comments I've heard around bundling the npm executable script. Also, TIL: Node.js ships with npx. |
Yes, in fact for historical reasons we already do on Windows. In case folks aren't too familiar with the official Node.js distributions, we currently have installers for Windows and mac OS. On Windows we also provide the Node.js binary on its own. On all platforms (including Windows and mac OS) we have compressed archives (zip or tarballs) which contain the Node.js binary plus
Only when bundled with |
Good question, although I think the TSC will probably delegate/defer to the Release WG on that. (But not a bad use of a tiny bit of TSC time to coordinate between the groups!) |
@Trott agreed to defer to Release team (hence why nodejs/Release#341 is in Release repo) and also that we should spend a bit of time in TSC meeting. |
Moderation Team report for the week:
@nodejs/moderation @nodejs/tsc @nodejs/community-committee |
Minutes for meeting #572 |
Time
UTC Wed 18-Jul-2018 17:00 (05:00 PM):
Or in your local time:
Links
Agenda
Extracted from tsc-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/build
nodejs/node
nodejs/TSC
nodejs/docker-node
nodejs/user-feedback
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
tsc-agenda
across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.Joining the meeting
Zoom link: https://zoom.us/j/611357642
Regular password
Public participation
We stream our conference call straight to YouTube so anyone can listen to it live, it should start playing at https://www.youtube.com/c/nodejs+foundation/live when we turn it on. There's usually a short cat-herding time at the start of the meeting and then occasionally we have some quick private business to attend to before we can start recording & streaming. So be patient and it should show up.
Many of us will be on IRC in #node-dev on Freenode if you'd like to interact, we have a Q/A session scheduled at the end of the meeting if you'd like us to discuss anything in particular. @nodejs/collaborators in particular if there's anything you need from the TSC that's not worth putting on as a separate agenda item, this is a good place for that
The text was updated successfully, but these errors were encountered: