Workspace-local terraform-ls.terraformExecPath or otherwise set terraform version per-project

[cspotcode]

Versions

This feature does not yet exist in:

• the latest version of the extension (below)
• the latest version of the language server (below)

Extension

HashiCorp Terraform v2.20.0

Language Server

terraform-ls 0.25.2

Problem Statement

My team has different projects on different versions of terraform, some 0.12, some 0.13. It is not always easy to upgrade. Instead, we use locally-vendored versions of terraform. This allows engineers to switch between projects and always be using the correct version of terraform. In the absence of clear guidance from the terraform ecosystem -- at least, I haven't seen any -- we use a git submodule and symlinks. ./tools/linux/terraform is symlinked to the correct version, and this symlink is committed to git. Our scripts put ./tools/linux onto the PATH.

The problem is that "terraform-ls.terraformExecPath" cannot be declared as a relative path.

I would like to declare this in our .vscode/settings.json and commit it to git:

{
    "terraform-ls.terraformExecPath": "${workspaceFolder}/tools/linux/terraform",
}

The ${workspaceFolder} convention comes from https://code.visualstudio.com/docs/editor/variables-reference

Expected User Experience

Engineers on my team can git clone a terraform project, open it in VSCode, and have the language service use the correct version of terraform for that project with as little intervention as possible.

Proposal

Described above in Problem Statement

References

[jpogran]

This is an interesting request! We have not had someone request using binaries vendored inside the workspace before, usually people have used PATH adjustments or tfenv to choose which binary to execute.

This setting is already resource scoped, so the VS Code scoping rules apply and we will get the correct value depending on if its a single folder with one .vscode/settings.json or a multi-root workspace with a code-workspace file.

The place to adjust is the LS since we read the setting value at initialization only. We'll have to change the LS to request the setting value dynamically at execution.

There are a few other planned features to finish we already have in flight, I'll add this to our backlog refinement to discuss in planning.

[cspotcode]

I'm happy to switch to tfenv if you feel that is a better way to handle this situation. I hadn't seen it before. Now that I look at the readme, it appears that running tfenv's terraform shim will always delegate to the correct version of terraform for the local project? That does sound like exactly what I'm looking for.

[jpogran]

I think this is more a 'what works for you' rather than a qualitative assessment. I think we can support both workflows without hurting things, it will just take some time to enable this one. You might try out the tfenv one until we (potentially) get this in and see which one suits your needs.

[cspotcode]

I tested tfenv and it is working well, so I've switched my project to tfenv and removed the vendored binaries. Thank you for the recommendation. I feel comfortable closing this ticket if you agree.

[radeksimko]

I think we'll need to find a way to do per-workspace configuration anyway - e.g. for hashicorp/terraform-ls#24 so I would keep it open but I am glad it worked for you.

As for tfenv - you may want to be aware of tfutils/tfenv#196

There are some alternatives also listed here hashicorp/terraform-exec#6