**@andrea** > For some reason, though, I often see libraries that recommend to do nimble > install to make them available.
I believe the reason this recommendation is so widespread is that developers very often prefer to test out packages before adopting them into their project. Often times they don't even have a project. Creating a .nimble file just to play around with a package would be tedious. > 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. Have you seen packages that just assume dependencies will be installed globally? I haven't seen a single one, so I don't think this danger is real. > that people stop mentioning `nimble install` as a way to depend on libraries > (it is fine for executables though) Maybe I am mistaken but developers are not suggesting that `nimble install` be used "as a way to depend on libraries". They are just showing this command without any comments. Looking at an npm package for example, I see a similar command shown in the [right sidebar](https://www.npmjs.com/package/async). Cargo packages on the other hand show a snippet that can be added into the [cargo.toml file](https://crates.io/crates/libc). I do agree that library authors should be showing `requires "pkg >= 0.1.0"`, but I'm not sure it's such a big deal if they don't. > that library authors git tag each new version of their libraries - this is > needed for nimble to retrieve the library at that particular version Agreed. This is a requirement and is described in Nimble's readme. > that library authors bump versions frequently enough that one can depend on > numbered versions Yes, but how often is often enough? Anyway, thanks for starting the discussion. I'm happy to discuss anything and everything about Nimble even though I may disagree with you sometimes
