Elixir: Don't allow circular application dependencies

[michalmuskala]

Environment

• Elixir & Erlang/OTP versions (elixir --version): 21/1.7.0-dev
• Operating system: macOS

Current behavior

It's possible to create circular dependencies between packages. For example:

• :jason package depends on :json (only as a dev dependency for benchmarking)
• :json package depends on :jason (possibly accidentally)

The result is that deps.get in the :jason package also downloads :jason from hex and later (understandably) refuses to compile it.

Expected behavior

It should either be an error to do this (and it should be detected during deps.get with a nice message) or it should be implicitly treated as override: true and use the local package instead of downloading from hex.
Given that we don't allow cycles in other places, I lean towards the first solution.

[ericmj]

This only happens when :jason is the top-level application, if they are all dependencies we detect the cycle.

[OvermindDL1]

As I recall @tmbb had a similar issue with this makeup ex doc interface when he tried to use it to generate docs for itself (as he had to depend on the elixir plugin, which then depended back on itself).

[michalmuskala]

After thinking about it a bit more, I think it might be useful to allow to set an override to make a dependency resolve to the current project.

The example use case is the https://github.com/PragTob/benchee_json library that depends on jason, that I would like to use to benchmark jason itself. I know it's a pretty weird and niche use case - I'm fine if we decide not to support it, but I wanted to put it out there.

[tmbb]

As I recall @tmbb had a similar issue with this makeup ex doc interface when he tried to use it to generate docs for itself

I still do. I still can't use makeup syntax highlighting in makeup's docs with my latest PR. I don't know if it's a valid reason to complicate dependency resolution, but the issue still stands.

[josevalim]

@tmbb you can do like Elixir does, which is to use the ex_doc via the command line or as an escript.

[josevalim]

Given this is not a common scenario, I prefer to not complicate resolution to handle those cases early, especially due to the different sources and umbrella projects.

So while we do download the package, it is quite fast, and the error message today points there is a duplicate project in two different locations:

warning: redefining module NimbleParsec.MixProject (current version defined in memory)
/Users/jose/OSS/nimble_parsec/deps/nimble_parsec/mix.exs:1

Error while loading project :nimble_parsec at /Users/jose/OSS/nimble_parsec/deps/nimble_parsec
** (Mix) Trying to load NimbleParsec.MixProject from "/Users/jose/OSS/nimble_parsec/deps/nimble_parsec/mix.exs" but another project with the same name was already defined at "/Users/jose/OSS/nimble_parsec/mix.exs"