Plugin discovery Issue

[lawrencegripper]

Hi,

Awesome work on the LSP!

I'm seeing an issue with nested modules and provider discovery. In the sample I have following folder structure.

What I see is that discovery is attempted at /deployment/environment/logicapp/.terraform/plugins/ not at /deployment/environment/.terraform/plugins/ where the root of the terraform project is.

Error is as follows, happy to look at fixing this up but probably won't be any time in the next few days.

2019/07/22 10:16:34 (*errors.errorString)(0xc0001c64d0)(Failed to find plugin: template. Plugin binary was not found in any of the following directories: [., /home/lawrence/source/external/terraform-lsp, terraform.d/plugins/linux_amd64, /home/lawrence/source/hacks/-/pipeline/deployment/environment/logicapp/.terraform/plugins/linux_amd64, /home/lawrence/.terraform.d/plugins, /home/lawrence/.terraform.d/plugins/linux_amd64, /home/lawrence/go/bin])

[juliosueiras]

will look into right now, since I might do is reverse ladder up in the dir(so going from the file dir all the way up to home directory)

[lawrencegripper]

Makes sense to me, guess you could go until the folder no longer contains any *.tf files as that is probably a good indicator that it's no longer the terraform project.

[chucknelson]

I have a similar issue on Windows, although it's not even nested - it's a very trivial random provider example. It doesn't even seem to be attempting to look in my workspace/project's /.terraform directory:

2019/07/22 21:43:28 [DEBUG] plugin dirs: []string{".", "c:\\Users\\chucknelson\\.vscode\\extensions\\mauve.terraform-1.3.12\\lspbin", "terraform.d\\plugins\\windows_amd64", "C:\\Users\\CHUCKN~1\\AppData\\Local\\Temp\\.terraform\\plugins\\windows_amd64", "C:\\Users\\chucknelson\\.terraform.d\\plugins", "C:\\Users\\chucknelson\\.terraform.d\\plugins\\windows_amd64", "C:\\Users\\chucknelson\\go\\bin"}
2019/07/22 21:43:28 [DEBUG] checking for provider in "."
2019/07/22 21:43:28 [DEBUG] checking for provider in "c:\\Users\\chucknelson\\.vscode\\extensions\\mauve.terraform-1.3.12\\lspbin"
2019/07/22 21:43:28 (*errors.errorString)(0xc00014f450)(Failed to find plugin: random. Plugin binary was not found in any of the following directories: [., c:\Users\chucknelson\.vscode\extensions\mauve.terraform-1.3.12\lspbin, terraform.d\plugins\windows_amd64, C:\Users\CHUCKN~1\AppData\Local\Temp\.terraform\plugins\windows_amd64, C:\Users\chucknelson\.terraform.d\plugins, C:\Users\chucknelson\.terraform.d\plugins\windows_amd64, C:\Users\chucknelson\go\bin])

Regarding this functionality in general - is it necessary for us to have the plugin installed at all?

There are many instances where I have terraform I'm maintaining but not running on my machine (i.e., it's running with special creds in a CI runner). The prior version didn't seem to require local plugin binaries to verify things, but maybe an LSP implementation has different requirements?

[lawrencegripper]

Yeah so looking at the way the code works the LSP is using the provider to dynamically discover the schema for the resource being used.

This, in my opinion, is ingenious as it will highlight errors based on the provider version used by the project not an arbritary version of the provider but I do see the issue with projects where terraform init hasn't been run.

One option we have is to install some set "Standard" providers into the /lspbin folder in the extension. This path is searched so it would allow completion and validation to work without terraform init being run.

Another would be to popup something in the vscode UI to prompt users to run terraform init to get full intellisense.

[lawrencegripper]

I think, for simplicity, I prefer the second approach. terraform init isn't a problem to run as it doesn't perform any actions on the infrastructure and it's nice and simple.

[chucknelson]

@lawrencegripper - I think in my use case, running terraform init will still be an issue, as if you have something like an S3 backend defined, it will still need credentials to access the S3 bucket where the state is stored.

Testing locally on a project at work, it looks like this can be avoided via terraform init -backend=false - it just downloads the plugins for my providers. According to the terraform init docs, though, I'm not sure this will work for all configurations, since some init actions apparently rely on the backend actually being configured.

Let me know if I'm missing something, thanks!

[juliosueiras]

P.S. because it search for all terraform folders including the root .terraform.d, so if you have a global provider binary there, it will default to that

[chucknelson]

@juliosueiras

P.S. because it search for all terraform folders including the root .terraform.d, so if you have a global provider binary there, it will default to that

Are we missing a path for where plugins are being searched, though? In my comment/scenario above, shouldn't it be attempting to look in <workspace/project path>\.terraform\plugins\windows_amd64?

[blairham]

What happens when you have a module that is not initialized with 'terraform init'? as those plugins don't even exists, I'm running into this now which is throwing a false positive error on every file in my module.

[pdecat]

Hi, I've submitted #23 which should resolve this issue.

[lawrencegripper]

Nice!