Good questions. Most of them are answered by Nimble's readme, but the packages readme should also contain this info (PRs welcome).
> Q1 :what happens if 2 nimble packages with same name are published to nimble? > eg: > [https://github.com/ivankoster/protobuf-nim](https://github.com/ivankoster/protobuf-nim) > > [https://github.com/PMunch/protobuf-nim](https://github.com/PMunch/protobuf-nim) This isn't allowed. The `package_scanner` ([link](https://github.com/nim-lang/packages/blob/master/package_scanner.nim)) script which is run by travis ensures this. > Q2: what happens if 2 nimble packages (whatever their package name) define > the same module? Nimble verifies each package's structure during installation. If a Nimble package does this then Nimble will show a warning (in the future this will become an error). > Q3: to mitigate module name collision, could we require/encourage packages > published on nim to either be a single module or multiple modules but under a > package foo? This is already done. Please read the Nimble readme: [https://github.com/nim-lang/nimble#project-structure](https://github.com/nim-lang/nimble#project-structure) > Q4: on a related note, the standard library puts a ton of modules on the > global top-level namespace, which could lead to name collisions. Lots of > other languages (eg C++, D, rust, C#, etc) use a package (typically std) to > avoid this. Why not use that in Nim? eg, using import std.typetraits instead > of import typetraits ; nimfix or anoother tool could help with migration and > aliases could be used during some deprecation period. Yes, this is occasionally a problem. There is now a `std` prefix that you can use: `import std/strutils`. There will also be a `pkg` prefix: `import pkg/random`. See this RFC for details: [https://github.com/nim-lang/Nim/issues/7250](https://github.com/nim-lang/Nim/issues/7250)
