4 ms·
If you don't have enough manpower who can control and collaborate on the development of the environment, the project will not succeed to be adopted. Programmin
by okanat 2y ago
If you don't have enough manpower who can control and collaborate on the development of the environment, the project will not succeed to be adopted.
Programming language-specific dependency tools succeeded due to their user friendliness, however abysmal they are in multi-language / OS dependent environments (and I despise them for that reason). Cargo.toml, go.mod, conan.txt, Dockerfile etc. all are can be understood by basically all members of a dev team. You cannot say the same for Nix for most devs in a team.
- mplanchard 2y agoOur direct experience counteracts this point. We have docs on how to add nix dependencies, and a file where they’re defined. For anything already packaged in nix, everyone can figure out how to add a line in that file to add something to everyone’s dev environment. We have over 3 years only wound up having to write our own derivations for two or three things. We still use language-specific tools for those dependencies, though, since that is what people are familiar with. I think this strikes a fine balance: nix describes the “operating system” that we all work in, and then Cargo, npm, etc lockfiles describe each language’s dependencies.