Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Felix Becker
    @felixfbecker
    So initialize is expected to install needed dependencies, and only return after that is done?
    Ólafur Páll Geirsson
    @olafurpg
    initialize is not expected to install dependencies
    Felix Becker
    @felixfbecker
    Is there any language-agnostic method for that?
    Ólafur Páll Geirsson
    @olafurpg
    the flow for installing dependencies would be more like
    1. initialize
    2. workspace/buildTargets (might return targets in different languages)
    3. buildTarget/scalacOptions (for the targets you are interested in)
    what JSON would the result message for "install dependencies" contain @felixfbecker ?
    I guess with npm install you can infer the dependencies yourself from node_modules/, but in the JVM world the classpath is composed of jars that can appear anywhere on disk
    Felix Becker
    @felixfbecker
    The return value would not matter - all the language server cares about is that afterwards, all dependencies are installed (at least for TS/npm, Go, PHP)
    Seems like JVM languages also need some data
    Does that mean there is a coupling between a language server only supporting certain build servers and vice versa?
    Ólafur Páll Geirsson
    @olafurpg
    I see, I think we can certainly add a language-agnostic build/installDependencies with an empty result message. I can imagine it being useful even in the JVM world.
    question, should this be workspace specific or build target specific?
    It feels like it should be workspace specific. I can imagine it enabling for example bloop (currently only server implementation) to trigger sbt bloopInstall behind the scenes
    Felix Becker
    @felixfbecker
    In an ideal world, a language server would not make any assumption about which build server it is talking to, it would just send generic requests and all build servers registered would react. I.e. all language server purely implement BSP and get Bazel support for every language. Is that plausible?
    Ólafur Páll Geirsson
    @olafurpg
    I think the use-case would be more: implement BSP client once and support bazel + maven + sbt through the same API.
    Felix Becker
    @felixfbecker
    I am a bit unsure about the terminology, would a build target in the JS world be a package.json?
    Ólafur Páll Geirsson
    @olafurpg
    yes, I think it would be equivalent of package.json
    Felix Becker
    @felixfbecker
    Gotcha. What do you mean with BSP client?
    Ólafur Páll Geirsson
    @olafurpg
    we go crazy with modules in the JVM, some repos I maintain publish >80 modules :sweat_smile: and when you include the test projects that'll be >100 targets
    Actually, package.json might be 2 targets if you have a separate list of dependencies for tests
    BSP client == language server
    (I admit it's a bit confusing)
    I btw answered a question on hackernews on "difference between LSP and BSP?" https://news.ycombinator.com/item?id=17328454
    might be of interest to you
    Felix Becker
    @felixfbecker
    Yeah we need to support monorepos with lots of packages and on-the-fly installation
    Ólafur Páll Geirsson
    @olafurpg

    To elaborate on "get Bazel support for every language"

    Yes, that is plausible for everything outside of the "Extensions" section which is language-specific

    Felix Becker
    @felixfbecker
    What confuses me is that there are scala specific methods in the official protocol spec
    Ólafur Páll Geirsson
    @olafurpg
    The scala specific methods are separated in the "Extensions" section at the bottom
    Screen Shot 2018-06-16 at 22.14.28.png
    Felix Becker
    @felixfbecker
    So are other languages expected to add own extensions?
    Or is scala a special child and usually extensions will not be needed?
    Ólafur Páll Geirsson
    @olafurpg
    compilers for different language may require language-specific information
    Felix Becker
    @felixfbecker
    Gotcha.
    Thanks for all the clarifications!
    Ólafur Páll Geirsson
    @olafurpg
    I don't know, for example in JavaScript you may want to have a JavaScriptBuildTarget that says which flavor of ECMAScript, jsx, ...
    Thanks for the good questions!
    Or in PHP, you may need to know which PHP version the project is on
    Felix Becker
    @felixfbecker
    So how would a language server “pick” a build server? Is it the language server’s responsibility to spawn it?
    Because if the language server is not to make assumptions about the build server, I imagine it would need to talk to some kind of generic proxy that broadcasts to all build servers
    Ólafur Páll Geirsson
    @olafurpg
    It's currently left out of the spec the same way LSP leaves it out. We've brainstormed some ideas for automatic detection and startup
    The idea was to have a file in the workspace root that contains a shell command that either 1) does stdin/stout or 2) prints out a socket address
    Felix Becker
    @felixfbecker
    So on Sourcegraph, we have a service called lsp-proxy which takes client requests and takes care of creating connections to language servers (over TCP) and sharing the same langserver connection for multiple clients.
    Seems like for BSP, there needs to be some kind of master server
    Which could be the IDE if it supports BSP
    So the langserver talks to the master to ask for build targets, and the master calls all build servers to return an aggregated list maybe
    Requiring a config file to be committed to every repo to make it work is something we would need to avoid
    Ólafur Páll Geirsson
    @olafurpg
    Do you expect it will be common for repos to have multiple running build servers?
    Felix Becker
    @felixfbecker
    Many companies use monorepos, which contain multiple languages, meaning multiple language servers, likely meaning multiple buid servers too
    so yes
    but my primary concern is about the architecture of how to “pick” the right build server
    Ólafur Páll Geirsson
    @olafurpg

    Multible build servers shouldn't be a problem, most of the methods are easily aggregatable (lists, or single notifications).

    Requiring a config file to be committed to every repo to make it work is something we would need to avoid

    I agree