Metals: Installation problems in VSCode

[mpilquist]

I tried installing 0.3.1 in to VSCode -- disabled other Scala language servers.

Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home
logging to file /Users/mpilquist/Development/project/.metals/metals.log
Unable to automatically connect to build server.
skipping build import with status 'Failed'

Restarting the Metals server & reconnecting to the server results in the same errors as above. Note my default Java is OpenJDK 11 but I have the path to JDK 8 specified in Metals settings.

[gabro]

Can you try and see whether manually executing the "Import build" command gives the same error?

You can run it from the command palette.

[mpilquist]

Thanks, that definitely helped with getting better diagnostics.

Import project failed, no functionality will work. See the logs for more details

Log shows that my problem on this particular project is that it's launching sbt and trying to load the project's plugins, which are not available on a public resolver. To resolve that error for this particular project, I'd need the ability to customize the SBT launcher to use and perhaps customize SBT args.

I tried on an open source project (fs2) and things are working great after disabling the other language server plugins.

[olafurpg]

@mpilquist are you behind a proxy? You may need to configure system properties to make it work then. It's undocumented at the moment, I've been meaning to add a section on proxies for a while.

[mpilquist]

Not behind a proxy exactly -- rather, I have to launch sbt with these args:

sbt -sbt-dir "$SBT_ENV_HOME" -ivy "$IVY_HOME" "$@"

Where SBT_ENV_HOME/repositories contains a bunch of custom resolvers and SBT_OPTS contains -Dsbt.override.build.repos=true -Divy.home=${IVY_HOME}.

[olafurpg]

That would explain it, Metals uses an embedded sbt launcher by default since that helped out on Windows. We should support executing the user's 'sbt' command, but it's not implemented at the moment.

[gabro]

Adding configurable sbt options similarly to the Java options we already have should be easy, wdyt @olafurpg?

[olafurpg]

I opened #387 adding support for .sbtopts, .jvmopts and allowing users add custom JVM options when metals launches sbt. I'm not sure if this fixes your problem @mpilquist but it's a good first step.

If that doesn't do the trick we probably need another option to run the user's sbt command directly, but I'm hesitant to go that route since it didn't work reliably on Windows when I tried.

[mpilquist]

I think I’d need custom launcher support as I want to use the regular SBT launcher for open source projects and a special launcher for work stuff. I normally do this via a launcher launcher which checks the directory structure and passes the right args to the sbt launcher — either no args or overridden -sbt-dir and Ivy home.

On Dec 8, 2018, at 12:00 PM, Ólafur Páll Geirsson [e-mail] wrote:

I opened #387 adding support for .sbtopts, .jvmopts and allowing users add custom JVM options when metals launches sbt. I'm not sure if this fixes your problem @mpilquist but it's a good first step.

If that doesn't do the trick we probably need another option to run the user's sbt command directly, but I'm hesitant to go that route since it didn't work reliably on Windows when I tried.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[gabro]

@mpilquist from what I can tell, #387 also allows to provide a custom sbt launcher:

https://github.com/olafurpg/metals/blob/2d201096264182f20e56b3e29837739c4f6a6a7f/metals/src/main/scala/scala/meta/internal/metals/UserConfiguration.scala#L34

That should satisfy your use case, right?

[olafurpg]

@gabro That customizable launcher is a jar file, not 'sbt' script.
@mpilquist how does this setup work for a larger team, do everyone need the
same custom 'sbt' script? I thought the idiomatic solution in this
situation was to declare custom options in '.sbtopts' that's checked into
the repo. I want to support this use case but I'd like to understand it a
bit better first.
On Sat, 8 Dec 2018 at 19:16, Gabriele Petronella [e-mail]
wrote:

@mpilquist https://github.com/mpilquist from what I can tell, #387
https://github.com/scalameta/metals/pull/387 also allows to provide a
custom sbt launcher:

https://github.com/olafurpg/metals/blob/2d201096264182f20e56b3e29837739c4f6a6a7f/metals/src/main/scala/scala/meta/internal/metals/UserConfiguration.scala#L34

That should satisfy your use case, right?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/scalameta/metals/issues/383#issuecomment-445478928,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABV8XUP6SuxDSVU0-Nljjp0ql4R_nodWks5u3AILgaJpZM4ZI90s
.

[mpilquist]

@olafurpg Yeah, either everyone needs a copy of the launcher script or everyone needs to configure ~/.sbt/repositories to point to the corporate proxy. The latter works fine if you aren't doing open source work on the same machine. My launcher script is sort of a lightweight equivalent to rbenv which adjusts SBT & Ivy settings based on the project / directory.

The .sbtopts approach didn't work for me in the past, as some of the environments need global SBT config and the launcher ensures those are all configured appropriately.

[olafurpg]

@mpilquist Thanks for the context. I'll update #387 to support executing a custom sbt script to see if that does the trick.

[olafurpg]

The installation instructions for "Import build" have been updated to include the steps to customize the sbt executable.