Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mechanism for fixed plugin sockets, for debug setups #206

Open
PJB3005 opened this issue Aug 11, 2022 · 0 comments
Open

Mechanism for fixed plugin sockets, for debug setups #206

PJB3005 opened this issue Aug 11, 2022 · 0 comments

Comments

@PJB3005
Copy link

PJB3005 commented Aug 11, 2022

This issue is mostly in the context of terraform but it seems the best way to tackle it is at the bottom of the stack, so I'm posting it here.

Right now, Terraform requires me to manually copy paste the TF_REATTACH_PROVIDERS environment configuration every time I start my provider in a debugger. This is really inconvenient. As far as I can tell there is currently no clean way around this, since Unix sockets are always assigned a random temp file, and I'd rather not have some hacky concoction of env vars and command aliases to prefix me running terraform with something to load the provider config automatically.

It seems to me like the best solution is some sort of env var to force the plugin system to mount to a specific unix (or TCP for Windows, but btw Windows 10 has had unix sockets for almost 5 years now) socket. Then I can specify a fixed TF_REATTACH_PROVIDERS and pressing F5 in VSCode is all I need to make sure the provider is properly connected to the terraform CLI.

Some further thoughts:

  • TF_REATTACH_PROVIDERS currently includes a PID number to check if the process is still alive, and otherwise error. This is cheatable by simply specifying an always-live PID like 1, but perhaps a cleaner solution is in order if this becomes an official configuration.
  • You'll need to unlink() + recreate the Unix socket if the unix socket still exists on disk due to unclean shutdown, probably.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant