Mix hangs when mix.exs contains a git+branch dependency

fireproofsocks

I’m posting this here for some visibility (and hopefully some solutions) for a strange behavior I encountered.

Running any mix command, including mix help from a certain directory causes mix to hang indefinitely (or at least for 5 or 10 minutes after which I killed it). The culprit turns out to be a particular dependency that references a git branch:

{:mongodb_driver, git: "git@github.com:zookzook/elixir-mongodb-driver.git", branch: "master"}

As soon as I change to specify a regular hex version OR to a specific Git commit, all is well – mix help et al all work so long as my mix.exs looks like this:

{:mongodb_driver, "0.9.1"}
{:mongodb_driver, git: "git@github.com:zookzook/elixir-mongodb-driver.git", ref: "d7c8652b4e66a0031e1a7fe36bc2af5c85cef408"}

Other repos that rely on git repos (e.g. private packages) download fine. I would not have expected mix help to care about what was in the mix.exs file, let along some subtle difference in how a dependency was referenced, but that seems to be what’s happening. Renaming mix.exs makes mix help work, for example.

It looks like maybe the head of the git repo is problematic somehow – if I specify the latest commit from the git log, everything hangs again

{:mongodb_driver,
        git: "git@github.com:zookzook/elixir-mongodb-driver.git", ref: "59aa841cc619f77979cc3027c76e918373685723"},

Can anyone shed light on this?

6 comments

#mix #git

0 4117 6

2022-10-22 01:56:49 UTC

Showing Posts 1 to 6

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

dimitarvp

It’s very likely your SSH software is waiting for you to confirm you want to add an IP to list of trusted hosts (in the spawned shell when fetching dependencies).

Happened to me many times in Docker deployments.

Suggestion: don’t use the GIT URL that’s usually used for push access. Use the https:// URL variant.

Bonus points: just use the github: "user/library" syntax in mix.exs and forget about this nonsense.

Post #1

slouchpie

I usually see git URLS as using http scheme, e.g.

def deps do
...
  {:mongodb_driver, git: "https://github.com:zookzook/elixir-mongodb-driver.git"}

Try this

Post #2

fireproofsocks

I’m becoming more and more convinced that this is something to do with the commit that’s on the head of the master branch on the mongodb_driver repo. Is it a merge commit? Why should that be problematic?

Using the HTTP scheme for the URL had no effect. The following still hangs:

# Fails. (mix hangs)
{:mongodb_driver, git: "https://github.com/zookzook/elixir-mongodb-driver.git", branch: "master"}

Using the github syntax fails:

# Fails. (mix hangs)
{:mongodb_driver, github: "zookzook/elixir-mongodb-driver", branch: "master"}

Avoiding the problematic commit by specifying a ref works with the HTTP URL scheme:

# Ok!
{:mongodb_driver, git: "https://github.com/zookzook/elixir-mongodb-driver.git", ref: "d7c8652b4e66a0031e1a7fe36bc2af5c85cef408"}

Likewise, it works with the github syntax:

# Ok!
{:mongodb_driver, github: "zookzook/elixir-mongodb-driver", ref: "d7c8652b4e66a0031e1a7fe36bc2af5c85cef408"}

So something is weird with the 59aa841cc619f77979cc3027c76e918373685723 that’s at the HEAD of the master branch. Somebody with more git foo than me will have to clarify what the problem is. It’s still surprising that this one thing is preventing ALL mix tasks from running.

Post #3

derek-zhou

The problem has nothing to do with git but everything to do with the code. Apparently, this commit is bad:
https://github.com/zookzook/elixir-mongodb-driver/commit/e00871509c5287cd212d4c6f6c1783a0a64692b6

in mix.exs, project/0 calls docs/0, which in turn calls project/0 again, it is an infinite recursion. Did they test their code before the push?

Post #4

dimitarvp

Yikes.

Post #5

fireproofsocks

I’m willing to give the benefit of the doubt there – we’ve all had days with bad commits

I’m still surprised that this entry inside mix.exs effectively shuts down all mix operations. I wouldn’t expect mix.exs to be parsed, let alone the dependencies checked, let alone code in that dependency evaluated. This has proven very educational!

Post #6

— All posts loaded —