Add support for formatting capabilities to the LSP

[ebresafegaga]

This pull request adds the formatting capability to the LSP using topiary.

To use this successfully, the user has to do the following:

1. Have the topiary binary installed. See here
2. Have the topiary repo cloned locally
3. Set the environment variable TOPIARY_REPO_DIR to point to the local copy of the repo
4. And finally, an environment variable TOPIARY_LANGUAGE_DIR to point to $TOPIARY_REPO_DIR/languages

Steps 2-4 are necessary because, for now, topiary cannot be used outside its repo directory.

Alternatives

I think making a user fetch the topiary and set those environment variables, just to have the formatting capability in nls is a bit too much. I can think of the following alternatives, but I don't know if they are ideal.

Keep a cache of the topiary repo

Keep a cache of the topiary repo. Fetch the repo from GitHub if it is not available in the local cache or not up to date.

• Pros
  • Automatic updates of the repo (and hence the formatting rules for Nickel)
• Cons
  • We still have to set environment variables at runtime
  • nls has to download a potentially large repo

Embedded Nickel formatting rules as a string in the nls binary

Since topiary just needs a single nickel.scm to be able to format nickel files we could just point TOPIARY_LANGUAGE_DIR to <some-temp-directory>/language, and put the embedded file in that directory.

• Pros:
  • It's just a single file, so it will be small
  • No need to download/fetch anything
• Cons:
  • We still have to set environment variables at runtime
  • We have to ensure the formatting rules are up to date with topiary

[yannham]

The setup is indeed a bit clunky, but I imagine it's due to the setup of Topiary being clunky, right? There's not more to do for the Nickel LSP than what we already need to do to use Topiary locally, if I understand correctly? In that case, this is a reasonable first iteration step 👍

[aspiwack]

The setup is indeed a bit clunky, but I imagine it's due to the setup of Topiary being clunky, right?

If there are things that Topiary could do to help, please open an issue there 🙂 .

[ebresafegaga]

The setup is indeed a bit clunky, but I imagine it's due to the setup of Topiary being clunky, right?

Yeah, but it's not really a big issue. The problem is that topiary cannot work (automatically) outside topiary repo's directory: you'd have to set some environment variables for it to work

If there are things that Topiary could do to help, please open an issue there 🙂 .

I've told @nbacquey about this. They (the topiary team) are aware of it, but they have not yet decided how dynamic loading of languages should work, so I assume there should be an issue tracking it there.

[nbacquey]

Relevant issues in Topiary are tweag/topiary#254 and tweag/topiary#415

[yannham]

@nbacquey this is only about getting a running topiary executable, right? How would the $TOPIARY_LANGUAGE_DIR variable would be handled in this case? Would the queries be statically embedded inside such a binary?

[nbacquey]

Embedding the queries in the distributed binary would be a possibility, yes. Also, we could support manual installation of languages, as @ebresafegaga suggested. Something like

$ topiary install <language>

$ topiary list languages

[yannham]

@ebresafegaga is there anything left to do on this PR? Otherwise, I think you can merge.