Hi Nathan, Your comments are very helpful. Thanks for the links. Sorry to top-post, but I think it's clearer at this point.
I see better now that node-bindings is a transitional package to facilitate the move from waf to gyp. When I started to realize how flexible node-bindings is, I naturally imagined ways to "abuse" it. (I imagined that node-bindings would be integrated into core someday.) I saw it as an-purpose Ginsu knife. I'll try not to cut myself now. :) If the only platform were Un*x, I can see that waf would suffice, and I appreciate that the node community is taking multi-platform and cross-platform support seriously. I live in a heterogeneous network and a cross-platform node ecosystem is going to simplify things for me. (BTW, this a *much* bigger selling point for me than the economy of using the same language on both ends of the wire.) I don't actually mind compiling native modules, but confess I am not eager to learn packaging. So when binary modules become available via npm, I will use them. Re: global vs. local, thanks for the link to Isaac's blog. I appreciate his clearly articulated perspective. I may be a product of different environments. As is surely obvious, I do not come from a web/internet development background. But I'm aware that many popular web frameworks take a drop-copies-as-needed approach. This is an effective way to isolate change but (opinion ahead!) an expensive-in-people-time way to manage change. While copies don't preclude traceability, the cost of and maintenance potentially scales with the number of copies. Ugh. I want to treat modules like shared libs. And this has nothing to do with disk space; it's all about leverage. So I am very happy to learn that node does not force a local-only approach, even if it is the approach preferred by many/most node experts. I plan to make heavy use of 'npm link' in production and use local installations primarily in my test sandboxes before deploying. I am grateful that node is flexible and will let me work in ways that are economical for me. Thanks for the basket of clues! On Tue, Feb 14, 2012 at 12:14 AM, Nathan Rajlich <[email protected]>wrote: > On Mon, Feb 13, 2012 at 9:00 PM, C. Mundi <[email protected]> wrote: > > > > Hi. I have another naive question. Nathan has been helping me out == a > lot > > == with node-gyp and node-bindings and I want to say publicly that these > > tools are going to be ++huge for those of us forced work in > > platform-heterogeneous networks. > > I appreciate the complements :) Truly, that's what makes us devs > working on these things in our free time keep at it. > > > > > One thing I notice is that node-bindings seems designed to support the > > pattern of installing a separate copy of each required module with the > > requiring node app. This practice of multiple copies makes (made) a > certain > > amount of sense before node-bindings, because it provides one way to > ensure > > the version, platform and architecture of modules match the requiring > app. > > I think you might be misunderstanding where node-bindings fits in the > scheme of node's module system, node_modules, and npm. node-bindings > was designed as a stopgap for this transition from waf to gyp. There's > a lot of native modules out there that have waf-style require paths to > their project's bindings (like "./build/Release/bindings.node"), but > now gyp and node-gyp by default build into > "./out/Release/bindings.node" (on Unix) and "./Release/bindings.node" > (on Windows). So node-bindings simply provides a way to try these > various paths to load the first path that actually works. > > So I'm not exactly sure what you mean by "node-bindings seems designed > to support the pattern of installing a separate copy of each required > module with the requiring node app." Previously most people had their > uses compile modules with node-waf at install-time, so we didn't have > to worry about version, platform, and architecture, but now that we're > leaning towards binary distribution, we will need to think about that > (so node-bindings also attempts to solve that problem with a folder > convention, see node-ffi for an example: > https://github.com/rbranson/node-ffi/tree/master/compiled/0.6). > > But like I said, it's a stopgap solution that is nice in the meantime > but will probably be phased out by something more integrated with > node/npm. > > > > > But now (when) node-bindings does that. So what are the remaining > reasons > > to keep multiple copies of modules instead of just installing globally > > shared copies (which could still be segregated by platform)? (I have not > > studied the JavaScript runtime model, so if you tell me that two apps > > requiring the same file implies some shared state I would not be > surprised.) > > So this is where I think you're confused. npm is the one who deals > with global vs. local modules, and the bottom line is you should > always use local modules, like when using node-bindings. The -g flag > is for modules that come with some program that you would like in your > $PATH (like node-gyp), and that's it. > > > I'd like to start to understand this better, because I see benefit > > (quantifiable in dollars) to maintaining one copy of each module per > machine > > instead of one copy per app per machine. > > I'm sure Isaac can preach the philosophy of npm better than I :) > There's also this blog article from a while back: > http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-installation/ > > > > > Thanks for cluing the noob. > > > > -- > > Job Board: http://jobs.nodejs.org/ > > Posting guidelines: > > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > > You received this message because you are subscribed to the Google > > Groups "nodejs" group. > > To post to this group, send email to [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > For more options, visit this group at > > http://groups.google.com/group/nodejs?hl=en?hl=en > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
