Julia not on PATH using the default Julia devcontainer

Code to Cloud Codespaces Beta
#1

I am trying to test Github codespaces with a Julia project. I am using this devcontainer.json: https://github.com/microsoft/vscode-dev-containers/blob/b384de8d7bb7dbf58cedbeb8212d72ed49132581/containers/julia/.devcontainer/devcontainer.json

However Julia is not on the path in the container causing the “postcreatecommand” to fail as well as the extension not loading properly. I have tried to modify the devcontainer using the following command:
“remoteEnv”: { “PATH”: “${remoteEnv:PATH}:/usr/local/julia/bin” }
without any success.

vscode ➜ ~/workspace $ julia
bash: julia: command not found

vscode ➜ ~/workspace $ echo $PATH
/home/vscode/.vscode-remote/bin/5e350b1b79675cecdff224eb00f7bf62ae8789fc/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/home/vscode/.local/bin:/home/vscode/.local/bin

The strange this is that by observing the log file it seems as the path is set properly at some point:
[2020-12-04 13:04:02.559 Agent.Workspace I] VSCode (0) [STDOUT]: JULIA_PATH=/usr/local/julia
[2020-12-04 13:04:02.559 Agent.Workspace I] VSCode (0) [STDOUT]: PATH=/usr/local/julia/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/julia/bin…

Any help av advice is appreciated!

#2

Strange - that shouldn’t be happening and does not preproduce in the VS Code Remote - Containers extension so there’s something going on with Codespaces. Will raise an internal issue on this.

#3

Can you try using containerEnv instead of remoteEnv when updating the PATH? RemoteEnv only applies to the VS Code server process tree, but postCreateCommand is executed as a separate process in the container, so it only sees the containerEnv.

#4

@jkeech To be clear, the image itself has the PATH set correctly - but that might work as a workaround.

It also appears to affect other things like the python image/definition where py-utils is not in the path. Things that work are because they’re in the system path.

#5

Thanks for the quick replies. Tried again now and it is working… seems like someone has fixed something behind the scene? It may have been an issue related to the terminal/shell because now sh is the default shell but I believe it was bash before. At least the prompt is just a $ nothin else. Anyway happy that it works now and ready for some experimenting this weekend.

#6

We rolled back a recent change. We do plan to switch back to bash as the default for custom containers and will ensure this scenario works before re-enabling. Thanks for reporting!