Allow Go tools to be installed in a separate GOPATH #351
Conversation
|
hmm right after I created the pull request, I went back to the issue thread and realized that I should have probably used the bin lookup instead of appending the tools path to the GOPATH. |
samherrmann
force-pushed
the
tools-gopath
branch
3 times, most recently
from
c6b39ab
to
158949d
Compare
|
This is great - I'm actually pleasantly surprised that it's this simple to add support for a separate Go tools installation path. I think eventually it would be good to expand upon this and choose a default location for the tools and automatically download them for the user on startup, as well as tracking/managing versions, to avoid all of the current manual acquisition steps. But this feels like a reasonable step toward that which enables users to easily setup their own global installation path, and allows us to go further in the future, but also to offer configurability of the installation location in the future even if the default changes. On the env var name - I'm happy with /cc @ironcladlou in case he has any thoughts on this. |
ramya-rao-a
force-pushed
the
master
branch
2 times, most recently
from
0b2155b
to
7aa5605
Compare
|
@samherrmann There has been quite a few changes to |
|
Yup, I will try to do this tonight. |
samherrmann
force-pushed
the
tools-gopath
branch
from
158949d
to
f3a3c9c
Compare
samherrmann
force-pushed
the
tools-gopath
branch
from
f3a3c9c
to
6f51759
Compare
|
Thanks @samherrmann ! |
|
@samherrmann @ramya-rao-a Is there a reason why this is implemented as an environment variable and not a configuration key in user's vscode profile? The way I see it, people run vscode as I think a config key would be a "less ephemeral" solution and would preserve between launches. For instance, I manually install all go tools to my |
|
Totally agree. Great idea.
… On Jan 13, 2017, at 2:38 AM, Ahmet Alp Balkan ***@***.***> wrote:
@samherrmann @ramya-rao-a Is there a reason why this is implemented as an environment variable and not a configuration key in user's vscode profile? The way I see it, people run vscode as code . and you can't expect them to have this ENV key set at all times. (I certainly do not wish to be in that business.)
I think a config key would be a "less ephemeral" solution and would preserve between launches. For instance, I manually install all go tools to my ~/gotools folder, I wish I could just set it to a vscode preference key and forget about it forever and vscode would handle things for me (such as perhaps periodically updating these tools).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes I think I agree as well. I think I used an env var because it seemed to make sense when looking at the existing code, but from a user's point of view a config key makes probably more sense. Here is my first attempt at implementing the change: Please provide feedback if anything already jumps out at you. |
|
One catch with setting this as a user/workspace setting is that the debug adapter will not be able to read it, and so this will work for all tools except |
…ild-i * 'master' of github.com:Microsoft/vscode-go: Moved debugging doc to a separate wiki Make a copy of process.env when setting VSCODE_GOTOOLS Debugger cannot read settings Improve error handling of test coverage (microsoft#721) Use proper plurality in output (microsoft#720) Fixes microsoft#303 Dont run test if current file is not test file Added a note on how to debug single tests Allow Go tools to be installed in a separate GOPATH (microsoft#351) Fix typo in README.md (microsoft#715) Honor the 'cwd' launch configuration argument (microsoft#714)
This is a prototype for issue #5.
The approach used in this prototype allows users to install the Go tools in a separate GOPATH by setting a VSCODE_GOTOOLS env variable to the directory of where they want to install the tools.