-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to run Fourmolu via the CLI interface of a separate binary, rather than the bundled library #2763
Conversation
…ary, rather than the bundled library This makes it easier to set up an environment (e.g. a Nix shell) which uses the same version of Fourmolu in HLS as from the command line. It can also be useful when Fourmolu has updated and we don't want to wait a month for an HLS release, or re-compile.
I wonder whether we really want this as a generic option. An alternative would be to just provide an additional formatting provider, say, e.g. what happens if you are trying out formatters and you do:
I think my suggestion would also solve that: there would simply be some tests for a different formatting provider.
Maybe it doesn't matter that much in this case, but I imagine this sort of thing matters more for e.g. passing the right GHC extensions to tools that need to know that. That's one advantage of my other proposal to do
Not all clients are VSCode. Putting it on the PATH is not onerous, but if having an option to give the path is cheap, I think it's nice. Again, no problem since I'm suggesting not having a single option ;) |
Thanks @michaelpj. Agreed on all points. I'll implement it as a separate plugin.
It's fine. GHC options etc. come via I may have to think about factoring out |
Actually, I think we'd get most of the benefits, along with easier maintenance, by just making it a plugin-specific option. I'd completely missed that we now have #691. |
It's not immediately obvious to me how to achieve this, and I'm keen to get this PR in to the impending release if possible. So I'll save it for future work. |
Right. I think I'm using |
Ensures expected config files are found.
I also can't find a nice way to set this new plugin-specific option in the tests. I could refactor EDIT: Actually it is pretty straightforward. It's just kind of ugly, and doesn't scale nicely to adding more plugin-specific options. |
Somehow 3d9f964 has broken the functionality completely. Odd. |
Yes, I think you're right. The only issue would be that you might end up with illegal combinations of plugin options? e.g. if you have some other
I think the VSCode extension also needs to be extended so it knows about the new setting, while the config is "generic" on the HLS side, I don't think is on the VSCode side. I don't really know how it works, though. I'd probably just test it in a grimy way by setting it to true by default 😆 |
Isn't it just a matter of adding another plugin-specific option? "Path to fourmolu binary (only used if |
Yes, I'm sure you're right. I started writing that before I'd implemented the first option.
I don't anticipate that being an issue any time soon.
Yeah, don't worry, I've already done that, and it works nicely. Well, it did before the CWD change, which I haven't been able to investigate yet. I should be able to get this finished up later today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks fine.
<> map ("-o" <>) fileOpts | ||
){cwd = Just $ takeDirectory fp'} | ||
contents | ||
T.hPutStrLn stderr err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should get logged properly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's no worse than with the non-CLI version. I'll open a new issue to track better logging for both.
@@ -152,11 +154,14 @@ goldenWithHaskellDocFormatter plugin formatter title testDataDir path desc ext a | |||
runSessionWithServer :: PluginDescriptor IdeState -> FilePath -> Session a -> IO a | |||
runSessionWithServer plugin = runSessionWithServer' [plugin] def def fullCaps | |||
|
|||
runSessionWithServerFormatter :: PluginDescriptor IdeState -> String -> FilePath -> Session a -> IO a | |||
runSessionWithServerFormatter plugin formatter = | |||
runSessionWithServerFormatter :: PluginDescriptor IdeState -> String -> PluginConfig -> FilePath -> Session a -> IO a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe document this function while you're here
(printerOpts <> lspPrinterOpts) | ||
defaultPrinterOpts | ||
} | ||
properties :: Properties '[ 'PropertyKey "cli" 'TBoolean] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bikeshedding: "external"? "shell"? I think "cli" seems fine though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, surpisingly no word I could think of here seems perfect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've decided I do prefer "external": 558a3bc. Not going to bother changing the variable names though.
Co-authored-by: Michael Peyton Jones <[email protected]>
As for:
Is there anything I need to do? I see from #1576 that we have some auto-generation script. Is this part of the release process? Is any of this (i.e. the process of adding an option) documented anywhere? |
I have no idea. I suspect it isn't documented: I had a look at the CONTRIBUTING for |
This looks like this PR adds support for using a locally installed binary of fourmolu instead of the version bundled with hls. I'm using hls 1.7.0.0, and installed fourmolu 0.6.0.0 on my path. I tried setting What settings do I need to set to tell HLS to use a locally installed version of fourmolu? |
I genuinely don't know. My personal use case for this disappeared shortly after it was merged. I can only suggest subscribing to #2827. |
The setting was later renamed to "external": {
"haskell.formattingProvider": "fourmolu",
"haskell.plugin.fourmolu.config.external": true
} |
Using GHC 9.4.8 HLS 2.5.0.0 with lsp-mode on emacs, the bundled fourmolu does not apply indentation from the yaml file, and using the external binary triggers the error |
Is fourmolu on your editor's path? |
Yes, ~/.cabal/bin is on my emacs exec-path variable. |
This makes it easier to set up an environment (e.g. a Nix shell) which uses the same version of Fourmolu in HLS as from the command line.
It can also be useful when Fourmolu has updated and we don't want to wait a month for an HLS release, or re-compile. Or when one wants to try out a development version of Fourmolu.
To do
This will require a non-trivial refactor to parameteriserunSessionWithServerFormatterCLI
andgoldenWithHaskellDocFormatterCLI
over aConfig
arg, so I'd like some confirmation that I'm on the right track first.Future work
We need to note that the option currently only affects FourmoluPATH
PATH
. I'm not sure this would be useful though since we already have thehaskell.serverEnvironment
option. It would also make it harder to have a single option for all formatters. EDIT: ishaskell.serverEnvironment
specific to VSCode?Minor issues
lspPrinterOpts
is unused. I doubt anyone actually cares. We can't just pass--indentation
as this would take priority over options from config files, which is not what we want (see Fix fourmolu plugin inconsistent formatting #599).