Metals fails to download in VSCode behind a HTTP proxy

[ghost]

Describe the bug
I get a connection refused error in VSCode when the metals extension (v 1.2.0) activates the first time.

I'm behind a corporate HTTP proxy, but it's properly configured in the http.proxy setting of VSCode. I also tried to set the http.proxySupport to on, but no avail.

To Reproduce
Steps to reproduce the behavior:

1. Get behind a HTTP proxy.
2. Install the metals extension and reload the window.
3. Open a folder with a build.sbt.

Expected behavior
metals installs properly.

Screenshots

Installation:

• Operating system: Linux
• Editor: Visual Studio Code
• Metals version: v0.4.0

Search terms
HTTP Proxy

[olafurpg]

Thanks for reporting! Can you try updating -Dhttps.proxyHost=… -Dhttps.proxyPort=… in the "Server Properties" setting for Metals in VS Code? Alternatively, those properties are picked up automatically from .jvmopts if they are defined there.

[ghost]

@olafurpg Thanks for your fast response, this worked 🎉 👍

That said, I think this could be improved. I've set my HTTP proxy in two other places already:

• JAVA_OPTS in /etc/environment (sbt picks this one up)
• http.proxy in VSCode's settings.json (code extensions pick this one up)

I'd argue that this extension should pick up at least one of these. How about changing fetchAndLaunchMetals to either

• explicitly set -Dhttps.proxyHost, etc. according to the http.proxy setting, or
• splice JAVA_OPTS into the coursier invocation?

Picking up JAVA_OPTS for this invocation seems like a good idea beyond this ticket, since this variable is often used to set general Java flags.

What do you think? I'd do a pull request for this if you like.

[gabro]

I didn't know about http.proxy in VSCode settings, and I think respecting it would be intuitive behavior. Wdyt @olafurpg?

[olafurpg]

@swiesner-dlr I agree this can be improved, I like your suggestions 👍

[ghost]

@gabro I just read the VSCode documentation again and it looks like http.proxy is considered “legacy”, though it's not exactly clear what the replacement is supposed to be.

Perhaps JAVA_OPTS is the better way forward?

@olafurpg Thanks. Would you like a pull request? If so, which option would you like to see implemented?

[olafurpg]

In that case I like respecting JAVA_OPTS. We should include the options both when launching metals and also when running coursier fetch. A good place to fix this would be somewhere around here

metals-vscode/src/extension.ts

Line 84 in c2e3196

const serverProperties: string[] = workspace

[gabro]

@swiesner-dlr thanks for looking into it. I think it would also be interesting to try setting http.proxySupport to override. Would you mind trying that? https://code.visualstudio.com/updates/v1_30#_network-proxy-support-for-extensions

[ghost]

@gabro I saw that option, and I searched VSCode's code for what it does, and from what I saw it only affects HTTP calls from Javascript directly, by injecting proxy settings into the underlying network handler of Electron. I doesn't look like it automatically propagates to subprocesses or offers a dedicated way to get hold of current proxy settings.

[olafurpg]

BTW, note that environment variables don't always propagate when starting VS Code as a GUI applications. It's best to start it with the code binary from the terminal to expose JAVA_OPTS.

[ghost]

Thanks for the reminder! I know that GUI and env variables are a mess on macOS, but this issue affects me only on Linux (I don't have a mac at work), so I'm fine 😊