Gleam Executable Detection in VSCode with Nix Flakes

[jordangarrison]

I’ve really enjoyed exploring Gleam—what a fantastic ecosystem! This extension has been incredibly useful, but I’ve encountered a small issue detailed below. If there’s any way I can assist with resolving this or if I’ve duplicated an existing issue, please let me know.

Description

It appears that a cached path setting prevents VSCode from recognizing the updated path of the Gleam executable when using Nix Flakes. Each time a new Nix development shell is instantiated in a separate directory (for a new project), the path to the Gleam executable changes, leading to detection issues in VSCode.

Error Message

When this issue occurs, the following error message is shown:

[Error - 10:02:36 PM] Gleam Language Server client: couldn't create connection to server.
Launching server using command gleam failed. Error: spawn gleam ENOENT

Reproduction Steps

1. Use a flake.nix setup similar to the example below.
2. Open a new project in a separate directory and initiate a development shell.
3. Observe the error in VSCode indicating that the Gleam executable path is not found.

Example flake.nix File

{
  inputs = { nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable"; };

  outputs = { self, nixpkgs }:
    let
      systems = [ "x86_64-linux" "x86_64-darwin" "aarch64-darwin" ];
      forEachSystem = nixpkgs.lib.genAttrs systems;
    in {
      devShells = forEachSystem (system:
        let
          pkgs = import nixpkgs {
            inherit system;
            config.allowUnfree = true;
          };
        in {
          default = pkgs.mkShell {
            buildInputs = [ pkgs.gleam pkgs.erlang pkgs.rebar3 ];
          };
        });
    };
}

Current Workarounds

1. Disable and Re-enable the Gleam Extension in VSCode

Disabling and re-enabling the Gleam extension temporarily resolves the issue, allowing VSCode to recognize the current executable path.

2. Define All Gleam Projects Under a Shared Parent Directory

Placing all Gleam projects under a single parent directory with a shared flake.nix file resolves the path issue. However, this approach limits the flexibility of using flake.nix for unique, project-specific environments.

Environment Details

• Local Machine: MacOS Sequioa
• Development Environment: VSCode Remote SSH Development connected to a NixOS server (LTS)
• Shell Setup: Using the above flake.nix configuration for each project
• Shell Setup: direnv executable loads a .envrc file with the contents use flake on opening project or cding into a directory
• VSCode: Extension for Direnv to load the shell into the editor context (for LSP support inside the direnv shell context)
• VSCode: Extension for Nix Environment Selector (Somewhat redundant with the Direnv extension)

Expected Behavior

The Gleam executable path should be dynamically detected for each project?

Additional Context

Any guidance on resolving this path-caching issue would be greatly appreciated, as the current setup is needed for maintaining isolated development environments for each project.

[lpil]

Hello! Nix produces a large support demand on Gleam core compared to other third party things, and it takes up more of our time than we can afford to spend on any one small subset of users when we could be working on things that benefit everyone, especially since the problems originate from Nix itself. Because of this we cannot do any Nix specific work. A PR would be accepted for small and easy to understand and maintain features that aid Nix folks, but ideally they would not be Nix specific.

[jordangarrison]

@lpil Totally understand and thank you for the context, nix is a unique environment and I don't want to add any burden to building out tooling for this wonderful language. I’ll fork the repo and try to dig deeper into this. I hope to identify whether the issue is rooted in changing file paths for the Gleam executable, something related to using the LSP integration with VSCode's Remote Development over SSH, or if it’s specifically tied to Nix’s behavior.

Currently, I’m working around it by:

1. Disabling the extension in VSCode
2. Reloading the editor
3. Re-enabling the extension

While it’s a bit tedious, it allows me to work on a single repo with a flake setup.

The flake’s effect is updating the path of the executable, so my initial suspicion is that the issue might be related more broadly to changing paths and potential caching behavior rather than being exclusive to Nix development environments. Is it the expectation that the file path for the Gleam executable should remain consistent and not change?

To test these theories I'm hoping to do the following (I'll try to remember to update this as I find out):

• See if this is present in other tools like asdf
• See if this is present using nix flakes on MacOS using VSCode locally
• See if this is present using nix flakes on NixOS locally (not over SSH)
• See if this is present in other editors using Nix Flakes

With this info I think we can determine if this is an issue with Nix and Nix Flakes, VSCode Remote Development or some behavior in the extension.

I’ll keep investigating. Thanks again for your input and let me know if you think this isn't the correct way to go about this.

[lpil]

Is it the expectation that the file path for the Gleam executable should remain consistent and not change?

No, you can change the executable location at any point and it will be used so long as it is on the PATH you have given to VSCode. This extension relies entirely on the operating system for executable discovery.

If you want to change you path variable you will need to update any already-running processes with this new environment configuration, in this case VSCode.

Currently, I’m working around it by:

You don't need to disable and re-enable the extension. It does not persist any state.

[jordangarrison]

@lpil Thanks for the helpful context. I believe the issue I’m encountering may not be directly related to Nix or Nix Flakes, but rather tied to VSCode Remote Development over SSH. I’ll continue investigating to better understand the root cause.

The more specific behavior I’ve noticed is that if the connection with the language server is interrupted—such as when changing locations and closing my laptop—it seems to cause issues. I’ll dig deeper to see what might be happening in these scenarios.