Mix deps.get eats all memory

gVolop

i have the same issue like here Hex v0.20.2-5 eats all memory and dies, but maybe it is us - #4 by outlog

When i try to execute mix.deps.get after removing mix.lock, the terminal hangs at Resolving Hex dependencies... . The process then starts to eat all available memory and swap …

my-app|qa⚡ ⇒ mix hex.info
Hex:  0.20.5
Elixir: 1.9.4
OTP:  22.1.4

Built with: Elixir 1.9.4 and OTP 22.1.4

my-app|qa⚡ ⇒ mix deps.get                                    
* Updating google_api_storage (https://github.com/DinaWork/google-api-storage.git)
* Updating google_auth (https://github.com/DinaWork/google-auth.git)
* Updating paranoid (https://github.com/echobind/paranoid.git)
Resolving Hex dependencies...

it’s umbrella with ~30 apps

i think it started after i update hex to 0.20.2
but now, even if i trying to change it back to lower version - i still have the same issue.

20 comments

#hex

2 4509 20

2022-11-10 12:33:34 UTC

Showing Posts 20 to 11

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

Hex recently released version 2.0, which is afaik meant to resolve the issues presented here.

Post #20

menty44

This worked for me

Post #19

rogerweb

I’ve just had this issue while upgrading from Phoenix 1.5 to 1.6 and, believe it or not, deleting the mix.lock did the trick.

Post #18

jjenkins

This:

I hadn’t come across your answer, but from the earlier posts I realized a similar thing. If the mix.lock file is gone, it will throw that error it seems. Simply comment out all but one dependency. Run a deps.get, then you can likely uncomment all the rest (I uncommented in groups of about 5 or so). I’d guess that having at least one in a lock file is the key to circumventing this search space issue.

Post #17

benonymus

Ok interesting, I checked the .dockerignore and the lock file was added there for some reason.

# prevent overwriting mix.lock file in base image
project_umbrella/mix.lock

If I remove it the deps are coming along nicely.
This should be safe to remove from the ignore right?

Post #16

josevalim

Creator of Elixir

My Docker knowledge is very limited but I think you need to explicitly copy all files or something?

Post #15

benonymus

Wow it is not there, but why?
The image is doing:

ADD . /application
WORKDIR /application/project_umbrella

And when I check before getting the deps with ls the following files/folders are there:

apps
config
mix.exs

Post #14

josevalim

Creator of Elixir

IIRC none of them should mess up the lock. Can you double check you are copying the mix.lock file to the Docker image before running those commands?

Post #13

gVolop

try to change the dependencies to fixed version - “== 2.1.6” instead “~> 2.1.6”

Post #12

benonymus

Hey,
I am experiencing the same problem, on the deployment docker file even when I run it locally.
I identified that id I comment out these 3 deps, then we are ok, but the 3 together causes the problem.
I have a mix.lock

      {:ex_aws, "~> 2.1.6", override: true},
      {:quantum, "~> 3.3.0"},
      {:chromic_pdf, "~> 0.7.2"}

I am wondering that the docker file that I inherited might causes this partially because locally I can get the deps without any issues, only I am trying to build the container I am getting the problem.

I think this part is the relevant:

RUN
mix local.hex --force &&
mix local.rebar --force &&
mix clean &&
mix deps.clean --all &&
mix deps.get &&
mix deps.compile

Do any of these steps mess with the lock file?
I read the docs for the cleaning steps but I am still unsure.

Thanks

Post #11

Load more posts (10 remaining)