Q1 :what happens if 2 nimble packages with same name are published to nimble? eg: https://github.com/ivankoster/protobuf-nim https://github.com/PMunch/protobuf-nim
I don't see any package name uniqueness constraint mentioned here: https://github.com/nim-lang/packages/blob/master/README.md
Is package name collision prevented by nimble publish, or enforced in any way?
Q2: what happens if 2 nimble packages (whatever their package name) define the same module? eg: these https://github.com/ivankoster/protobuf-nim and https://github.com/PMunch/protobuf-nim both define module protobuf; so what will import protobuf import if both packages are published and installed (in the future, since now they're not on nimble)?
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? https://github.com/nim-lang/packages/blob/master/README.md doesn't mention this
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.
https://forum.nim-lang.org/t/3695 cpp compilation into own namespace (regarding collisions when compiling nim code along with a large C++ library)
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/PMunch/protobuf-nim
This isn't allowed. The package_scanner (link) 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
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