Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Chris Kipp
    @ckipp:matrix.org
    [m]
    an alternative would be to start sbt --client first in the workspace, then open the project in Metals if you've chose sbt as a BSP server
    then it'd just connect to the already running server
    Markus Appel
    @markusa380
    @ckipp:matrix.org of course Metals needs SBT to function as BSP, but it would be a bit more ergonomic to "wait" for an SBT instance instead of starting one unasked. It is after all a tool that integrates with SBT less than SBT being a tool integrating with Metals.
    To rephrase, I need to use SBT and Metals, and Metals depends on SBT, so Metals should not start SBT, because I also need SBT. So I should start SBT and Metals should pick that up, as it already does when starting SBT itself and waiting for it to boot up
    It should at least be a flag one can set in the preferences that make Metals wait for a server instead of starting one.
    Or, what would also work, and might solve more than just this issue, is if the command to start SBT is configurable.
    Chris Kipp
    @ckipp:matrix.org
    [m]
    well both Metals and sbt are implementing BSP here, and according to BSP discover, if a .bsp/<server>.json file exists, that's an indication that it should be started. So in this situation when you've chosen to use sbt as a build server at some point in time and open the project, metals remembers that, follows BSP discovery rules and starts the server since it needs that in order to function
    Markus Appel
    @markusa380

    There's this setting already:

    Sbt Script
    Optional absolute path to an sbt executable to use for running sbt bloopInstall.
    By default, Metals uses java -jar sbt-launch.jar with an embedded launcher while respecting .jvmopts and .sbtopts.
    Update this setting if your sbt script requires more customizations like using environment variables.

    But this is not honored.

    4 replies
    Chris Kipp
    @ckipp:matrix.org
    [m]

    It should at least be a flag one can set in the preferences that make Metals wait for a server instead of starting one.

    But metals would sort of be unusable until that happened

    Markus Appel
    @markusa380
    We unfortunately have the special case here that SBT cannot run twice on the same project without severe problems
    Yes of course it wouldn't be usable until that
    Chris Kipp
    @ckipp:matrix.org
    [m]
    but when sbt server is running for a workspace, it only runs once right? So does starting sbt server first and then vs code work in this scenario?
    because even then, only one sbt instance would be running
    Markus Appel
    @markusa380
    But currently it's making my life harder because I need to hard kill the implicitly started SBT instance to start my explicit SBT instance so I can run SBT commands and force clean/recompile on demand

    So does starting sbt server first and then vs code work in this scenario?

    Yes, it would, but I want to of course use the integrated terminal to avoid alt-tabbing between the windows. Most people prefer that I think.

    Chris Kipp
    @ckipp:matrix.org
    [m]
    well the way that it's launched is actually defined in your .bsp/sbt.json file
    Markus Appel
    @markusa380
    Would it be up to BSP spec to start an instance of SBT explicitly in the integrated terminal? That would make sense in more than one way.
    Chris Kipp
    @ckipp:matrix.org
    [m]
    when looking in there, I'm assuming you don't see the env variables you're looking for?
    if that's the case please do submit an issue with a reproduction
    Markus Appel
    @markusa380
    I don't even know what this JSON file contains as info, can I just "hack" it to not start SBT somehow?
    Again, I'm completely okay with not having functionality until SBT is started. I just want to be able to use SBT at the same time as using Metals.
    Chris Kipp
    @ckipp:matrix.org
    [m]
    I'm still not sure I understand why you can't. Even after metals starts sbt, you should still be able to open your terminal, connect to the running server and issue commands
    Markus Appel
    @markusa380
    With SBT being more important as it tells me when it's done with compilation, while Metals leaves me to guess depending on how many seconds ago the list of errors has changed.
    Because SBTN is a buggy mess.
    Chris Kipp
    @ckipp:matrix.org
    [m]
    also, are you issueing compile command via sbt in this scenario?
    Markus Appel
    @markusa380
    It randomly disconnects, and selecting recent commands with [Arrow Up] or pressing tab for autocomplete bugs out if SBT is busy
    Sometimes
    Chris Kipp
    @ckipp:matrix.org
    [m]
    I mean if sbt is your build server then compiling manually via sbt is redundant as a save in VS Code will also trigger the same compile
    Markus Appel
    @markusa380
    Metals leaves me to guess [when compile is done] depending on how many seconds ago the list of errors has changed.
    Especially on compile heavy projects this can get quite upsetting :(
    But apart from this I want to be able to run clean and test when I want
    Vadim Chelyshov
    @dos65
    @/all new release 0.10.4 with Scala 2.12.14 support is published
    Chris Kipp
    @ckipp:matrix.org
    [m]

    Because SBTN is a buggy mess.

    there has been a ton of work on the sbt side on sbtn, so please refrain from shitting on it here

    as for the clean and test, there are also ways to directly do these in VS Code, so that may not be ideal for you
    Markus Appel
    @markusa380
    I am not, it's a gods gift, but it's not yet stable enough for my day to day work
    Chris Kipp
    @ckipp:matrix.org
    [m]
    all that to say, trying to think through a workflow for you, one thing maybe to try, although it'd take an extra step would be to open VS COde, which would start sbt, especially since you chose to use it in the past
    after that, you could issue the Build Disconnect command which would shut your build server down
    then open your terminal and start it again that way
    Markus Appel
    @markusa380
    That's pretty similar to what I do already
    Chris Kipp
    @ckipp:matrix.org
    [m]
    but in theory that should be exactly the same as just attaching to the running server already
    Markus Appel
    @markusa380
    Whenever I open VSCode I run the following commands:
    sbt --client shutdown
    sbt
    Takes half a minute because of course the first instance is busy for a minute compiling before I can shut it down
    Look, Metals can't abstract SBT away, there's too much custom functionality. Every developer has some SBT console open while working in the IDE to run special commands. I mean the list of SBT commands is very long.
    Chris Kipp
    @ckipp:matrix.org
    [m]

    It randomly disconnects, and selecting recent commands with [Arrow Up] or pressing tab for autocomplete bugs out if SBT is busy

    Have these been reported to sbt?

    again to reiterate ideally in theory having Metals start sbt and then attaching to it via the embedded terminal should work fine
    Markus Appel
    @markusa380
    In a perfect world that would be the way to go
    Chris Kipp
    @ckipp:matrix.org
    [m]
    there are certain things you can't do at the same time with multiple connections to the server, that's a limitation of BSP support in sbt I believe, but still connecting to it shouldn't be an issue. I'd recommend reporting issues that sbt is having in that scenario there
    Markus Appel
    @markusa380
    Sure, okay
    Chris Kipp
    @ckipp:matrix.org
    [m]
    you could possibly disable Metals for a workspace as well
    then yo ucould open the project without metals triggering anything