fix: support multiple elixir versions on multiroot projects#413
fix: support multiple elixir versions on multiroot projects#413
Conversation
cd60477 to
3a54178
Compare
3a54178 to
245f890
Compare
|
@giddie could you verify if this PR works in your setup? Thank you! |
|
Yeah, still seems OK. Looks like the fallback is working as intended 👍 |
🤖 I have created a release *beep* *boop* --- ## [0.1.0-rc.2](v0.1.0-rc.1...v0.1.0-rc.2) (2026-02-24) ### Features * add `instance_id` metadata to logs ([#380](#380)) ([5c209be](5c209be)) ### Bug Fixes * ensure `MIX_BUILD_PATH` is set for child processes ([#436](#436)) ([3178302](3178302)) * **expert:** check start_child return in initialized handler ([#371](#371)) ([de979ce](de979ce)) * forward logs through window log handler ([#418](#418)) ([c608dc8](c608dc8)), closes [#382](#382) * support multiple elixir versions on multiroot projects ([#413](#413)) ([dee595d](dee595d)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
@doorgan unfortunately I think this patch is making it not work for folks (like myself) who use Nix and devshells. The devshell puts the locations of the tools it installs directly in the path, and doesn't activate when we boot a login shell in the project directory because the user might be using direnv to load it or they manually do So when we reset the PATH to do the login shell, all those exes are lost and it can't find them (and they might not be installed globally) |
|
@mhanberg Does the fallback method work if you |
|
Looking at the logs, showing this for me right now I think it finding the erl from the expert build might be related to the nix packaging right now. It did actually end up finding the right elixir tho. |
|
I'm confused, this PR brings back old behavior. I'll take another look because it's odd that it reports failure to find the executables, but then finds them all of a sudden |
#344 fixed the case when SHELL isn't available and we can't use it to find elixir, but apparently that change causes us to only be able to find a single elixir version in a multiroot project, so we need the shell approach too.
This PR reintroduces the shell approach, and adds the #344 as a fallback if SHELL is not available.
Testing this I also found that having multiple projects with different elixir versions made them download different hex versions, and that sporadically caused issues on my tests, so I had to make expert remove more environment variables than we did before.
Also on windows I am now using mise, which has the elixir shim as
elixir.cmdand Expert was struggling to find it even if it was in the path.