fix: refactor flake.nix to build burrito app and allow elixir/erlang version overriding

[zoedsoupe]

firstly, thanks for all the hard work! 💜

the original flake.nix was derived directly from lexical since its the base source code, however expert uses a multi-app (not umbrella) setup and uses burrito for distribution.

those new requirements creates new complexities for the nix derivation building, so i need to make some tweaks, specially for burrito outputs artifacts.

i successflly builded on macos m1, whish if this PR makes sense for the project on medium-term time.

Closes #95

[Alt-iOS]

Hey, just wanted to say thank you for the fix!!

[zoedsoupe]

this new working derivation also introduces new 'dependencies' which will not reuse nixpkgs prebuilt cache

burrito only have prebuilt erlang_26 for at maximum version 26.2.5.9, which differs from the current (nixos-25.05) default erlang_26 version: 26.2.5.14, which causes burrito failure. this is kinda easy to solve though. this is the most frustrating part of this derivation, since it builds erlang, rebar3, hex and elixir from source, which on my macOS m1 took around 32min. using a prebuilt erlang binary from nixpkgs cache and that burrito have it would decrease that for compiling directly the mix release.

so, although this derivation works well, i would only proceed with this pr changes once burrito handles the latest release of otp26 version.

also, the derivation correctly only compile the desired burrito binary for the host target/system from nix.

[zoedsoupe]

i've also took the opportunity to simplify flake.nix to avoid using flake "helpers" like flake-parts and flake-utils, make it easier to extend it using only "raw" nix.

[mhanberg]

For nixpkgs, we don't really need to use burrito at all. Nix on Darwin systems also doesn't enable the network sandbox, but on NixOS it would actually fail because it would block burrito from downloading OTP anyway.

In Next LS, we opted for a standard mix release since nix is taking care of the dependencies.

Thank you for this patch tho, I'll take a look. I was working on this a couple nights ago but the monorepo aspect was making it difficult.

Question: does the beam workspace still work without flake-parts? nix-beam-flakes is a flake-parts module.

[zoedsoupe]

Question: does the beam workspace still work without flake-parts? nix-beam-flakes is a flake-parts module.

yeah, that's a nice question. i got excited to refactor and probably missed that. for now i will only come back with the flake-parts, however it will be necessary to change the exposed name lib since it conflicts with the beam-flakes module that is imported on top-level.

for burrito... well, we can just make a wrapper script indeed, but it was easier first just to rely on burrito, the main tricky part was indeed the multi-app setup - without umbrella. will try a version without burrito, like next-ls (i think lexical too) does

[mhanberg]

I pulled this down on NixOS, the beam workspace does not work, and it doesn't build.

In Next LS, we didn't use burrito because there really isn't any point. It can't download its own OTP builds because of the build sandbox (which isn't used on darwin, only Linux) and Nix already packages the software and distributes it, which defeats the point of Burrito.

Thank you so much for the effort, but I'm going to close this in favor of #106