Mix "dependency is not locked" error when building with edeliver

Questions / Help
, ,
1

I have a project that uses edeliver and distillery for build and deployment. There’s a staging and a production server, and I’m also using staging as the build host.

After not touching the project for a while, and having to rebuild the staging server, I’m getting an error when it tries to run the remote build. I can reproduce the error by logging onto the staging server and running mix from the build directory:

$ MIX_ENV=prod mix
Unchecked dependencies for environment prod:
* sshex (Hex package)
  the dependency is not locked (run "mix deps.get" to generate "mix.lock" file)
** (Mix) Can't continue due to errors on dependencies

There definitely is a mix.lock file, which includes sshex. I suspect this may be an environment problem rather than anything to do with edeliver, but I’m at a bit of a loss where to look for a solution.

Any ideas?

Thanks,

Kerry

2

Is the up-to-date mix.lock file in the Git repo and in the commit which the build server has checked out?

3

Thanks for the suggestion @BrightEyesDavid, but yes, mix.lock was up-to-date in git (I thought it was a related problem, but that turned out to be a red herring).

I finally tracked it down to some unexpected (to me, at least) behaviour from mix. My application is an umbrella project, and two of the apps in the umbrella list sshex as a dependency. One of them only uses it for testing, so I’d specified only: [:dev, :test] (the other doesn’t have any environment conditions. It seems that when mix loads the dependencies for the umbrella with MIX_ENV=prod, the only instruction in the first app overrides the unrestricted specification in the second. That explains why it worked fine when I just ran mix, but not when building for deployment (I eventually realised that running MIX_ENV=prod mix compile failed locally with the same error.

I’m not sure whether this is just me misunderstanding how mix dependencies are supposed to work in umbrella apps, or whether it’s a bug – it seems like something that should at least generate a warning. When I get a chance I’ll put together a minimal test case and submit an issue.

4

Hi Kerry,

did you manage to solve this issue? I bumped into the exact same thing I believe, with a different dependency.

5

As far as I can remember I just removed the only: option from the application that had it. I converted it from an umbrella to a single application using Phoenix contexts soon after, which would have avoided the issue altogether.

6

One more note for anyone who might bump into this: it seems to just work well on Elixir 1.7.2, so finally, that solved the problem for me. There seem to have been fixes to the only and umbrella apps behavior somewhere at that point.