Homebrew formula

[mhanberg]

@mhanberg Hey, I wrote the formula for Expert and wanted to clarify the use of burrito.

The homebrew formula does not need to use burrito tho, so that should probably get changed.

I was not aware of this. This is actually my first time writing a Homebrew formula, so I took quite a lot of inspiration from others; mainly, the Next LS formula from the elixir-tools tap, which also used burrito, but it's good to know, as that would eliminate the zig and xz dependencies the formula currently has when building from source.

Though one more thing I will add is that the plain releases appear to be significantly slower than the burrito ones, so that's one potential reason to keep using burrito for the formula as well. Take for example this command:

expert --version

With the burrito release, this takes ~200 ms to run, but with a plain release it takes ~2 seconds (this is on macOS Intel); that's 10 times slower!

I'm not sure why there's such a big difference. Perhaps this won't matter much when actually using the language server, but it's something to keep in mind (and potentially improve about the plain releases).

---

Anyways, while prototyping a version of the formula that builds a plain release instead, I initially was going to switch it to this:

    system "mix", "local.hex", "--force", "--if-missing"
    system "mix", "local.rebar", "--force", "--if-missing"
    system "just", "release"

    libexec.install Dir["apps/expert/_build/prod/rel/plain/*"]
    libexec.glob("bin/*.bat").map(&:unlink)
    bin.install_symlink libexec/"bin/start_expert" => "expert"

But I quickly discovered that this doesn't work because symlinking the start_expert executable prevents it from calling the plain executable (which is not symlinked and should probably not be symlinked).

The failure seems to be caused by the use of $(dirname -- "$0")"/plain which returns the directory of the symlink rather than the directory of start_expert in its actual location.

ElixirLS does something similar to the plain releases with its use of a launch_server.sh executable, so I looked at how they solve this issue. They include this to resolve calls from symlinks:

readlink_f () {
  cd "$(dirname "$1")" > /dev/null || exit 1
  filename="$(basename "$1")"
  if [ -h "$filename" ]; then
    readlink_f "$(readlink "$filename")"
  else
    echo "$(pwd -P)/$filename"
  fi
}

dir="$(dirname "$(readlink_f "$0")")"
exec "${dir}/launch.sh"

Something like this could be included in the start_expert executable as well.

In the meantime, the only way to get the plain release to work with Homebrew is to do this instead:

    system "mix", "local.hex", "--force", "--if-missing"
    system "mix", "local.rebar", "--force", "--if-missing"
    system "just", "release"

    libexec.install Dir["apps/expert/_build/prod/rel/plain/*"]
    libexec.glob("bin/*.bat").map(&:unlink)
    (bin/"expert").write <<~SHELL
      #!/bin/sh
      exec "#{libexec}/bin/plain" eval "System.no_halt(true); Application.ensure_all_started(:xp_expert)" "$@"
    SHELL

---

P.S.

Any chance we could merge #550?

That would allow us to simply the formula from this:

    system "mix", "local.hex", "--force", "--if-missing"
    system "mix", "local.rebar", "--force", "--if-missing"
    system "just", "release"

    ...

To this:

    system "just", "release"

    ...

Originally posted by @AlternateRT in #556 (comment)

[mhanberg]

@AlternateRT i made this new issue to discuss this. I'll respond further once I'm at a computer

[mhanberg]

the Next LS formula from the elixir-tools tap,

Yeah, that's my bad. I was focused on getting it working with burrito at the time, but didn't really come to realize that it should use all homebrew provided dependencies. I'm actually surprised they merged it since it downloads its own erlang.

With the burrito release, this takes ~200 ms to run, but with a plain release it takes ~2 seconds (this is on macOS Intel); that's 10 times slower!

This is very strange, if anything it should be faster. On my machine the plain release (used by nix) runs in about 193ms. I'm hesitant to think too much about anything related to intel macs tho, since its a far minority of users at this point.

In the meantime, the only way to get the plain release to work with Homebrew is to do this instead:

This is basically what we do for nixpkgs: https://github.com/NixOS/nixpkgs/blob/77bbd72922d6b9f52151cea2d0dcbbf9f2581b69/pkgs/development/beam-modules/expert/default.nix#L51-L55

Any chance we could merge #550?

I don't like that implementation and the naming is confusing. I'd rather just have the user manage it themselves, or just add the hex and rebar lines to the deps recipe so it gets called when it runs that recipe. Not really a blocker for this tho.

---

Also note, I feel like the brew recipe should not use burrito, but we (expert team) are not going to be able to maintain the formula super closely, so you are free to maintain it as you wish! I'm just giving my 2 cents.

[AlternateRT]

This is very strange, if anything it should be faster. On my machine the plain release (used by nix) runs in about 193ms. I'm hesitant to think too much about anything related to intel macs tho, since its a far minority of users at this point.

Fair! I myself will be moving to an ARM mac in the near-future, so that's understandable.

This is basically what we do for nixpkgs: https://github.com/NixOS/nixpkgs/blob/77bbd72922d6b9f52151cea2d0dcbbf9f2581b69/pkgs/development/beam-modules/expert/default.nix#L51-L55

Oh 😅

I'd prefer if this was handled upstream (like ElixirLS) so that we can just symlink start_expert on the formula, but I won't press further on this.

I don't like that implementation and the naming is confusing. I'd rather just have the user manage it themselves, ...

FWIW, I have no strong attachment to the naming (it was simply the best I could come up with) and if the implementation can be improved, please do let me know how, I'm all ears.

This was really just for convenience and cleanness. I think it's a nice QoL to manage this for the user as well.

... or just add the hex and rebar lines to the deps recipe so it gets called when it runs that recipe. Not really a blocker for this tho.

The reason I chose to make a separate recipe is that deps is called twice by the burrito, burrito-local, and release recipes, so adding to it there would mean unnecessarily calling hex and rebar more than once.

---

Also note, I feel like the brew recipe should not use burrito, but we (expert team) are not going to be able to maintain the formula super closely, so you are free to maintain it as you wish! I'm just giving my 2 cents.

No, I agree! Using burrito is also fragile because of the zig dependency. ATM, burrito uses the latest version of zig, but when Homebrew inevitably updates it, this would lag behind. Switching brew to use a plain release makes sense.