Decide on a policy on how to handle URLs and clashing project names

[elcritch]

Currently the way Nimble treats package names and URL's in requires list in Nimble files causes issue.

For example having packageA and github.com/foo/packagea in the nimble files for two dependencies in a project can potential result in non-deterministic behavior. One case would be to have two separate paths of the same module (--path:packagea_path --path:github_foo_packagea_path) passed to the compiler. Though I believe the SAT code currently avoids this. Alternatively a package will get chosen based on the insert order of the packages lists as they're generated, which seems to depend partly on the order of iteration of Nimble packages.

One really bad result of this indeterminate order could be a hijack a package name with a hostile package injected via another dependency which adds a trojan URL into it's nimble requirements. For example project bar could add requires "github.com/_bad_hacker/foo" which has a foo.nimble. When Nimble runs printPkgInfo on the package cache after an update then Nimble might choose github.com/_bad_hacker/foo instead of the official github.com/cooluser/foo because say it uses treeWalk or similar to parse package info. Note that I haven't tried this, and it's possible the code avoids this issue. It'd also depend on the end-users OS and other details as well.

Personally I think the way Elixir's mix package manager handles it is the best, but it requires specifying the package name as well as the URL in it's dependencies format for packages not in the official catalog. In Elixir that's done as a tuple {:other_package, "~> 2.0", git: "github.com/foo/packagea"}. Then if as an end-user I want to fork a library and use it I can do {:other_package, "~> 2.0", git: "github.com/user/packagea_fork", override: true}. However, Nimble requires doesn't support this and packages are already specified purely via URL.

A benefit about treating the URL or source as extra metadata in requires means the name conflict can be raised before running SAT or even cloning a repo/package since the name is already included. The user can then specify what they want to do. If it's a legitimate fork then the user can override the default name.

One solution for example would be to modify requires to allow requires (name: "foo > 0.2", git: "github.com/cooluser/foo", override: true). This also avoids the need for Nimble to do network requests to test is a requirement is a git or hg repo, etc.`. Just one thought.

IMHO, the randomness of URL handling is a pretty big issue to have in the 1.0 release. Especially as a fair number of widely used packages in the nimbleverse are reference via URLs.