rebar3 looks to be going to hex.pm also ?

Minimal case.

[test]$ rebar3 compile
===> Fetching rebar3_path_deps v0.4.0
===> Version cached at /home/wmealing/.cache/rebar3/hex/hexpm/packages/rebar3_path_deps-0.4.0.tar is up to date, reusing it
===> Analyzing applications...
===> Compiling rebar3_path_deps
===> Verifying dependencies...
===> Fetching event_handler (from {path,"../event_handler"})
===> Failed to update package event_handler from repo hexpm
===> Package not found in any repo: event_handler

I've noticed that it is fetching it from ../event_handler/

If I however create a rebar.lock file (all characters are fictional, any resemblance to real life people is purely coincidental).

$ cat rebar.lock
[{<<"event_handler">>,
{path,"../event_handler",{mtime,<<"2020-10-24T02:12:53Z">>}},
0}].

It seems to work

[test]$ rebar3 shell
===> Verifying dependencies...
===> Upgrading event_handler (from {path,"../event_handler",
{mtime,<<"2020-10-24T02:12:53Z">>}})
===> Analyzing applications...
===> Compiling event_handler
Erlang/OTP 22 [erts-10.7.2.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [hipe]

Eshell V10.7.2.3 (abort with ^G)
1>

What am I / did I do wrong ?

Thanks in advance.

Reproduce the minimal case with `rebar3 compile` using the `{path,"../event_handler"}` dependency, then compare it with the behavior after creating the shown `rebar.lock`. Trace the dependency verification and fetching path involved; done means a path dependency is not treated as a Hex.pm package and the minimal case reaches compilation without a manually created lock file.

Written by the indexing model from the issue text.