Support multiple / relative directories for explicit Terraform binary path

[paultyng]

Related to #109, it would be useful to specify a relative path from the configuration directory to a Terraform binary, or to support a list of discovery paths.

[csaltos]

Yes, please !! ... I have a monorepo with a run for development and other run for production and it would be great to be able to have a way to declare a list of discovery paths, thank you !!

[radeksimko]

One concern I initially had about relative directories was that users wouldn't at first sight know what is the path relative to. However these concerns were recently basically addressed by turning CLI flags into LSP config options in https://github.com/hashicorp/terraform-ls/pull/588 - so we have a path that relative paths can be appended to (project root).

However before implementing this I'd really like to understand the use case for relative paths here because I'm not sure that treating project/workspace dir as root for relative paths is folks actually want/need.

@csaltos @bigbrozer Do you folks mind explaining your workflow/setup in more detail? Specifically why do you (want to) use a different Terraform binary per environment and how do you manage your Terraform installations, relatedly where on your filesystem would you install these Terraform binaries?

Have either of you tried using version management tool, such as these?

• https://warrensbox.github.io/terraform-switcher/
• https://github.com/Yleisradio/homebrew-terraforms
• https://github.com/asdf-community/asdf-hashicorp
• https://github.com/tfutils/tfenv

Generally speaking I would assume that maintaining some form of text/config file with a version is more sustainable than expecting anyone to install terraform directly (or as a symlink) into project dir.

Are there other reasons beyond versioning where relative paths would help?

[bigbrozer]

Meanwhile, we have now a terraform binary installed globally on developers workstation (always latest) and we have switched to a Python virtual environment where we install the terraform binary and version (eg. in .venv/bin) per projects to lock a bit and follow updates / deprecations etc... That's working well when we are using terraform on the command line (a shell with the virtual environment enabled where PATH contains .venv/bin/terraform relative to project dir).

(EDIT: The terraform binary installed system-wide is here to tests / prototype some stuffs using the latest release locally. The one inside the project virtual environment is here to ensure we have all the same version validated for this project.)

But, I have a doubt that the language server is still using the one provided globally (system-wide) instead of the one from the project virtual environment (.venv/bin/terraform) because PATH may be updated lately or when VSCode opens... Will try to dig into logs to ensure about this.

[csaltos]

Thank you for your messages.

The setup we currently use at my company is as follows:

• We have two environments: testing and production
• These two environments reuse common definitions in a shared folder
• We use the same version of Terraform for testing and production (no need to tfenv or Terraform switcher or similars)
• At the testing folder we can run terraform plan or terraform apply and it will affect only testing servers
• At the production folder, we can run separately terraform plan and terraform apply commands that will use only production servers
• Both runs use the mentioned common folder where the main piece of Terraform code definitions live

So, here is the feature we would like to have:

When we open the Terraform code we would like to have a way to set where is the starting folder, in this way we can set the production folder when we need production and the testing folder when we need it for testing servers.

A nice to have feature would be to have several Terraform starting folders at the same time.

Once again thank you for all your work and support. Since we are using Terraform and Terraform LS our lives become a lot more easy, productive, and happy.

[radeksimko]

@bigbrozer That makes sense. I think the venv workflow is very similar to the one provided/supported by direnv and most likely the other tools where the tool hooks into your shell and executes something to change the relevant environment upon cd https://direnv.net/docs/hook.html

I believe the best way we can support all these different tools and use cases would be (optionally?) loading shell environment, similar to how VS Code does it when it opens the builtin terminal. With that said I'm tempted to say that supporting explicit/static paths to TF binary would not serve these workflows very well as one would have to keep updating the list of paths constantly.

I'm inclined to close this issue in favour of https://github.com/hashicorp/terraform-ls/issues/69 and https://github.com/hashicorp/terraform-ls/issues/305 and/or even merge these two issues into one by describing more general-purpose mechanism as above.

---

@csaltos

These two environments reuse common definitions in a shared folder

Do you mind elaborating on this? Specifically what do you mean by "common definitions"? Would that be a locally shared module such as

module "network" {
  source = "../network"
  subnets = ["10.10.0.0/24", "10.10.1.0/24", "10.10.2.0/24"]
}

We use the same version of Terraform for testing and production

I'm struggling to understand why would you need a different path to Terraform binary for testing or production, if the version is the same?

When we open the Terraform code we would like to have a way to set where is the starting folder

Do you mind explaining the idea of a "starting folder" and how do you expect this to work in practice?

Thanks.

[github-actions[bot]]

Marking this issue as stale due to inactivity over the last 30 days. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

Thank you for understanding.

[github-actions[bot]]

Closing this issue due to its staleness.

If the issue was automatically closed and you feel it should be reopened, we encourage creating a new one linking back to this one for added context.

Thank you!

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.