When creating a software project, it is important that it is reproducible. This means that the dependencies for that project are not, for instance, globally installed on the developer machine, but there is an automated way to retrieve them and make it available.
Many language-specific package managers (e.g. Maven, SBT, Leiningen, NPM, Cargo) handle dependencies through a configuration file. This allow, for instance, to clone a project on a fresh machine and (usually) be able to build it locally with a single command. For languages where such package managers are not widespread (e.g. C), many people resort to solutions such as Docker to create an isolated, reproducible environment to build the final artifact. Nimble is able to handle dependencies as well: when starting a new project one needs only to create a .nimble file and declare dependencies there, and then run `nimble c ...` \- or a custom nimble task - to build the project having the dependencies in scope. For some reason, though, I often see libraries that recommend to do `nimble install` to make them available. For instance, out of the latest 10 libraries published on nimble (one of which is my own), the following 4 suggest a global `nimble install`: * [http://fragworks.io](http://fragworks.io)/ * [https://github.com/euantorano/tempdir.nim](https://github.com/euantorano/tempdir.nim) * [https://github.com/tulayang/nimnode](https://github.com/tulayang/nimnode) * [https://github.com/euantorano/sysrandom.nim](https://github.com/euantorano/sysrandom.nim) (not to pick on those in particular). The problem is that this will install libraries globally. Suggesting newcomers to use `nimble install` for anything but executables (such as c2nim) will lead to an ecosystem where projects are built with unknown dependencies at random versions. My suggestion is: * that people stop mentioning `nimble install` as a way to depend on libraries (it is fine for executables though) * that library authors `git tag` each new version of their libraries - this is needed for nimble to retrieve the library at that particular version * that library authors bump versions frequently enough that one can depend on numbered versions I think this is important, because nowadays being able to handle dependencies in a package manager is more or less given for granted by people coming from other languages, and while technically Nim is able to do that, there is still mixed advice in the community. See [this issue](https://github.com/nim-lang/Nim/issues/5776) for more discussion of the topic
