`mix setup` fails to compile `gleam_stdlib` in a default Phoenix project

[zakw]

Hello,

I originally commented this in gleam-lang/gleam#3483 (comment) but realized this was probably a more appropriate place.

I believe I have a reproduction of the issue that @mradke ran into.

For me, it was in the context of attempting to add Gleam to an existing Phoenix application. The default Phoenix template has a slightly more involved mix.exs than a default mix new project so perhaps that's what was masking the discovery of this issue.

Running mix setup results in the following build errors for me:

==> gleam_stdlib
could not compile dependency :gleam_stdlib, "mix compile" failed. Errors may have been logged above. You can recompile this dependency with "mix deps.compile gleam_stdlib --force", update it with "mix deps.update gleam_stdlib" or clean it with "mix deps.clean gleam_stdlib"
==> gleam_test
** (Mix) Could not find a Mix.Project, please ensure you are running Mix in a directory with a mix.exs file

Here is a simplified repo with each commit representing the set of steps to reproduce and subsequently "fix" the issue with a hack:
https://github.com/zakw/gleam_mix_test/commits/main/

Steps to Reproduce

1. Ensure Phoenix is installed mix archive.install hex phx_new (see https://hexdocs.pm/phoenix/installation.html)
2. Create a new default Phoenix project mix phx.new gleam_test --database sqlite3
3. Add Gleam compiler and dependencies support following the standard README.md
4. Run mix setup

Note: In-between test attempts I would run git clean -xdf to ensure I had a clean, first-time environment before running mix setup again.

Observations

• The first time mix setup is invoked, the gleam_stdlib fails to compile. It appears to compile after a subsequent invocation of mix setup and continue with the application first-time setup.
• If you instead invoke mix deps.get and then run mix setup, separately, it builds and runs without issue even though setup invokes deps.get, itself
• No amount of tweaking or adding compile, deps.compile, deps.compile gleam_stdlib to the various aliases seemed to avoid the first-time compilation issue

The "Fix"

My hack fix was to modify the gleam.deps.get command to cmd mix gleam.deps.get to run it in a separate process. My sneaking suspicion is that either:

• a) there is some post-invocation magic that gleam.deps.get does which is not properly captured by the setup alias pipeline or
• b) there is some environment issue induced by gleam.deps.get that is avoided by running it in a separate process

This "hack fix" is illustrated, here:
zakw/gleam_mix_test@1be6c9c

I'm unsure what the true underlying issue is or what the appropriate solution is, but I thought I'd illustrate my findings here in case that helps point someone who knows more about this system in a good direction.

System Environment

• Windows 10 22H2 x64
• Powershell 7.5.4
• VS Code 1.107.1
• Erlang/OTP 28
• Elixir 1.19.4
• Phoenix 1.8.3
• Gleam 1.14.0

Originally posted by @zakw in gleam-lang/gleam#3483 (comment)