2 ms·
I'm not sure I understand this issue. The existence of a standard package manager doesn't prevent you from manually vendoring dependencies if you want to. I hav
by zoogeny 3y ago
I'm not sure I understand this issue. The existence of a standard package manager doesn't prevent you from manually vendoring dependencies if you want to. I have personal experience working on node.js projects where several dependencies were just `cp` into a directory and treated like local modules, no npm involved at all.
It's like `apt` or `brew` for system dependency management. It is there if you want it but you can just as well download a tar and config/make/install yourself if you want.
In many ways, it is like a standard lib. No one forces you to use it. If you prefer the simplicity of your own implementations then I see no reason why you can't just write your own.
But when you want the advantages of a package manager, and there are advantages that you may not appreciate but others do, then having a standard one built into the language feels preferable to having a dozen non-standard independently competing variations that the community cobbles together.
- uranusjr 3y agoFurthermore, having a package manager indicates there are some kind of specifications behind so each package and repository has an expected format (not necessarily _a_ standard package manager; in many ecosystems multiple managers share one standard). This helps vendoring a lot since the standard specification makes the vendoring process very easy to automate and validate. Dependency managers in their essence is really just automated vendoring (or vendoring is just less automated dependency management); it helps because you can pick it apart and choose to automate only the parts you want, even if you don’t like the fully automated solution.