Closed teddy-codes closed 5 years ago
Requested review from Ammar since he's the one who turned it off to begin with.
Makes sense. I am unsure of any tooling that has a problem with go modules.
What is the plan when modules are landed in 1.13?
Hopefully vscode-go works more reliably before then.
On Wed, 26 Jun. 2019, 5:07 am Robert M, notifications@github.com wrote:
What is the plan when modules are landed in 1.13?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cdr/sail/pull/228?email_source=notifications&email_token=ACVYSVHVTTQIXJYGUZKH5SLP4JUGRA5CNFSM4H2WXEXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRI3YQ#issuecomment-505581026, or mute the thread https://github.com/notifications/unsubscribe-auth/ACVYSVDCMRS7AMY2EOGWB2DP4JUGRANCNFSM4H2WXEXA .
vscode-go works fine with gopls
Edit: Here is the config:
"go.alternateTools": { "go-langserver": "gopls" }
I'm OK with merging this the way it is. Please confirm that all Go tooling works well in this container. They may have fixed the bugs.
We shouldn't use gopls yet because it isn't standard yet and might confuse the typical Go dev.
Seems to be working:
Only thing that I had to do was ctrl+shift+p
to bring up cmd pallet and install of the go binaries that are required for vscode-go. Thoughts?
We should install whatever that binary was in the image.
I should make a different PR for that
Enabled go modules and added directory perms.
We might want to add directory perms to the base ubuntu-dev-go image, but I am unsure as of now.
Edit: Resolves #192 Resolves #193