Nightly commit bd65281 fails to build engine for project

[Terbium-135]

Guess this is known already - Just reporting in case:

The project is on 1.19.1 and OTP-28.1

10:32:44.705 [debug] Building engine: Unchecked dependencies for environment dev:
* snowflake (Hex package)
  the dependency is not available, run "mix deps.get"

10:32:44.705 [debug] Building engine: * elixir_sense (https://github.com/elixir-lsp/elixir_sense.git - e3ddc403554050221a2fd19a10a896fa7525bc02)
  lock mismatch: the dependency is out of date. To fetch locked version run "mix deps.get"

10:32:44.705 [debug] Building engine: * patch (Hex package)
  the dependency is not available, run "mix deps.get"
* sourceror (Hex package)

10:32:44.705 [debug] Building engine:   the dependency is not available, run "mix deps.get"
* refactorex (Hex package)
  the dependency is not available, run "mix deps.get"
* deps_nix (Hex package)
  the dependency is not available, run "mix deps.get"
* credo (Hex package)
  the dependency is not available, run "mix deps.get"
* gen_lsp (Hex package)

10:32:44.705 [debug] Building engine:   the dependency is not available, run "mix deps.get"
* path_glob (Hex package)
  the dependency is not available, run "mix deps.get"

10:32:44.713 [debug] Building engine: ** (Mix.Error) Can't continue due to errors on dependencies
    (mix 1.19.2) lib/mix.ex:647: Mix.raise/2
    (mix 1.19.2) lib/mix/tasks/deps.loadpaths.ex:107: Mix.Tasks.Deps.Loadpaths.deps_check/3
    (mix 1.19.2) lib/mix/tasks/deps.loadpaths.ex:73: Mix.Tasks.Deps.Loadpaths.run/1
    (mix 1.19.2) lib/mix/task.ex:499: anonymous fn/3 in Mix.Task.run_task/5
    (mix 1.19.2) lib/mix.ex:1014: anonymous fn/6 in Mix.install/2
    (elixir 1.19.2) lib/file.ex:2007: File.cd!/2
    (mix 1.19.2) lib/mix.ex:978: Mix.install/2
    /home/elixir-dev/.local/share/.burrito/expert_erts-15.2.7_0.1.0-bd65281/lib/xp_expert-0.1.0-bd65281/priv/build_engine.exs:23: (file)

10:32:44.719 [error] Engine build script exited with reason: :normal ** (Mix.Error) Can't continue due to errors on dependencies
    (mix 1.19.2) lib/mix.ex:647: Mix.raise/2
    (mix 1.19.2) lib/mix/tasks/deps.loadpaths.ex:107: Mix.Tasks.Deps.Loadpaths.deps_check/3
    (mix 1.19.2) lib/mix/tasks/deps.loadpaths.ex:73: Mix.Tasks.Deps.Loadpaths.run/1
    (mix 1.19.2) lib/mix/task.ex:499: anonymous fn/3 in Mix.Task.run_task/5
    (mix 1.19.2) lib/mix.ex:1014: anonymous fn/6 in Mix.install/2
    (elixir 1.19.2) lib/file.ex:2007: File.cd!/2
    (mix 1.19.2) lib/mix.ex:978: Mix.install/2
    /home/elixir-dev/.local/share/.burrito/expert_erts-15.2.7_0.1.0-bd65281/lib/xp_expert-0.1.0-bd65281/priv/build_engine.exs:23: (file)

[mhanberg]

I think there might be a bug in how we determine if the compiled engine artifacts need rebuilt.

I believe for now, you can delete the folder for expert in the ~/.local directory.

I can't remember exactly the path but it should be somewhere in there.

[doorgan]

We use Mix.install for this, so if we have a bug here it may be likely there's a bug in Mix.install?
The directory is ~/.local/Expert/0.1.0 on linux, or ~/Library/Application Support/Expert/0.1.0 on macos

[ashkan117]

Adding some context in my case here but let me know if I need to make a new issue.

For the longest time I was running into this issue so I tried using Claude Code to help debug the codebase and ran into an issue with EXPERT_ENGINE_PATH not being set. A workaround I did was to set it in my nvim environment with

vim.env.EXPERT_ENGINE_PATH = "/home/ash/projects/expert/apps/engine"

I tried looking into it some more a week later to see what could be a fix. I think maybe the issue was ultimately caused since my lsp was connecting to a previous version of expert? After running the command below I couldn't reproduce the issue and now my lsp works without setting EXPERT_ENGINE_PATH

rm -rf ~/.local/share/.burrito/expert_*

I'm not very knowledgeable on burrito so I'm not sure what's going on or if there is an actual problem but thought I'd report my findings.

[mhanberg]

Pretty sure when developing locally, it always installs the engine code to 0.1.0, so it probably wont' sense a code or deps change, which causes this.

For now, if you are seeing this, you can try elixir -e ':filename.basedir(:user_data, "Expert") |> File.rm_rf!() |> IO.inspect()' which will delete the local Expert data.

We'll come up with a better long term solution.