Use a standard configuration format that other tools can reuse about bloop HOT 4 CLOSED

2 more cents, no more novelty. The Clang community has settled on a format and quite a lot of tooling has sprung up around it. I would love if we could do the same in the scala community. It may make sense to re-use the same keys they use for our shared bits of information and then just enrich the file with additional information we need to help us interoperate with existing tooling.

https://sarcasm.github.io/notes/dev/compilation-database.html

My other thought, I would like for this file to contain enough information to be able to determine if artifacts built with these settings are still valid or if they need to be rebuilt. I don't know all of the variables besides the scala source code, maybe it is just classpath, compiler flags, and scalac version?

from bloop.

I know I brought this up in another ticket, but I'll reiterate here, as it's more relevant.

If the file format needs to be read by other tools, JSON is too heavyweight a dependency to require, as it becomes largely inaccessible to shell scripting (which is a particular use-case for Bloop). JSON can be read with jq, but it's not standard.

The existing key/value format works very well for shell scripting, as grep, cut and tr provide most of the functionality required for manipulating keys, even if they're rather blunt tools for the task.

To throw another idea into the pot, but one I'm by no means wedded to, the git file format seems like a reasonably good compromise between human-readability, developer familiarity, and computer-readability. Any git config file can be read with git config --file <file> --get <key>, and it's more reasonable to expect git to be available than jq.

I have no idea about HOCON, but anything which requires complex parsing immediately makes the format less useful. Even changing from a single = delimeter to a space-padded = makes the parsing harder, for example. Needing to remove quotes, or do escaping just introduces opportunities for errors and fragility, as programmers build tools which work adequately for their own common use-cases, and break for some other users with slightly different needs.

In summary, please don't introduce complexity you don't need!

from bloop.

HOCON desugars to JSON so any JSON is valid HOCON, and a HOCON parser can read HOCON and emit JSON. Not sure if that helps related to the above points, just trying to fill in some of the blanks regarding HOCON, not an argument for or against.

from bloop.

My 2c, nothing novel just some thoughts

• if you go with JSON, I recommend defining a JSON schema http://json-schema.org/ (for example. Buckescript build system does that https://bucklescript.github.io/bucklescript/Manual.html#_bucklescript_build_system_code_bsb_code. JSON schema has great IDE support in out of the box in IntelliJ + vscode without any plugins.
• if you define your own schema, I suspect it will be a challenge to come up with a widely accepted model for defining projects/targets/modules and their attributes.
• I would consider looking into adding build related extensions to LSP, similar to what they're doing in sbt. I think this could be hugely valuable for IDE integration, esp. when once bloop supports running tests

from bloop.