Skip to content
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

"No formatter found" (Brittany) #255

Closed
georgefst opened this issue Jul 28, 2020 · 7 comments · Fixed by #258
Closed

"No formatter found" (Brittany) #255

georgefst opened this issue Jul 28, 2020 · 7 comments · Fixed by #258

Comments

@georgefst
Copy link
Contributor

On a fresh install, Brittany is set as the default formatter, but any formatting requests fail, with the log showing:

[Error - 00:34:57] Request textDocument/formatting failed.
  Message: Formatter plugin: no formatter found for:[brittany]
  Code: -32602

Perhaps the binaries were compiled without the AGPL flag?

FWIW, my vote is very much for Ormolu as the default. For one thing, on the first file I tested, it was the only one that actually worked, due to the presence of ImportQualifiedPost.

@fendor
Copy link
Collaborator

fendor commented Jul 29, 2020

Thank you for the report! I have noticed this, too. I think I messed up the cabal flags somewhere.

@lukel97
Copy link
Collaborator

lukel97 commented Jul 29, 2020

The static binaries are indeed built without the AGPL flag. However I'm not sure if we would be able to turn it on since I think this counts as distributing, which would be mean we would need to distribute the binaries under AGPL too (I'm no license expert here so feel free to correct me)
I am +1 for changing the default formatter to Ormolu/Floskell/Stylish Haskell

lukel97 added a commit to lukel97/vscode-hie-server that referenced this issue Jul 29, 2020
Since brittany isn't included in the static binaries due to licensing
restrictions
Fixes haskell#255
@alanz
Copy link
Collaborator

alanz commented Aug 3, 2020

The static binaries are indeed built without the AGPL flag.

I would argue that we should build with the AGPL flag, as the norm. Then people constrained by corporate policy can sort themselves out.

@vaclavsvejcar
Copy link

@bubba I'm still facing this problem with v1.0.1

[Error - 9:01:56 AM] Request textDocument/formatting failed.
  Message: Formatter plugin: no formatter found for:[brittany]
  Code: -32602 

is there any workaround how to actually use Brittany? If there's some issue with the bundled one, can I somehow tell HLS to use the external Brittany binary I have in ~/.local/bin?

@lukel97
Copy link
Collaborator

lukel97 commented Aug 5, 2020

@vaclavsvejcar HLS doesn't call the Brittany binary, it includes it as a library dependency. I read a bit more on the AGPL and think we're actually ok to build the binaries with it, since HLS also has the source publicly available. I'm going to make a PR to build the binaries with Brittany, but it looks like it won't be available on ghc-8.10.1 (@jneira any word on this by the way? I'm thinking of vendoring this lspitzner/brittany#305)
In the meantime you can build HLS from source with the -fagpl cabal flag to get Brittany, sorry about that

@vaclavsvejcar
Copy link

vaclavsvejcar commented Aug 5, 2020

@bubba Thanks a lot for the answer. Actually if I'm correct, in the old VSCode extension for HIE I think there was an option to provide path to external Brittany (or other formatter) binary. Would something like that be possible also for this extension, or is there any technical issue why that's not possible? For example my use case was that I used custom-built Brittany that contained some more features than the public release, and maybe it would be cool to have such option in vscode-haskell as well?

@lukel97
Copy link
Collaborator

lukel97 commented Aug 5, 2020

@vaclavsvejcar ah I see, I don't think there's currently anything inside HLS for invoking a binary to do the formatting. The plugins in HLS currently don't rely on calling external tools, but not for any technical reason as far as I'm aware, other than perhaps to make distributing binaries easier. Although for your custom built Brittany I'd imagine it would be pretty easy to build your own HLS from source with the custom Brittany vendored in! If you edit the stack*.yaml files so that the packages field contains a path to the custom Brittany and then run the install script I don't see why it shouldn't work

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants