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
    Is this something that could be solved with BSP?
    Ólafur Páll Geirsson
    @olafurpg
    Can you elaborate on why that doesn't work well for language agnostic build tools like bazel?
    Á bsp workspace can have multiple "build targets" of different languages. A single build target can also have sources in different languages.
    If you search for "languageId" in the spec
    Ólafur Páll Geirsson
    @olafurpg
    You can see which methods support multiple language.
    (BTW Sourcegraph looks like a great product from my limited experience with it ☺️)
    Felix Becker
    @felixfbecker
    Our “build servers” are just wrappers around language servers - so we have one for each language, and Sourcegraph only ever talks to the “build server”. That means every “build server” handles e.g. certain package managers that are common for that language, e.g. the Java “build server” supports Maven and Gradle, the JavaScript/TypeScript “build server" supports npm and yarn.
    If we wanted to support Bazel for all languages though, that would mean we would have to implement it in every “build server” for each language, duplicating implementations.
    BSP sounds like it solves this - Sourcegraph would talk to the language server directly, but the language server under the hood delegates build tasks to the build server. So language servers just need to implement BSP and can all share a common Bazel build server.
    Is that accurate?
    Ólafur Páll Geirsson
    @olafurpg
    That is accurate. Our primary use-case for bsp was to enable a language server to communicate with different build tools through the same protocol. The barrier for creating a scala language server in scala is quite high since the community is spread through multiple different build tools (sbt, maven, pants, bazel and new ones like mill). It's a similiar situation as with LSP but replace "editor" with "build tool".
    the success of the protocol will depend on adoption from both sides: build tools and language servers. The announcement yesterday was exciting since the IntelliJ Scala plugin added bsp support in its nightly release, I hope this will be incentive for people working on build tools like bazel join the efforts to reap the benfits of a smooth "Import project" step in IntelliJ
    Felix Becker
    @felixfbecker
    Awesome. If that is true, I would love to see how we can move our "build server" wrappers over to BSP.
    So for our use case, we mostly care about telling an appropriate build server to "initialize" the workspace, which basically means installing dependencies.
    Looking through the BSP spec, I don't see any method like "install dependencies" or "initialize workspace", only compile, run etc.
    Is there something in BSP that would fit our use case?
    Ólafur Páll Geirsson
    @olafurpg
    @felixfbecker "install dependencies" for Scala would be this request here https://github.com/scalacenter/bsp/blob/master/docs/bsp.md#scalac-options-request
    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.