hex problem with the gleam build tool

[massivefermion]

I just got the new gleam version and tried to test the new gleam build tool. But I keep getting the following message:

Resolving versions
error: Hex API failure

There was a problem when using the Hex API.

This was error from the Hex client library:

this account is not authorized for this action

This happens for any command that has to do the Resolving versions step!
It seems to be about my hex account, so I just logged in using mix hex.user auth but it didn't solve the problem. I should also say that there is nothing wrong with my account because I could publish a new version of my hex package with no problem. So what's going on?

[lpil]

That's very interesting- that command doesn't use any authentication. Does the problem persist if you change your IP by using a different internet connection?

[massivefermion]

Well, actually I have to do that a lot because of sanctions. So I use tor and torsocks for publishing my package and that works. But it makes no difference here.

[lpil]

Does mix deps.get work for you without any authentication?

[massivefermion]

yes, no problem.

[lpil]

I wasn't aware we did anything different to them. It would be good to learn more here, I do not know how proceed with debugging or reproducing this issue.

[massivefermion]

Well, it'd be great if I could actually contribute to gleam. So I'll try to figure it out.

[massivefermion]

ok, I figured it out
In compiler-cli/src/dependencies.rs, inside the function resolve_versions, you're calling lookup_package which in turn calls hex::get_package_release which in turn calls hexpm::get_package_release_request which sends a http request to https://hex.pm/api/packages/{name}/releases/{version}. But hex.pm is blocked in my country because of sanctions(and for some reason my VPN does not solve this!).
Anyway, hex basically does the same thing, or at least I think. It's like a maze so I can't be sure of exactly what's going on. But what I'm sure of is that instead of https://hex.pm/api/packages/{name}/releases/{version}, hex uses https://repo.hex.pm/packages/{name} which returns a binary chunk of data. It then uses :zlib.gunzip to decompress it. Then the result is decoded to give a list like:

[
...,
%{
    dependencies: [
      %{optional: true, package: "cowboy", requirement: "~> 1.0"},
      %{package: "plug", requirement: ">= 0.13.1 and < 2.0.0"},
      %{package: "poison", requirement: "~> 1.3"}
    ],
    inner_checksum: <<74, 82, 181, 5, 158, 238, 181, 108, 195, 161, 61, 122, 94,
      215, 254, ...>>,
    outer_checksum: <<105, 106, 76, 118, 6, 200, 174, 66, 46, 179, 65, 236, 213,
      116, ...>>,
    version: "0.15.0"
  },
  %{
    dependencies: [
      %{optional: true, package: "cowboy", requirement: "~> 1.0"},
      %{package: "plug", requirement: "~> 0.14 or ~> 1.0"},
      %{package: "poison", requirement: "~> 1.3"}
    ],
    inner_checksum: <<73, 176, 185, 126, 84, 89, 132, 36, 222, 71, 36, 133, 110,
      134, ...>>,
    outer_checksum: <<32, 187, 33, 129, 44, 249, 177, 176, 25, 64, 88, 251, 31,
      ...>>,
    version: "0.16.0"
  },
...]

For some reason https://repo.hex.pm/packages/{name} is not blocked in my country so there is no problem when I run mix deps.get.

[lpil]

Impressive detective work! I think mix is using the deprecated Hex API in this case. I could be wrong.

[massivefermion]

Actually this is not happening in mix, but in the hex client. I don't know how exactly mix is communicating with hex, but I have a suspicion they use an ets table that is written to ~/.hex/cache.ets.