-
-
Notifications
You must be signed in to change notification settings - Fork 11.3k
Conversation
Yeh, we could probably split this somewhere into a
Yeh, this is making me feel like we should wait until the patch is upstreamed before we include this. Another concern with this is that we have Thanks for the really comprehensive and considerate work here. It's much appreciated and you're massively accelerating the rate at which |
Ok removing patches from the de-keged PRs (this one and, #36343) as they won't be needed for much longer. In the mean time, can we include the patch here #36357 now that its been put behind a flag? This would make the existing iojs formula a drastically more useful in its current state while we wait for nodejs/node-gyp#564 to land and can go ahead with, most likely, this PR. I'll start on npm is quick to install/update and hard to break, so the chance of rolling back or being pushed forward during an parallel install or formula update isn't that big of a deal IME. Also the current node formula has this same behavior. We could add the caveat to give a heads up about this:
Thank you for your feedback and support. ❤️ homebrew & node+iojs so its been a fun learning experience for me |
I took a rough pass at extracting most of the npm install code, but I did't put a lot of thought into it. Feedback welcome. |
There are two ways to bring in npm:
I can't remember where @DomT4 and I last left things when we were discussing this, but it would be helpful to have some support from the formula for whichever approach you adopt. The reasons for choosing one versus the other have mostly to do with where you expect issues to be upstreamed, so as the person in charge of the npm issue tracker, I vote for 2. I'm happy to contribute work towards making this happen and will point out that there is a releases feed that could help with some of this automation. |
@othiym23 is there a url we can pull in from and always get the latest version? IE |
At the moment we're serving up the latest stable npm tarball in the Node formula every time Node is released, and I manually push a PR to update it and enforce the update onto users via a formula Re iojs, our prior discussion was left open-ended, but we were discussing sticking it in
Homebrew generally doesn't do this because it doesn't allow HB to checksum the tarball, and it doesn't allow HB to know with any certainty that x version of
We did this before and we scrapped it. It was semi-problematic and unreliable 😢. |
Darn.. ok. I guess keeping on top of the distributed npm version, and really clear caveats seems to be a decent solution. |
I don't remember what the issues were, but if this is true (and the issues can't be worked around), then my vote switches to coupling the version of npm to match what's distributed with the corresponding version of io.js. So far, io.js has a much steadier release cadence than Joyent Node, and this means that we're less likely to see the issue where the bundled npm is significantly out of date compared to the latest release from the npm team. What I really don't want to happen is for Homebrew to in effect create a new distribution of Node, where the people who support npm have to keep an eye on which version of npm Homebrew is currently bundling. Both Homebrew and npm lose in a situation where we have to keep a close eye on what each other are doing. |
I don't think a close eye is that critical. Just as long as the distributed version is pretty close, and worst case scenario, as close as it needs to successfully update to latest. Now that I have a better idea of how npm is handled in the formula, I'm willing to help keep it as close as possible along with everyone else who has. I think the following improvements to the caveats would help too:
|
I disagree very strongly. Remember that npm has a firehose of incoming issues, and that end users are maybe not the best at getting all the relevant details together before filing issues (I am being extremely generous and polite here). If a Homebrew formula for Node or io.js gets out of sync in some kind of breaking way, it is absolutely material information to the people triaging incoming npm issues that the users behind a burst of incoming issues are all running Homebrew. Those people then have to come to the Homebrew issue tracker or look at the git history of the formula and try to figure out what happened. This is not a theoretical concern, as I've had to do something along those lines several times in the year that I've been working on npm full-time (see also: the npm issues you link to in the OP). This is why I'm advocating having a definite solution one way or the other: either keep the npm version in lockstep with what's bundled with io.js (preferably using the npm that's bundled in the io.js tarball, although I understand why the current formula doesn't do that), or installing / upgrading to
IMO putting stuff in caveats is next to useless. End users pay some attention to them, maybe (if you run |
Personally, I'm +1 on automatically running |
FWIW, My word on this isn't anywhere near being final. The maintainers are free to override me as frequently as they like 😸. I feel personally like it negates the bottled npm in certain ways, but I very much doubt that's a show-stopper.
This works for me at least. I'm happier matching I'll probably duck out of this issue for a while. I'm trying to avoid the whole Node/iojs situation as best I can for the sake of not annoying everyone here. Feel free to tag me back in if there's any specific issues I can be useful on. |
@DomT4 Any advice on the |
Not in our experience. It broke for end-users relatively often. It's not reliable enough for me to be comfortable doing this for a while (maybe ever because it's not in keeping with what we do with e.g. |
Just to repeat myself from #36357 (comment): adding this patch to |
I'd like to get some more upstream confirmation on what the relationship between Node and iojs is. There seems to be a lot of talk about potentially merging back together in the future, and I'm kinda worried about taking big steps only for Brew to have to undo them in 6 months or a year's time for x,y or z reason. But I don't think that's reason to stop pondering if we can't handle Have you had the chance to put it through local testing yet? |
Personally I'm not super concerned about this.
Yes, this is what makes me lean towards not making changes unless we have to. |
That's cool. It's just a personal kink, but it's not something I'm overly grumbily about, and at the end of the day, it's something you guys can override me on. No challenge from me against what you or the other maintainers feel best here. Will try to productively contribute where I can, or where I'm asked. |
That was my understanding. Currently this PR does not run an update on Does anyone happen to know more specifically what kinds of issues were going on? The state of npm has improved massively and rapidly over the last couple years. I bet it might be worth revisiting historic issues and compare them to the situation today.
Understand. Closed it. If people really want
Here are some key articles if interested: |
Rebased to capture #36518 changes. (or should that have been a merge?) |
@bcomnes Rebase is good. What's the |
Still in the works. |
Rebased and added one more additional npm test to test a small native extension install. |
Thanks for the rebase! I like how this is going, It's looking good. Any news from upstream on the |
Still waiting on |
Version bump |
This PR - takes iojs out of keg-only - conflicts node and iojs - does not patch npm - Added NPM install code to language/javascript.rb - Added npm caveats to iojs and node formula based off of python caveats. - incorporated 1580f8b change Signed-off-by: Bret Comnes <bcomnes@gmail.com> Update npm caveats
@bcomnes Can you go into a little detail about how today's confirmation of the merge is going to change things, if at all? The convergence document seems to say that Node will continue, iojs will continue, but a third Node branch of merged Node/iojs origin will be created? Are we looking at a situation where the iojs formula goes away in favour of the Node formula (or vice versa), or a third Node-related formula being created for the converged branch entirely, or something else? Sorry, It's late and my head is 😫. Just trying to grab some idea as to what the end result for Homebrew is here and what, if anything, we need to do to prepare for it. |
I'll have to catch up myself! TY for the heads up. |
Thanks. The amount of documentation covering everything is immense. It looks like I guess the question is, and probably needs @MikeMcQuaid's input, if a It looks like the
But the last one could be tricky. They seem fond of the I'll read through some more of the documentation progressively. I'm already git-tracking all three branches. None of this is super-urgent, it looks like |
@DomT4++ I'll have to look into it more tomorrow AM most likely. Bet time for me. Giving you collaborator access to this branch/PR in the event it becomes useful but needs some changes before merging and I'm not around. |
Thanks. No worries and no rush. I'm just being overly-cautious about not being caught out on a major Node ecosystem shift again, the |
I'd say we go for Got to LOL about this whole thing, really, given the |
Node gyp was updated in npm! Not sure what it all means yet, https://github.com/npm/npm/releases/tag/v2.11.1 I'll post what I find out, but hopefully the patch issue was addressed. UPDATE: Nope, header files and floating patch still an issue. |
Patching is no longer an issue as of npm 2.6.1 / iojs 1.5.0. |
Cool! Happy for this to be no longer keg-only then. |
I'm not sure why people think the landing of nodejs/node#990 implies that the npm team is not still landing floating patches with each new version of npm when it's merged into io.js, but that isn't the case. Unless and until the changes related to |
@othiym23 Thanks for the clarification. Sorry I got carried away and started the confusion. |
Just to throw an update in here from what I can gather: Iojs and node are merging. The next version of node beyond 0.12 will be called node, but will be some some version of iojs. What this next node release will look like is yet to be seen. I speculate node will be a stable branch and iojs will be more cutting edge. We shall see! EDIT: Yes, this appears about right: https://medium.com/@nodesource/essential-steps-long-term-support-for-node-js-8ecf7514dbd |
nodejs and iojs have merged into v4.0.0 Here is a PR for upgrading node to v4.0.0: #43725 To try it out you can use https://github.com/hmalphettes/homebrew-node:
|
I will close this PR for the time being. Nice work everyone. Happy to see thing start to simplify again. |
Thank you for all your work on this @bcomnes! Really appreciate you working with us patiently and helping clarify some of the Node/Iojs development process ❤️ |
This is an alternative to #36343 that brings the following qualities:
This PR:
Issues that still need resolution
Library/Homebrew/language/javascript.rb
and share between node and iojs formula. (Anyone feel free to hop in on this one! I don't have time right now)node-gyp
patch to landWhy this arrangement works well
(except for the current patch).npm updating itself wont break patchWackiness
Massive DRY violation. Can thenpm
install code be separated out somehow?Patching resources is a tad funky. This would be cleaned up by Patching external resources #31508 (comment)Patching one formula but not the other breaks the linking/unlinking dance with both formula installed./usr/local/lib/node_modules/npm
Current iojs formula discussions
Adds flag to patch npm install for iojs compatibility #36357 Adds flag to patch npm install for iojs compatibilityNode, iojs and npm formula resolution #36343 Node, iojs and npm formula resolutionworking iojs taps
Past iojs formula discussions
npm formula issues: