Workspace not initialized #329
Comments
|
Yes, we plan to add an initialization workflow where the extension prompts. We can use this as the tracking issue (I'm still working my way through issue cleanup and creation). |
|
I'm also getting a similar error for a multi-repository workspace. One repo is not a terraform project, and the other repo has multiple terraform root folders within it (terraform mono-repo?). |
This isn't just a matter of there not being a built-in workflow. It's totally impossible to resolve this. It instructs me to run |
|
@forstermatth unfortunately multi-folder is not yet supported by the LS. There is a possibility of doing multiple LS's per folder, or supporting multiple folders in a single LS process, and I don't know that we have chosen a direction yet, you can track that in #330 |
|
@smiller171 what Terraform version are you on? ( Update I should work on my log reading skills, disregard the output comment! |
|
well, guess it'll be a while before the new language server is even remotely ready for me then. re:multi-folder support unfortunately I can't even get the workflow working for configuring a different language server so I can keep using the old one. @paultyng The run in the logs here was |
|
@muram that'd be because this new version isn't published yet, you need to sideload it. Also your comment is totally irrelevant to this issue. |
|
@muram you'll need to manually download and install it from the GitHub releases page. It won't hit the marketplace until next week or the week after most likely. |
|
Got it, thank you @smiller171 @paultyng and sorry for hijacking this thread BTW, now I've the same exact issue reported by @sgmiller , so I'm in the right place now 😄 |
The version is output in the logs, from @smiller171's output;
|
|
@smiller171 I really appreciate you trying this and providing feedback and understand if its possibly too rough/early for you. One more data collection thing, can you manually run the command referenced in that output log: My guess is this is |
|
You can manually override how Usage: terraform-ls serve [options]
Starts the Language Server
Options:
-log-file string
path to a file to log into with support for variables (e.g. Timestamp, Pid, Ppid) via Go template syntax {{.VarName}}
-port int
port number to listen on (turns server into TCP mode)
-tf-exec string
path to Terraform binary
-tf-exec-timeout string
Overrides Terraform execution timeout (e.g. 30s)
-tf-log-file string
path to a file for Terraform executions to be logged into with support for variables (e.g. Timestamp, Pid, Ppid) via Go template syntax {{.VarName}}"terraform.languageServer": {
"external": true,
"args": [
"serve",
"-tf-exec=/home/paul/go/bin/terraform",
]
}, |
This is in a pretty small module. |
|
Just to provide some explanation/background, this error
would be returned when this path doesn't exist: filepath.Join(dir, ".terraform",
"plugins",
runtime.GOOS+"_"+runtime.GOARCH,
"lock.json")where This is the default path to the plugin cache lock file; an implementation detail of how Terraform keeps track of providers locally after they are downloaded via This is admittedly a very simplified way of detecting whether a workspace was initialized and as such is has some known flaws:
All of the above cases are valid use cases we want to support, just bear in mind that this is an initial release, so we did take some shortcuts (including not supporting the above yet) to gather early feedback and better gauge the priorities based on it. With that in mind - does any of the above describe your situation? If not - can you please check if the lock file exists in the root of the directory you are opening in VSCode under Thank you all for sharing this early feedback! |
|
I made some comments in #275 and was asked to look here for one of the problems I came up against. I think this explains why This explains the problem I was seeing. |
|
@marksmall Understood, that is a valid use case we intend to support. Have you tried opening the Relatedly am I right to say that you would normally run |
|
@radeksimko That is probably what I'll end up doing as a workaround while this problem is being fixed. It's not a big deal for me in the grand scheme of things. As to you your question on |
|
@radeksimko I don't think any of these describe my situation. Is it possible that lock file is not created if no plugins are in use? The lock file does not exist for me, and I have run |
Yes, that is certainly possible. I suppose that use case would be described as "I'm starting from scratch and don't have any code yet"? Which is also a totally valid (and common) use case we want to support. One way we can support that is by not erroring when schema isn't available on initialization as per hashicorp/terraform-ls#83 |
I think there's only one plugin we ever use, and it's an in-house plugin that we'll be deprecating once custom validation is in a good place. We have more than 70 terraform repos and I think that's the only plugin we use in any of them. |
|
@smiller171 If there is one plugin then there should be a plugin cache and therefore a lock file. Can you share some details about how/where you run
I'm having trouble understanding how could you use Terraform without any plugin - it doesn't seem very useful on its own? So just to clarify - when I say plugin I mean a provider (like any provider from https://github.com/terraform-providers/). Are we on the same page? 😅 |
|
@radeksimko ok, I didn't realize that providers show up as plugins. This is still an issue for nearly all of our modules because it only creates the When I explicitly call the provider and init the directory and lockfile are created, but this isn't ideal within a child module.
|
|
ok, I've just realized that the plugins lock is also created if I add the providers I'm using to |
|
Hashicorp took the initiative to work on this project. Of course they need to think this through. |
|
@smiller171 |
|
oh...that's not good... |
|
I have things structured in the Terragrunt style, with an infrastructure-live repo that contains only terragrunt.hcl files that reference modules, and a modules repo that contains said Terraform modules. I used to use this extension to keep those modules and hcl files properly formatted and linted. I don't ever run Terraform commands from my local Terraform folders. I have automation that pulls down repos and runs commands as part of it's build/deploy. This extension has basically become useless for me now, since I don't have the root modules folder init'd. |
This would be our use case. We use our own variant of tfutils/tfscaffold, which does indeed set the TF_PLUGIN_CACHE_DIR to something other than ./terraform by default (due to it cd-ing into a component directory). So it would be good to see the option to provide the option to specify the directory, rather than just auto-detect it. |
|
My use case is within:
I tried disabling the language server as a workaround, but it still produces the error message at startup. Is that expected? Is there any other way to disable the LS other than by using the command in the interface (configuration files etc)? |
|
FYI, the downgrading issue is an upstream VS Code issue (see microsoft/vscode#99699 (comment)). We will track the upstream in #385 and provide updates there. |
|
Hello folks, yesterday I ran into this issue and found the reason in the way I work. |
This worked for me also, running WSL as my default terminal within VS Code. |
|
@mieseprem Btw. Also the Remote - WSL extension may help you a lot with this workflow. It allows basically to run the whole VS Code in the context of WSL and so you would not need to run a second init in Windows nor you need the Windows Terraform executable at all. |
quick and simple workaround! Thanks for the hint. |
|
I too hit this issue, the way I worked around it was to copy a random configuration from the examples folder into the root of my github repro forked directory, opened a windows command prompt to that folder and ran the |
|
The workaround I used and it works. I copied a This solved the issue. But is a horrible workaround. |
|
Reporting another horrible workaround: made a symlink in the root dir of my project:
My dir structure: |
|
Hi, Terraform. Can we please put a note in the Extension readme that explicitly states that multi-folder workspaces are not supported - along with any other caveats of expected and not supported folder structures? Would have saved me 2 hours today, probably hundreds (thousands?) of hours per month across all users. Thank you!! |
|
Fwiw, I still haven't gotten the features to work properly but it sounds like that's because in addition to using multi-folder workspaces exclusively, I'm also using non-traditional folder structures. 🤦♂️ I'm strategically deciding to just give up for now and live without the autocomplete and syntax-highlighting goodness, but will watch this thread for resolution. Please someone post these caveats to the readme of the extension. 🙏 UPDATE: I'm feeling empowered now. Apparently it's all in the repo and I can just create a PR. :) #430 is ready for review. |
Proposal for review: #430 |
|
I really hope this gets merged. I have a workspace with a ton of separate terraform repos in various different paths on my local machine, and I have to do the "shuffle the directory to the top" dance to get it to work properly. |
|
Hi folks, Thank you for understanding and patience. |
|
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. |
Workaround:
For anyone who comes across this issue, as long as your TF is in the root of your project, you're likely seeing this issue within a child module that doesn't declare it's own providers, instead relying on inheritance from a parent module. If this is the case, a workaround that works for me is to define the
required_providersso that Terraform knows what providers to cache when youinit.example:
Original issue description:
When trying to enable the language server with the new
2.0.0-rc1version, I get a "Workspace not initialized" error, which is not resolved by runningterraform initThe text was updated successfully, but these errors were encountered: