2 ms·
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
by 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 agoI 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 agoI 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.