Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flat Tree Dependency Resolution in Npm v3

docs.npmjs.com

Post reply on HN
Print view View original

111–120 of 123 posts

Re: Flat Tree Dependency Resolution in Npm v3

#111

Post by spinningarrow »

davexunit wrote: post #97
nawitus wrote: post #64

Earlier quoted context omitted.

Language specific package managers seem to actually work in real life and are cross platform, e.g. npm. But I'm not aware of anything for e.g. C++ which would offer the features of npm (mainly installing dependencies with a single command and supporting GNU/Linux, OS X and Windows). Is there a single non-language specific package manager which is cross platform, and supports a large percentage of packages for a given…

>'m not aware of a single successful language-independent package manager Ummmm... dpkg and yum? You know, the package managers that manage the software on everyone's production servers. Or do these not count because they don't work on Windows or something?

Yes, his previous sentence specifically mentioned 'cross-platform'.

Re: Flat Tree Dependency Resolution in Npm v3

#112

Post by DCoder »

bhouston wrote: post #100

I do not understand why they just didn't have a two level directory structure: node_modules/[module_name]/[version] Then it would be flat and support multiple versions of the same module in a way that is completely deterministic and also fully deduplicated. This new system is unnecessarily complex.

With that approach, the module loader needs to know which version of a module to load for you when you require() something - in the general case that can't be done without parsing your package.json . This would require changes to node itself, not just npm, as well as all the external tools that implemented node's current require algorithm.

Re: Flat Tree Dependency Resolution in Npm v3

#113

Post by moron4hire »

city41 wrote: post #99
moron4hire wrote: post #89

Earlier quoted context omitted.

I don't think you realize just how different even various Linux distros running even the same kernel can be, and I think you're giving waaay too much credit to OSX/Linux for being "alike". MAKE build scripts have notoriously been a mess for decades because of the differences between distros. Any reasonable language has the ability to query all of the platform-specific stuff directly from the standard library. You can…

I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/node…

There is no reason building Windows software has to be this hard, other than the maintainer just not putting even a reasonable amount of effort into it.

When developers are hostile torwards Windows, this is the result. This doesn't do anything to Microsoft, this just hurts other developers and users.

Re: Flat Tree Dependency Resolution in Npm v3

#114

Post by bcoates »

frik wrote: post #11
shill wrote: post #4

This will help Windows users who have filesystem and zip compression issues with deeply nested dependency trees.

Windows to this day still has the 260 chars path limit. http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx... https://en.wikipedia.org/wiki/Long_filename Microsoft should finally fix such old limitations (-> update WinAPI), instead adding work arounds to third party projects like Nodejs. https://github.com/Microsoft/nodejstools/issues/69 They could also improve the command line shell (cmd.exe) that also Pow…

That's a serious breaking change to existing windows programs and can safely be put in the "never going to happen" pile.

Re: Flat Tree Dependency Resolution in Npm v3

#115

Post by tonyarkles »

jameshart wrote: post #76
city41 wrote: post #53

Earlier quoted context omitted.

Windows is very much an outlier in the world of software development. Unless you're specifically using Microsoft tech (ie .NET and all that), then you're in a world dominated by Linux and OSX. I'm annoyed that Microsoft insists on going forward with a proprietary OS that does not conform to standards that pretty much every single other OS does. Sure, platform specific issues do happen for other OSes, but they are rar…

Seems to me that reasonable people could disagree over whether POSIX should be considered the be-all and end-all of OS standardization.

I wouldn't call it the be-all and end-all, but rather the bare minimum. "If you implement this API spec, there's a good chance a lot of software can successfully build"

Re: Flat Tree Dependency Resolution in Npm v3

#116

Post by acjohnson55 »

dc2 wrote: post #23
theGimp wrote: post #13

That's a great improvement over the old behavior, but I'm wondering why the team didn't go a different route. Why not always store packages at the top level, and create a directory for each version that's required? For example: directory "A" contains two subdirectories: "v0.1.0" and "v0.1.1"

When your actual Node .js file runs `require('a')`, it has no context to determine which version it is requiring. To expect Node to look for a package.json file at runtime is absurd. This presents a problem.

Why is this absurd? Order-dependent installation and massive node_modules trees seem a lot more absurd to me. Why not just have node parse all the package.json's (or, perhaps, npm-shrinkwrap.json) at startup time? Then `require` could easily parse that and know what dependency version from the flat node_modules to deliver.

Re: Flat Tree Dependency Resolution in Npm v3

#117

Post by gelasio »

city41 wrote: post #99
moron4hire wrote: post #89

Earlier quoted context omitted.

I don't think you realize just how different even various Linux distros running even the same kernel can be, and I think you're giving waaay too much credit to OSX/Linux for being "alike". MAKE build scripts have notoriously been a mess for decades because of the differences between distros. Any reasonable language has the ability to query all of the platform-specific stuff directly from the standard library. You can…

I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/node…

Other projects have to do a lot of work to support OS X too. So I guess I still don't see your point. Electron, for instance, had to program an entirely different object model to represent OS X's kludgy global menu bar when every other OS has menus attached to application windows.

I can't believe your defending OS X though when Apple makes you buy a whole computer from them to use it...meanwhile I can run a 6 month trial of Windows (over and over again) on any virtual machine. Honestly, it's way more work to support OS X than Windows if you really bother to look at it.

Re: Flat Tree Dependency Resolution in Npm v3

#118

Post by city41 »

moron4hire wrote: post #113
city41 wrote: post #99

Earlier quoted context omitted.

I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/node…

There is no reason building Windows software has to be this hard, other than the maintainer just not putting even a reasonable amount of effort into it. When developers are hostile torwards Windows, this is the result. This doesn't do anything to Microsoft, this just hurts other developers and users.

gyp was created by Google for building Chrome. I would guess they've put a decent amount of effort into it.

Re: Flat Tree Dependency Resolution in Npm v3

#119

Post by city41 »

gelasio wrote: post #117
city41 wrote: post #99

Earlier quoted context omitted.

I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/node…

Other projects have to do a lot of work to support OS X too. So I guess I still don't see your point. Electron, for instance, had to program an entirely different object model to represent OS X's kludgy global menu bar when every other OS has menus attached to application windows. I can't believe your defending OS X though when Apple makes you buy a whole computer from them to use it...meanwhile I can run a 6 month t…

Apple is definitely not innocent here. They force a lot of terrible decisions too. I think ultimately though, this conversation boils down to my bias and experience versus your bias and experience.

Re: Flat Tree Dependency Resolution in Npm v3

#120

Post by fapjacks »

ag_dubs wrote: post #93
city41 wrote: post #49

Earlier quoted context omitted.

I think this is the wrong approach. We shouldn't pick up MS's slack, MS should. This just enforces the current situation and keeps enabling MS to ignore the problem.

you might also consider the fact that OSX machines are expensive. and the education for learning linux is generally expensive or not accessible. so supporting windows also supports ... poor people, people from different countries that have different economies, etc. should we not pick up capitalism's slack? capitalism sure isn't going to pick up its own slack, err... systemic method of restricting underprivileged/poor…

> the education for learning linux is generally expensive or not accessible

Wow, this is incredibly wrong. The cost of education to learn Linux is living in a country where you are likely to be literate and have access to a computer. That is literally the cost to learn Linux, guy. There is nothing like an MSDN subscription for Linux documentation.

Post reply on HN