[Documentation]: VS Code integration with the direnv extension

[apgrucza]

The Devbox documentation makes mention of the Devbox VS Code extension and dev containers, but neither currently provide VS Code users with an adequate experience (as described in #1001). In that issue it was identified that the direnv VS Code extension provides a more streamlined Devbox experience. I find this approach preferable to dev containers, which negate the benefits of Devbox as a Docker-free solution.

I wish I'd come across the direnv extension earlier, as I spent a lot of time looking for workarounds and nearly gave up on Devbox. Having it in the Devbox documentation could prevent others having the same experience.

Note the known issues with this extension. There are two other direnv extensions in the marketplace, but I've not tried them.

[Lagoja]

@apgrucza we had some struggles with the direnv extension + Devbox in the past, but if it's working well we can consider recommending it. Does your project work well since you installed it?

We've made changes to our direnv integration, so it's possible that we're now at a state where they work well together

[Lagoja]

Did some testing with a few example projects, and this seems to work reasonably well if a .envrc file is present. There are some limitations highlighted in the extension's docs that are worth noting.

• The Direnv Extension doesn't seem to work with tasks of process type
• There seem to be reports where the Direnv Extension does not set the environment quickly enough for other extensions to detect and load the new environment

I still think it's worth recommending as an option. Some next steps we could take on this issue:

1. Add a note about the Direnv extension to the Direnv + VSCode pages in our documentation
2. Test the IntelliJ Direnv extension to see if that also helps with IntelliJ setup

I would also still like to find a way for Devbox to work with VSCode and other editors without having dependencies on direnv + the direnv extension.

[apgrucza]

The direnv extension worked well for my Devbox trial, but I didn't do extensive testing (I tried the terminal, a task of type shell, Python debugging and an extension that tries to execute a locally installed tool).

To remove the dependency on direnv, perhaps some functionality could be copied from the direnv extension into the Devbox extension.

Good IDE integration is pretty important in ensuring Devbox gains wider adoption. If Devbox can work with both VS Code and IntelliJ IDEs, that might make it a more attractive option than Dev Containers (which are currently VSCode-only). But this IntelliJ issue suggests that the direnv plugins don't work particularly well.

[mohsenari]

@apgrucza We're looking into how direnv extension is handling environment management to see if we can implement setting environment in devbox extension as well.

The main issue is we can't be sure when vscode language extensions (golang, python, java etc.) read the env variables such as $GOPATH, $PYTHONPATH, or $JAVAHOME etc. because devbox extension needs to set or override those env variables before they're read by a language extension. The other issue is, we don't know how it affects debugging and vscode tasks.

So the ideal case is if the user runs devbox shell and then code . to open vscode from inside the devbox environment. Or alternatively, if direnv is setup, cd project_dir and then code . because that way, the vscode process starts in a devbox environment before any of its extensions are loaded.
But that doesn't usually happen to be the case. Usually, you have vscode open and you open the workspace directory from within vscode. In that case, the best an extension can do is to play with process.env and that's what direnv extension does (as far as I know). So right now we're testing updating process.env to see how it affects vscodes integration with a devbox environment.

If possible, would you mind sharing the tests you ran for tasks and python debugging?

[mohsenari]

For more context around this very issue, see this thread.

[apgrucza]

@mohsenari See #1028 for the test I did with tasks.

For Python debugging, I used the Python extension.

In devbox.json:

{
  "packages": [
    "python310",
    "python310Packages.pip@23"
  ],
  "shell": {
    "init_hook": ". $VENV_DIR/bin/activate"
  }
}

In .vscode/settings.json:

{
    "python.defaultInterpreterPath": "${env:VENV_DIR}/bin/python"
}

In .vscode/launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": true
        }
   ]
}

Then I opened a .py file, added a breakpoint with F9, and started debugging with F5.

[mohsenari]

@apgrucza I'm just putting a comment here to give a small update.
I've been working on adding a better integration between devbox and vscode that works better than direnv extension.
The PR is out but it's still needs a bit of cleanup and review. But to summarize, it allows for changing the process environment in which vscode runs to a devbox environment as if you opened vscode from a devbox shell. I'll ping here again once the PR is merged and the feature is out.

[apgrucza]

@apgrucza I'm just putting a comment here to give a small update. I've been working on adding a better integration between devbox and vscode that works better than direnv extension. The PR is out but it's still needs a bit of cleanup and review. But to summarize, it allows for changing the process environment in which vscode runs to a devbox environment as if you opened vscode from a devbox shell. I'll ping here again once the PR is merged and the feature is out.

Thanks for the update, it sounds promising. Are you planning to have a setting in the extension for enabling the new "pure" mode? Or perhaps there should be a setting in devbox.json to enable pure mode for all users, as suggested by @codethief over here.

[mohsenari]

@apgrucza oh both are very good suggestions, I haven't considered that. I have to do some testing to see how it works in vscode. Let me discuss with the team to see where we land on it.

[mohsenari]

@apgrucza we just published a new version of devbox VSCode extension that has the ability to reopen VSCode in a devbox environment.
Unlike direnv extension, we change the environment variables of the vscode process (hence the reopening). That means other extensions and vscode settings will point to your devbox packages if they look for an executable (e.g., python). It was a challenging task to overcome, but it is pretty much the same as opening vscode from a terminal that has devbox shell enabled.

Here is the link to the extension, but you can install it via VSCode extension search when you search for "jetpack devbox".
Please give it a try by doing these steps and let us know if you have any feedback:

1. opening a project in vscode that has a devbox.json
2. opening command palette (cmd+shift+p) and searching for "reopen in devbox"
3. once vscode is reopened, confirm if env variables in vscode's terminal are set correctly to your devbox environment. (It updates the env variables in all of vscode not just the terminal, but it's harder to check env variables outside of terminal in vscode).

[apgrucza]

@mohsenari not sure if you want the feedback here or in a separate issue.

The first time I selected "reopen in devbox", I saw the popup saying that it was installing packages, and then the VS Code window closed before it had finished and did not reopen. Now when I try again, the VS Code window closes immediately and also does not reopen. It seems like it might be crashing.

I am using WSL - I wonder if that might be related.

[mohsenari]

@apgrucza feedback here is fine for now. For WSL, I'm not sure if this feature works. Reason being, we do process communication between VSCode and devbox CLI. Then devbox CLI spawns a new instance of VSCode with env variables set to devbox environment. But in WSL, VSCode is on the Windows side and devbox CLI is in Linux subsystem so when the CLI tries to open a VSCode instance, it fails and you won't see the reopening part of the flow.

I will try WSL on my own machine to see if there is a way around it. Otherwise, I'll build the safeguards to show the proper error message that this feature isn't supported WSL or windows.