Partial native windows support
What problem are you trying to solve?
It would be nice to have devbox working natively on Windows without WSL.
What solution would you like?
I'd like at least the vscode devcontainer support to work in Windows. I imagine this to function as it would for non-Windows systems, using the Nix-based backend. I'd be interested to see whether this might work out of the box (although I expect that creating the devcontainer itself probably relies on Nix - so a Nix "bootstrapping" container would probably be required for Windows).
For a truly native experience, a different backend would have to be used for windows, since Nix does not (and probably will never) support Windows.
Some Nix-alternatives to use for providing a native Windows backend:
- https://github.com/aquaproj/aqua
- https://github.com/moonrepo/proto
- https://github.com/prefix-dev/pixi/
- https://github.com/version-fox/vfox
- https://github.com/jdx/mise
From my experience, aqua is the least restrictive (that is, "less opinionated") tool, and the most responsive to user feedback. It is written in go, and might even be possible to use as a library.
I am also having much success with mise on Windows, and it seems to be the most versatile in that it offers many different backends, including aqua and ubi.
Alternatives you've considered
No response
@mjgallag @gcurtis The comment above looks very suspicious.
@W1M0R Thank you for pointing it out. I hid those spam comments and reported the users to github.
@W1M0R
For devconainer support, we use devbox itself to setup the environment inside the container. Given most containers are Linux based, that shouldn't cause a problem even if the container host is Windows. As for generating the devcontainer settings via Devbox, we provided that as a convenience tool but it doesn't mean the devcontainer.json and Dockerfile that is required for devcontainer setup has to be generated via Devbox.
With that said, I suggest you generating those file via devbox generate devcontainer in WSL and then trying it in Windows with Docker installed and running to see if devcontainer connection works.
Thanks for the tip @mohsenari
@mohsenari I gave your suggestion a try. It looks like it could work, but I'm running into the following error:
...
[4759 ms] Start: Run: docker ps -q -a --filter label=devcontainer.local_folder=c:\Users\user2\sdl --filter label=devcontainer.config_file=c:\Users\user2\sdl\.devcontainer\devcontainer.json
[5258 ms] Start: Run: docker inspect --type image jetpackio/devbox:latest
[5767 ms] Start: Run: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f C:\Users\user2\AppData\Local\Temp\devcontainercli\container-features\0.65.0-1724849351682\Dockerfile-with-features -t vsc-sdl-184efe9025c41d9f92e5a0cef3dc276ee837f28be9a7ac7ff59572504f995093 --target dev_containers_target_stage --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label c:\Users\user2\sdl
[+] Building 0.0s (0/0) docker:default
2024/08/28 14:49:14 http2: server: error reading preface from client dummy-1: read |0: file already c
[+] Building 12.7s (10/11) docker:default
=> [internal] load build definition from Dockerfile-with-features 0.4s
=> => transferring dockerfile: 771B 0.1s
=> [internal] load metadata for docker.io/jetpackio/devbox:latest 0.0s
=> [internal] load .dockerignore 0.1s
=> => transferring context: 2B 0.1s
=> [dev_container_auto_added_stage_label 1/7] FROM docker.io/jetpackio/devbox:latest 0.0s
=> [internal] load build context 0.1s
=> => transferring context: 65B 0.1s
=> CACHED [dev_container_auto_added_stage_label 2/7] WORKDIR /code 0.0s
=> CACHED [dev_container_auto_added_stage_label 3/7] RUN mkdir -p /code && chown devbox:devbo 0.0s
=> CACHED [dev_container_auto_added_stage_label 4/7] COPY --chown=devbox:devbox devbox.json d 0.0s
=> CACHED [dev_container_auto_added_stage_label 5/7] COPY --chown=devbox:devbox devbox.lock d 0.0s
=> ERROR [dev_container_auto_added_stage_label 6/7] RUN devbox run -- echo "Installed Packag 11.9s
------
> [dev_container_auto_added_stage_label 6/7] RUN devbox run -- echo "Installed Packages.":
6.798 Info: Ensuring packages are installed.
11.84 Error: error running script "echo" in Devbox: Head "https://cache.nixos.org/7p3n0svlfnhc29qxv5j
20mv2npmiaddm.narinfo": context deadline exceeded
11.84
------
Dockerfile-with-features:15
--------------------
13 |
14 |
15 | >>> RUN devbox run -- echo "Installed Packages."
16 |
17 | RUN devbox shellenv --init-hook >> ~/.profile
--------------------
ERROR: failed to solve: process "/bin/sh -c devbox run -- echo \"Installed Packages.\"" did not compl
ete successfully: exit code: 1
[22236 ms] Error: Command failed: docker buildx build --load --build-arg BUILDKIT_INLINE_CACHE=1 -f C:\Users\user2\AppData\Local\Temp\devcontainercli\container-features\0.65.0-1724849351682\Dockerfile-with-features -t vsc-sdl-184efe9025c41d9f92e5a0cef3dc276ee837f28be9a7ac7ff59572504f995093 --target dev_containers_target_stage --build-arg _DEV_CONTAINERS_BASE_IMAGE=dev_container_auto_added_stage_label c:\Users\user2\sdl
[22236 ms] at mtA (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:466:1933)
[22237 ms] at async Pm (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:465:1856)
[22237 ms] at async NH (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:465:610)
[22237 ms] at async KtA (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:482:3771)
[22237 ms] at async eB (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:482:4886)
[22238 ms] at async hrA (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:663:200)
[22238 ms] at async lrA (c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js:662:13452)
[22258 ms] Exit code 1
[22264 ms] Command failed: C:\Users\user2\AppData\Local\Programs\Microsoft VS Code\Code.exe c:\Users\user2\.vscode\extensions\ms-vscode-remote.remote-containers-0.380.0\dist\spec-node\devContainersSpecCLI.js up --user-data-folder c:\Users\user2\AppData\Roaming\Code\User\globalStorage\ms-vscode-remote.remote-containers\data --container-session-data-folder /tmp/devcontainers-3cdd33a1-1e04-4da6-b306-02ab1b7a97ba1724849345101 --workspace-folder c:\Users\user2\sdl --workspace-mount-consistency cached --id-label devcontainer.local_folder=c:\Users\user2\sdl --id-label devcontainer.config_file=c:\Users\user2\sdl\.devcontainer\devcontainer.json --log-level debug --log-format json --config c:\Users\user2\sdl\.devcontainer\devcontainer.json --default-user-env-probe loginInteractiveShell --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root --terminal-columns 101 --terminal-rows 14 --include-configuration --include-merged-configuration
[22265 ms] Exit code 1
This looks like the relevant error:
> [dev_container_auto_added_stage_label 6/7] RUN devbox run -- echo "Installed Packages.":
6.798 Info: Ensuring packages are installed.
11.84 Error: error running script "echo" in Devbox: Head "https://cache.nixos.org/7p3n0svlfnhc29qxv5j20mv2npmiaddm.narinfo": context deadline exceeded
I suspect this is not a devbox issue. I wonder if there is no internet access from within the container. I'll play around some more.
Did you get any further @W1M0R ? I'd really love to use Devbox to configure our entire cross-platform CI fleet if possible, but the lack of native Windows support is a showstopper.
@griels No, I haven't looked into this again. In principle it should still work, but I'm no longer interested in the devcontainer approach.
I'm now using mise for the cross-platform bits, and devbox for the linux-specific bits, and just to choose between the two based on the platform. This approach is working well, and has nice performance advantages and a pretty good developer experience, but it comes with some additional complexity.
Thanks @W1M0R - yes, Mise/Pixi have been the other things I looked at. I'll check out Just. I'm also in touch with some folks working on Cygwin support for Nix so hopefully at some point in the distant future devbox can just use this.