“Package not found in registry: :hackney” problem

Questions / Help
1

I am attempting to add coverage to my project, but
keep running into problems.

I’ve run all the suggestions in the error
message at the bottom of this listing with the same
frustrating result.

I have a larger project that I wish to add coverage,
but all the coverage packages bomb the same way.

I started with a clean project, “bug”,
with only the mix deps()
addition so interference gets minimized.

Any help would be appreciated.

Versions:

rebar3 --version
rebar 3.13.2 on Erlang/OTP 22 Erts 10.4.3

elixir --version
Erlang/OTP 22 [erts-10.4.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
Elixir 1.9.4 (compiled with Erlang/OTP 22)

erl --version
Erlang/OTP 22 [erts-10.4.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [hipe]
Eshell V10.4.3  (abort with ^G)

The mix.exs in deps:

defp deps do
[
#{:coverex, “~> 1.5”, only: [:test], runtime: false},
{:excoveralls, “~> 0.13.0”, only: [:test], runtime: false},
{:idna, “~> 6.0.1”},
]
end

I’ve used different verions of coverex and excoveralls but the
resultsl are the same.

I notice:

"Bad dependency version for httpoison (and others...)"

but I don’t understand what to do about this either.

Here is the listing:

=> mix clean
=> mix deps.get
Resolving Hex dependencies...
Dependency resolution completed:
Unchanged:
  certifi 2.5.2
  excoveralls 0.13.0
  hackney 1.16.0
  idna 6.0.1
  jason 1.2.1
  metrics 1.0.1
  mimerl 1.2.0
  parse_trans 3.3.0
  ssl_verify_fun 1.1.6
  unicode_util_compat 0.5.0
All dependencies are up to date
Command completed;mix deps.get
=> mix test
===> Package idna-6.0.1 not found. Fetching registry updates and trying again...
===> Updating package registry...
===> Writing registry to /home/cecilm/.cache/rebar3/hex/default/registry
===> Generating package index...
===> [appsignal:1.6.2], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.6-beta.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.0], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.7.0-alpha.4], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.0-beta.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.3], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.7.0-alpha.3], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [batch_loader:0.1.0-beta.4], Bad dependency version for absinthe: ~> 1.4.0 or ~> 1.5.0-beta.
===> [prometheus_httpd:2.1.10], Bad dependency version for prometheus: ~> 3.5 or ~> 4.2.
===> [batch_loader:0.1.0-beta.5], Bad dependency version for absinthe: ~> 1.4.0 or ~> 1.5.0-beta.
===> [appsignal:1.7.0-alpha.2], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.7.0-alpha.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [batch_loader:0.1.0-beta.6], Bad dependency version for absinthe: ~> 1.4.0 or ~> 1.5.0-beta.
===> [appsignal:1.12.0], Bad dependency version for decorator: ~> 1.2.3 or ~> 1.3.
===> [appsignal:1.6.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.5], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.6-beta.2], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.6], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.7], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [appsignal:1.6.4], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> [batch_loader:0.1.0-beta.3], Bad dependency version for absinthe: ~> 1.4.0 or ~> 1.5.0-beta.
===> [appsignal:1.6.0-alpha.1], Bad dependency version for httpoison: ~> 0.11 or ~> 1.0.
===> Writing index to /home/cecilm/.cache/rebar3/hex/default/packages.idx
===> Package not found in registry: {<<"idna">>,<<"6.0.1">>}.
(Mix) Could not compile dependency :hackney, "/home/cecilm/.mix/rebar3 bare
compile --paths="/home/cecilm/play/Elixir/bug/_build/test/lib/*/ebin"" command
failed. You can recompile this dependency with "mix deps.compile hackney",
update it with "mix deps.update hackney" or clean it with "mix deps.clean
hackney"
2

That seems quite odd. idna 6.0.1 definitely exists. Maybe try clearing the cache.

rm -rf ~/.cache/rebar3
rm -rf ~/.mix
rm -rf deps _build
mix deps.get

If you’re still having the issue then try creating a sample project and check the version of Elixir and Erlang you’re using.

3

I experienced the same a couple of days ago. Tried cleaning things up multiple times, but had to give up.
I’ll see if I can reproduce it and share the sample app.

4

Try updating rebar with mix local.rebar.

3 Likes
5

That worked for me. Thanks!

2 Likes
6

It’s a good practice to run this script periodically (once a week, or biweekly):

mix local.rebar --force
mix local.hex --force
7

No, its not.

hex will tell you if new versions are available as far as I remember, the version of rebar installed and used via mix local.rebar is determined by the version of mix (so elixir) you use. It is constrained by an exact version match, not a (semantic) range.

Therefore the good habbit is to run mix local.hex when hex tells you it can be updated after a mix deps.get, while you should run mix local.rebar after each update of elixir.

8

I adopted the practice after one CI started hanging up on that (the company was utilising CI caching heavily) and then eventually just started doing it on my machine.

It can’t be objectively argued this is a bad practice IMO but it seems you have your opinion.

That one, plus removing the _build and deps directories, comprise a good checklist to go through when you have strange issues.

9

YES! This does it.

rm -rf ~/.cache/rebar3 ~/.mix deps _build
mix deps.get

As suggested by dimitarvp below, I’ll do this once a week.
Some kind of tricky bug relating to dependencies…

10

This works. I’ll integrate this into my weekly practice.

Thank you very much. :slight_smile: :slight_smile:

11

Absolutely agreed. My “trial by fire” gets resolved by your suggestions.

Thank you very much. :slight_smile: :slight_smile:

This could be a tricky bug to reproduce consistently and resolve.

12

I’ve not sayd it were bad practice, just that it isn’t good practice :smiley: It doesn’t harm except for the couple of seconds it takes you to run that command :smiley: Perhaps even integrated into your systems weekly update script. So yeah, who cares :smiley:

Thats always a good one for unexplainable errors and usually the first to try…

1 Like