Asdf: Switching between projects is breaking my system

Questions / Help
1

I have two separate Phoenix projects.

The first uses Elixir 1.4 and the second i’m using 1.9.

I’m using asdf to set the local versions of each but noticed that I had accidentally set the global version as 1.9 on the second project. I tried setting the global version back to 1.4 and then tried deleting the .tool-versions file at /home/user, but I still get this crash report.

Regardless, I’m hitting an error on my first project now. Immediately when I try to run the project I hit this crash report on the CLI. I’ve tried deleting the _build and the deps. Even if i just run mix -v I get the crash report.

iex -S mix phx.server
Erlang/OTP 23 [DEVELOPMENT] [erts-10.6.2] [source-cf6cf5e5f8] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

=SUPERVISOR REPORT==== 15-Jan-2020::16:33:01.971915 ===
    supervisor: {local,'Elixir.Logger.Supervisor'}
    errorContext: start_error
    reason: noproc
    offender: [{pid,undefined},
               {id,'Elixir.Logger.ErrorHandler'},
               {mfargs,
                   {'Elixir.Logger.Watcher',watcher,
                       [error_logger,'Elixir.Logger.ErrorHandler',
                        {true,false,500}]}},
               {restart_type,permanent},
               {shutdown,5000},
               {child_type,worker}]

=CRASH REPORT==== 15-Jan-2020::16:33:01.973889 ===
  crasher:
    initial call: application_master:init/4
    pid: <0.93.0>
    registered_name: []
    exception exit: {{shutdown,
                         {failed_to_start_child,'Elixir.Logger.ErrorHandler',
                             noproc}},
                     {'Elixir.Logger.App',start,[normal,[]]}}
      in function  application_master:init/4 (application_master.erl, line 138)
    ancestors: [<0.92.0>]
    message_queue_len: 1
    messages: [{'EXIT',<0.94.0>,normal}]
    links: [<0.92.0>,<0.44.0>]
    dictionary: []
    trap_exit: true
    status: running
    heap_size: 376
    stack_size: 28
    reductions: 192
  neighbours:

=INFO REPORT==== 15-Jan-2020::16:33:01.975951 ===
    application: logger
    exited: {{shutdown,
                 {failed_to_start_child,'Elixir.Logger.ErrorHandler',noproc}},
             {'Elixir.Logger.App',start,[normal,[]]}}
    type: temporary
1 Like
2

you have a .tool-versions in each of the projects right?

eg cat /home/user/path_to/first_project/.tool-versions should have elixir 1.4 in it?

try rm -rf _build/ inside first project - maybe you accidently build it with elixir 1.9

1 Like
3

Yes that’s correct and i’ve already tried deleting the build.

4

hang on - I see erlang/OTP 23 - set the appropriate OTP for elixir 1.4 which is NOT OTP 23…

5

Have you also pinned an appropriate erlang version with each project?

1.4 and 1.9 have none overlapping erlang compatibility as far as I remember.

6

elixir 1.4 supports OTP 20 from a quick search… so use latest 20.x

7

Ok, progress with erlang 20.3, but I still get a compile error:

==> geocalc
Compiling 5 files (.ex)

== Compilation error on file lib/geocalc/dms.ex ==
** (CompileError) lib/geocalc/dms.ex:18: type t() undefined
    (stdlib) lists.erl:1338: :lists.foreach/2
    (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6

could not compile dependency :geocalc, "mix compile" failed. You can recompile this dependency with "mix deps.compile geocalc", update it with "mix deps.update geocalc" or clean it with "mix deps.clean geocalc"
8

elixir 1.4 or elixir 1.4.5 (which supports otp20…) ?

use otp 20.3.8.23 and elixir 1.4.5 - and remember rm -rf _build/ before…

also pin the elixir 1.9 project to a more recent otp - like latest 22.x

bonus tip: You’ll want to use the specific elixir/otp builds eg asdf install elixir 1.4.5-otp-20 and asdf install elixir 1.9.4-otp-22 - to enable all latest elixir features…

2 Likes
9

Great advice. Unfortunately, I’m still getting the same compile error on geocalc

10

is mix -v correct by now?

which geocalc version are you using? try going one minor version up or down…

11

So just a quick update, i do think it’s an issue with hex packages and cache.

For instance, I have geocalc 0.5 in my mix.ex, but running mix deps.get lists geocalc 0.8.0 as Unchanged.

So if I try to clean the cache on hex via mix deps.clean --all I get an error for each of my dependencies:

* Cleaning geocalc
warning: the dependency geocalc is not present in the build directory

If I go to my 1.9, I am able to run mix deps.clean --all successfully, but returning to 1.4 still resolves to geocalc 0.8.0. Super frustrating.

12
  • Do you have .tool-versions that not pin the Elixir version, but the Erlang version as well?
  • Have you pinned the Elixir version bare or with OTP, and is the OTP version the same as the pinned erlang version.
  • Do you have a mix.lock in the project where you think it resolves to the wrong version?
  • What are your deps in the mix.exs for that project?
1 Like
13

My .tool-versions specifies both elixir and erlang.

Have you pinned the Elixir version bare or with OTP, and is the OTP version the same as the pinned erlang version.

Not sure what this means.

I’ve tried deleting the mix.lock but that doesn’t resolve anything.

  defp deps do
    [
      {:phoenix, "~> 1.3.2"},
      {:phoenix_pubsub, "~> 1.0"},
      {:phoenix_ecto, "~> 3.2"},
      {:postgrex, ">= 0.0.0"},
      {:phoenix_html, "~> 2.10"},
      {:phoenix_inline_svg, "~> 1.1"},
      {:phoenix_live_reload, "~> 1.0", only: :dev},
      {:gettext, "~> 0.11"},
      {:cowboy, "~> 1.0"},
      {:absinthe, "~> 1.4"},
      {:absinthe_plug, "~> 1.4"},
      {:kronky, "~> 0.5.0"},
      {:dataloader, "~> 1.0.0"},
      {:httpoison, "~> 1.5"},
      {:guardian, "~> 1.0"},
      {:comeonin, "~> 4.0"},
      {:bcrypt_elixir, "~> 1.0"},
      {:scrivener_ecto, "~> 1.0"},
      {:csv, "~> 2.0.0"},
      {:distillery, "~> 2.0"},
      {:gcs_signer, "~> 0.2.0"},
      {:google_maps, "~> 0.9"},
      {:geocalc, "~> 0.5"},
      {:bamboo, "~> 1.1"},
      {:timex, "~> 3.1"},
      {:ex_uc, "~> 1.2"},
      {:number, "~> 1.0.0"}
    ]
  end

rm -rf _build deps mix.lock && mix deps.get
Resolving Hex dependencies...
Dependency resolution completed:
New:
  absinthe 1.4.16
  absinthe_plug 1.4.7
  artificery 0.4.2
  bamboo 1.3.0
  bcrypt_elixir 1.1.1
  certifi 2.5.1
  combine 0.10.0
  comeonin 4.1.2
  connection 1.0.4
  cowboy 1.1.2
  cowlib 1.0.2
  csv 2.0.0
  dataloader 1.0.7
  db_connection 1.1.3
  decimal 1.8.1
  distillery 2.1.1
  ecto 2.2.12
  elixir_make 0.6.0
  ex_uc 1.2.0
  file_system 0.2.7
  gcs_signer 0.2.0
  geocalc 0.8.0
  gettext 0.17.4
  google_maps 0.11.0
  guardian 1.2.1
  hackney 1.15.2
  httpoison 1.6.2
  idna 6.0.0
  jason 1.1.2
  jose 1.10.1
  kronky 0.5.0
  metrics 1.0.1
  mime 1.3.1
  mimerl 1.2.0
  number 1.0.1
  parallel_stream 1.0.6
  parse_trans 3.3.0
  phoenix 1.3.4
  phoenix_ecto 3.6.0
  phoenix_html 2.13.3
  phoenix_inline_svg 1.2.0
  phoenix_live_reload 1.1.7
  phoenix_pubsub 1.1.2
  plug 1.8.3
  plug_crypto 1.0.0
  poison 3.1.0
  poolboy 1.5.2
  postgrex 0.13.5
  ranch 1.3.2
  scrivener 2.7.0
  scrivener_ecto 1.3.0
  ssl_verify_fun 1.1.5
  timex 3.6.1
  tzdata 1.0.3
  unicode_util_compat 0.4.1
14

Do you have elixir-1.9 or elixir-1.9-otp-22 or something similar?

No, don’t delete it. Keep it.

This means the same as ">= 0.5.0 && < 1.0.0", so 0.8 is in range. If that does not work for your project, you need to add further constraints.

If you had a lockfile from previously, than the locked version from earlier would have been used, unless you unlock it. But in that case, you would probably not have concluded that the issue were related to having a different elixir version in a different project.

2 Likes
15

Do you have elixir-1.9 or elixir-1.9-otp-22 or something similar?

Obviously not.

No, don’t delete it. Keep it.

But it just recompiles on mix deps.get so what’s the problem?

This means the same as ">= 0.5.0 && < 1.0.0"

None of my dependencies specify a specific version. Is that taboo? I’ve never seen documentation that calls for a different syntax in the deps.

16

So whats in there then? If its neither of both forms?

Not having a mix.lock produces irreproducable results depending on when you did your mix deps.get and dependency resolution might resolve slightly different each time. It is considered good practice to keep it under version control.

But you said, geocalc 0.8 is a problem for you, or do I get you wrong? Maybe I’m just confused with what the actual problem beeing discussed here is about…

17

Here is my .tool-versions:

erlang 20.3.8.23
elixir 1.4.5-otp-20

Yes, geocalc seems to be the current problem, as I can’t get my project to compile:

mix phx.server
==> geocalc
Compiling 5 files (.ex)

== Compilation error on file lib/geocalc/dms.ex ==
** (CompileError) lib/geocalc/dms.ex:18: type t() undefined
    (stdlib) lists.erl:1338: :lists.foreach/2
    (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6

could not compile dependency :geocalc, "mix compile" failed. You can recompile this dependency with "mix deps.compile geocalc", update it with "mix deps.update geocalc" or clean it with "mix deps.clean geocalc"
18

The commit adding that type is only 6 days old, though it has been referenced from within code even before that.

Thats probably the problem.

Try to exclude 0.8.0 for now.

"~> 0.5 and != 0.8.0" should skip that single broken version.

19

Cool, that got me over that hurdle, now facing the next one.

== Compilation error on file lib/gettext/extractor_agent.ex ==
** (UndefinedFunctionError) function Agent.__using__/1 is undefined or private
    (elixir) Agent.__using__([])
    lib/gettext/extractor_agent.ex:3: (module)
    (stdlib) erl_eval.erl:670: :erl_eval.do_apply/6

could not compile dependency :gettext, "mix compile" failed. You can recompile this dependency with "mix deps.compile gettext", update it with "mix deps.update gettext" or clean it with "mix deps.clean gettext"

What’s the point of rounding your dependency versions when they are going to break your build?

20

To what version of gettext are your deps resolved? The most recent versions have elixir: "~> 1.6" in their mix.exs, so you need to find one that still allows for 1.4 and add an appropriate constraint.