I was recently caught off guard by the behavior of rebar3 and the rebar3_hex plugin, with the atomvm_rebar3_plugin that I published to hex.pm. The plugin has two dependencies, both are available on hex.pm, but I forgot to change the source of one of the dependencies from a GitHub tag to the hex release. This caused neither dependency to be listed on the atomvm_rebar3_plugin page on hex.pm, and indeed when pulling the atomvm_rebar3_plugin from hex.pm neither dependency was fetched. If changed my rebar.config to use the GitHub release tag everything worked as expected.
After discovering my mistake it does make sense, but I want to confirm this is expected behavior and not a bug in the rebar3_hex plugin, or possibly rebar3 itself. If this is expected, it does seem to make it impossible to release anything on hex.pm that includes a 3rd party application only available via git.
Thanks for taking the time to read this, and I appreciate any answers,
-Winford
Can you open an issue on rebar3_hex with details and steps to reproduce?
1 Like
Thank you for the answer, I had convinced myself this was my mistake. I’m glad I decided to ask!
Without knowing more, I would say the problem is either in rebar3_hex or hex_core, but that remains to be determined without more details. You should not be allowed to publish packages to hex that contain git dependencies.
Thank you for the clarification. That does make sense. This is the first package that has dependencies that I have published, and the second publication I have ever made, so I am still familiarizing myself with how it all works together. I am collecting some notes and will open an issue in the next day or so.
1 Like
In case anyone is curious… The way to reproduce this bug is to run rebar3 mix build and rebar3 mix publish when there is no rebar.lock present (or if its contents are: [].), and rebar.config has at least one package with a git source. This results in a package being published with no dependencies listed. I have opened an issue for rebar3_mix. When I started to try to reproduce this I was expecting it to be something related to recently updating to OTP 28.0 (suspecting a cache problem), but this can be reproduced on OTP 27 (and presumably earlier) as well.
In case anyone is following this, the problem was ultimately because hex was being used under a profile (the docs do say this should not be done), so this is an unlikely problem for anyone else to encounter. A fix has been merged into the rebar3_hex repo thanks to @starbelly 
Anyone else who hits this corner case will get an error when running rebar3 hex build (after the commit is included in a release), and they can’t accidentally publish a broken package to hex.pm.
Thank you again @starbelly for helping sort this out and coming up with a solution!
— Winford
1 Like