How to better handle updating versions with an existing BSP entry

[ckipp01]

Hello! This isn't actually a problem unique to Mill, but since the new release of Mill I've hit on this a few times so I figured I could create the convo here to see how we could maybe address it in Mill.

A workflow I have is to get a .bsp/mill-bsp.json file created (either manually or with Metals) and use Mill as a BSP server. When doing that you'll end up with an entry that looks something like this (I added formatting for easier reading):

{
  "name": "mill-bsp",
  "argv": [
    "/Users/ckipp/.cache/mill/download/0.10.7",
    "--bsp",
    "--disable-ticker",
    "--color",
    "false",
    "--jobs",
    "1"
  ],
  "millVersion": "0.10.7",
  "bspVersion": "2.0.0",
  "languages": [
    "scala",
    "java"
  ]
}

Now lets say after this was created a new Mill update comes out (like just happened with 0.10.8) and the user updates their .mill-version but never regenerates their BSP entry. They are now in a state where things could go wrong since in reality they are using 0.10.8 in their build but really are still using 0.10.7 in their BSP entry.

I haven't dug into the code yet to verify, but this will indeed be running a 0.10.7 build server correct? Is there any danger doing this if the build definition itself is on 0.10.8? I'm curious if there is any way to avoid this mismatch or to help a user out to ensure that when they do an upgrade to a new Mill version that they aren't stuck with an old BSP entry. Any idesas?

[lefou]

I think the most wanted solution is to use the executable, the user used to create the entry. E.g. in my typical setup, I use a globally installed millw (renamed as mill) to run Mill. But this is a shell script and Mill isn't aware of it. We could add the currently used entry point via a (hidden) cmdline option, which could then be used by Mill to generate the BSP entry config. For my outlined case, this would mean, BSP client would use my millw now which is correctly reading the .mill-version before starting the BSP server.

I also have a dev-mill script, which I use when developing and testing new Mill features. As it is ignoring the .mill-version but using a locally build dev version of Mill, I could still test BSP as currently, so I don't see any issues with my suggested approach.

[lefou]

I created pull requests in Mill and millw with experimental support for my idea. Instead of a cli-option, I used Java system properties. Let me know what you think.

• Add actual Mill cli as sysprop and use it in BSP config #2080
• Set the current cli as mill.main.cli sysprop lefou/millw#41