Allow configuration to be stored in $BLOOP_CONFIG #1757
Conversation
| @@ -23,7 +23,8 @@ object Environment { | |||
|
|
|||
| def cwd: Path = Paths.get(System.getProperty("user.dir")) | |||
| def homeDirectory: Path = Paths.get(System.getProperty("user.home")) | |||
| def defaultBloopDirectory: Path = homeDirectory.resolve(".bloop") | |||
| def defaultBloopDirectory: Path = | |||
There was a problem hiding this comment.
The problem with this approach is that once Bloop server is started it's not possible to change the directory for another project. So the workflow would be quite complicated. You would need to manually stop and start server.
Or do you have a better workflow in mind?
Both javaHome and javaOptions can be set in Metals and it should suggest to restart whenever you change the parameters or open a different project, with different local settings that are not equal the ones in bloop.json file. I feel like is a bit better UX can manually tinkering with the environment variable. What do you think?
There was a problem hiding this comment.
You would need to manually stop and start server.
This is already pretty much part of my workflow and probably will be until scalameta/metals-feature-requests#129 is resolved.
My current workflow is heavily reliant on direnv and nix.
I have barely anything installed on my machine. If I work on a project, I cd $PROJECT_DIR, nix pulls in everything I need for development, eg. sbt, bloop and java for Scala projects or npm, typescript etc. for Typescript Projects. These setups are pinned to the specific versions of dependencies, eg. Java 8 for project A and java 17 for project B.
Now, as you can imagine, a single running bloop server can already cause problems in such scenarios, but metals setting javaHome in $HOME/.bloop/bloop.json is just doomed to not be correct at some point.
Setting configuration / cache dirs per environment variable is actually kind of ideal for my workflow. I agree it might not be the best UX, but it works perfectly for my kind of users.
Both javaHome and javaOptions can be set in Metals
That is a good point. Using JAVA_OPTS and BLOOP_PORT in conjunction on a per project level might actually get me pretty close to the setup I'd like to have, though it is probably less clean. I'll look into that.
There was a problem hiding this comment.
Now, as you can imagine, a single running bloop server can already cause problems in such scenarios, but metals setting javaHome in $HOME/.bloop/bloop.json is just doomed to not be correct at some point.
Metals should already actually use JAVA_HOME when starting from VS Code. And when the java home breaks (doesn't exist) it will update it to the current one. I did a bunch of redundancies to ensure that workflows, such as when using nix, still work.
That is a good point. Using JAVA_OPTS and BLOOP_PORT in conjunction on a per project level might actually get me pretty close to the setup I'd like to have, though it is probably less clean. I'll look into that.
We don't use JAVA_OPTS currently, but we do use the metals.bloopJvmOptions configuration setting, which can be set per workspace. And Metals will suggest to restart whenever these differ from the defined ones. So ideally when you have per workspace settings Metals should suggest to update .bloop/bloop.json for you. I think this is much better UX wise since you just need to click once and get everything set up. Unless there are some issues with that, in which case we might need to still do some tinkering.
But ideally this would do the same as your workflow, but almost totally automatically.
There was a problem hiding this comment.
think this is much better UX wise since you just need to click once and get everything set up.
Honestly, my ideal setup is dev-tools setup scala-project <git-clone-url> to scafold a project and the cd into it with everything set up as I like it.
I'm usually not a fan of "just need to click once for magic" solutions.
But I can see how you would prefer it for a broader audience :)
Currently bloop (or by extension metals) generates bloop configuration data in
$HOME/.bloop.This change proposes to enable the user to change the directory where bloop expects global configuration to be found.
My rational for this is that I like my dev configuration to live with the project I am currently working on, ie
$HOME/projects/foo/.config/bloop. As I work a lot in agency with different tools / tech stacks, this helps greatly in keeping project contained and reduce clutter, configuration issue, cache issues etc.I will open the respective metals PR as soon (or if at all) this is ready for merge.