Live data from Hacker News

Flat Tree Dependency Resolution in Npm v3

docs.npmjs.com

71–80 of 123 posts

Re: Flat Tree Dependency Resolution in Npm v3

#71
post #64

Earlier quoted context omitted.

>This is what we did with Dart's package manager[1]. It works like Bundler where it finds a single set of package versions that satisfy all of the constraints and there are no duplicate packages. Constraint solving is the status quo, and I am strongly opposed to it. Rather than saying "I want foo >= 1.0" in a package manager, you should have the build system test the environment for the features you need. This is wha…

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…

The aforementioned GNU Guix and the similar Nix project are exactly that: Cross-platform (mostly, at least Nix requires a unixy layer on Windows) language-independent package managers.

One could argue that they aren't "successful" (in that they don't have all the packages you might want), but they are still quite new and are pretty different from traditional package managers. I believe that Nix/Guix are the future, but a future that will take some time to become widespread.

Re: Flat Tree Dependency Resolution in Npm v3

#72
post #12

Earlier quoted context omitted.

Why do dev communities have to continually pay the Windows tax? If Microsoft keeps insisting on being an outlier in the world of OSes, shouldn't they be the ones burdened? I gotta say, as someone who never ever uses Windows but maintains a couple of open source packages, I'm really sick of the Windows only problems that crop up.

As someone who has no choice but to use Windows at work, I'm really sick of all the problems that crop up because so many tools use were written by people who won't use Windows and haven't tested anything on it.

Yes, npm is very problematic/buggy on Windows. I wasted many hours because of https://github.com/npm/npm/issues/9696 (meaning any build on visual studio online breaks ~50% of the time simply running 'npm install').

Microsoft should finally fix the MAX_PATH issue in Windows, but npm should just fix their software: it's too important to be that buggy.

Re: Flat Tree Dependency Resolution in Npm v3

#73
post #39
post #35

Earlier quoted context omitted.

This "penalty" you propose would be a cosmetic thing, it wouldn't really make a difference. Many devs would choose to use the module as a dependency of their modules. The real solution to the sub-dependency-insanity of npm is ... use fewer dependencies. Don't use dependencies that have sub-dependencies. Write more code to directly solve your problem. This is a viewpoint you won't often hear, because it comes from som…

I wouldn't recommend using fewer dependencies, but smaller ones. One of the best features of npm is that it solves the "dependency hell" problem. You can depend on modules freely and not worry about making it harder for users of your module to install it. The issue comes when people create these huge "do-everything" modules. This is worth a read: https://github.com/sindresorhus/ama/issues/10#issuecomment-1...

That just creates a situation where you depend on an insane number of dependencies and your npm install takes 10 minutes.

Re: Flat Tree Dependency Resolution in Npm v3

#74
Jspm solves this by installing the module in a directory appending the package version. There is no maximally flat tree, the tree is 100% flat. At most there are several versions of the same package side by side, but no nesting.

It even supports circular dependencies.

Re: Flat Tree Dependency Resolution in Npm v3

#75
post #66
post #56

Earlier quoted context omitted.

I don't see how a project like Spectacle, which is OSX specific, relates. If someone wants to make an OS specific project, more power to them. The issue arises on platforms that span OSes, and they just never quite span onto Windows correctly. Microsoft is very happy that Node, Java, Clojure, etc work on Windows. It helps them a lot. But they make little to no effort to help bridge the gap, they usually leave that to…

I believe Microsoft worked to get Node.js supported on Windows.

Not just that, but they're working on making Node work with Chakra.

Re: Flat Tree Dependency Resolution in Npm v3

#76
post #53
post #50

Earlier quoted context omitted.

It sounds like you're getting annoyed that the devs of certain projects like Node.js have chosen to support an OS that you don't use without asking you about it first... If you're in control of the project - you have every right to ignore Windows users. If you're not in control, then you really have zero right to complain. Zero. Devs certainly aren't forced to "pay the Windows tax" in any way. Plenty of OSS projects…

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.

Re: Flat Tree Dependency Resolution in Npm v3

#77
post #71
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…

The aforementioned GNU Guix and the similar Nix project are exactly that: Cross-platform (mostly, at least Nix requires a unixy layer on Windows) language-independent package managers. One could argue that they aren't "successful" (in that they don't have all the packages you might want), but they are still quite new and are pretty different from traditional package managers. I believe that Nix/Guix are the future, b…

> Cross-platform (mostly, at least Nix requires a unixy layer on Windows)

Not good enough, language package managers must work on Windows, with a regular command prompt.

Re: Flat Tree Dependency Resolution in Npm v3

#78
post #63

Sorry to be negative but one of the things that I hate more than anything in my software development work is typing "npm install blah" and almost always being hit with wave after wave of errors typically related to dependencies. I don't know why it happens and I don't care I just wish they'd fix it. So many, many errors. Go on, try installing X packages at random using npm - did they install cleanly? The baseline out…

NPM has some dumb legacy features like optionalDependencies. optionalDependencies are often native code dependencies that might fail but the package is still usable, maybe just some specific feature isn't. That's the most common reason I come across for errors.

Re: Flat Tree Dependency Resolution in Npm v3

#79
post #66

Earlier quoted context omitted.

I believe Microsoft worked to get Node.js supported on Windows.

Not just that, but they're working on making Node work with Chakra.

Can they make it so I can spawn a process and not worry about whether I'm spawning on unix or Windows?

Re: Flat Tree Dependency Resolution in Npm v3

#80
post #9
post #7

Earlier quoted context omitted.

Which there will be because everyone uses --save so each module has the version around when they added the module.

--save adds the fairly loose ^ version number, so any major version should match, so less conflicts than if you'd added an exact version match, or a ~ match

A good percentage of npm modules are <1.0.0 so you're very likely to get dupes.
Post reply on HN