4 ms·

No clear winner when npm has more dots than all of the others? What's the point in even comparing them, then? I think npm's approach is pretty cool -- it sacri

No clear winner when npm has more dots than all of the others? What's the point in even comparing them, then? I think npm's approach is pretty cool -- it sacrifices disk space for portability (package dependencies are always installed in the node_packages directory of the package root), so while you might effectively have 3 or 4 of the same coffee-script folder in your install, you don't have to worry about virtual environments for development and you don't have to worry about dependency upgrades breaking some other package. I think the nature of javascript allows this to be effective considering that many dependencies are smallish snippets of code.

reiz 13y ago
No. There is no clear winner. The point is to show how other communities are solving this problem. By comparing them you get maybe new ideas. NPM is doing a pretty good job. If they would sign their packages and make the licenses mandatory it would be the clear winner. Only 2 points are missing.
moondowner 13y ago
More dots means the author has deeper understanding in npm and thus found more to write about it.
- reiz 13y ago
  Actually I'm using in my daily work more Bundler and Maven. But I'm anyway a big fan of NPM.
blueblob 13y ago
It appears to be biased towards npm given that one set of dots is "JSON Based" and could have just as easily been "XML Based." I mean strictly the chart, not the article. The article seemed fair.
- reiz 13y ago
  In the first version of the chart I had column for "XML". But it didn't looked good, because there was only 1 candidate for XML and that was Maven. That's why I dropped it again. Beside that I think that XML is kind of overkill for dependency management. JSON is just fine, much smaller and easy to read. Having the dependency definition in native code (Python, Groovy, whatever) is not a good decision, in my opinion, because that's a source for security vulnerabilities.
  - blueblob 13y ago
    I understand, you make a choice that summarizes the data the best that you can; I wasn't trying to attack you. I was trying to point out that choice of a language for the representation of your configuration is exactly that, a choice. I don't know that I agree that having the dependency definition in native code is a source of vulnerabilities; it could make the definition easier to write for people packaging code in that language. Also, I think JSON could be considered native code for npm since it is written in nodejs/javascript.
    - reiz 13y ago
      I didn't felt attacked. I appreciate feedback ;-) And you are right. The choice of a language is just a choice. Dependency definition in native code is always a security vulnerability, because by resolving the dependencies you execute unknown code, specially if the packages are not signed. I could for example publish a python package on PyPI with a setup.py which contains code to delete files on your hard disk. At the moment my setup.py gets executed on your machine you will lose some files. Something like that can not happen with JSON, XML or YML.
paulhodge 13y ago
> package dependencies are always installed in the node_packages directory of the package root Usually but not always. You can also have peer dependencies: http://blog.nodejs.org/2013/02/07/peer-dependencies/ http://blog.nodejs.org/2013/02/07/peer-dependencies/

reiz 13y ago

No. There is no clear winner. The point is to show how other communities are solving this problem. By comparing them you get maybe new ideas. NPM is doing a pretty good job. If they would sign their packages and make the licenses mandatory it would be the clear winner. Only 2 points are missing.

moondowner 13y ago

More dots means the author has deeper understanding in npm and thus found more to write about it.

reiz 13y ago
Actually I'm using in my daily work more Bundler and Maven. But I'm anyway a big fan of NPM.

blueblob 13y ago

It appears to be biased towards npm given that one set of dots is "JSON Based" and could have just as easily been "XML Based." I mean strictly the chart, not the article. The article seemed fair.

reiz 13y ago
In the first version of the chart I had column for "XML". But it didn't looked good, because there was only 1 candidate for XML and that was Maven. That's why I dropped it again. Beside that I think that XML is kind of overkill for dependency management. JSON is just fine, much smaller and easy to read. Having the dependency definition in native code (Python, Groovy, whatever) is not a good decision, in my opinion, because that's a source for security vulnerabilities.
- blueblob 13y ago
  I understand, you make a choice that summarizes the data the best that you can; I wasn't trying to attack you. I was trying to point out that choice of a language for the representation of your configuration is exactly that, a choice. I don't know that I agree that having the dependency definition in native code is a source of vulnerabilities; it could make the definition easier to write for people packaging code in that language. Also, I think JSON could be considered native code for npm since it is written in nodejs/javascript.
  - reiz 13y ago
    I didn't felt attacked. I appreciate feedback ;-) And you are right. The choice of a language is just a choice. Dependency definition in native code is always a security vulnerability, because by resolving the dependencies you execute unknown code, specially if the packages are not signed. I could for example publish a python package on PyPI with a setup.py which contains code to delete files on your hard disk. At the moment my setup.py gets executed on your machine you will lose some files. Something like that can not happen with JSON, XML or YML.

paulhodge 13y ago

> package dependencies are always installed in the node_packages directory of the package root Usually but not always. You can also have peer dependencies: http://blog.nodejs.org/2013/02/07/peer-dependencies/ http://blog.nodejs.org/2013/02/07/peer-dependencies/