lspitzner / brittany

haskell source code formatter
GNU Affero General Public License v3.0
690 stars 72 forks source link

Expose main function as a module #293

Closed soareschen closed 4 years ago

soareschen commented 4 years ago

Motivation: We would like to include Brittany as a dependency to our Haskell project, and then call Brittany through cabal run instead of having a global installation of brittany. The problem is that Cabal does not expose the brittany executable during runtime.

By exposing the main function of brittany as a module, we can create an executable like my-brittany in our Cabal project, and then call cabal run my-brittany instead of brittany.


This change is Reviewable

arybczak commented 4 years ago

Ping. Is there any problem with this PR?

lspitzner commented 4 years ago

@soareschen @arybczak

Sorry for the slow response.

No, this all looks good (*), and I have recently been thinking about the same change.

\ I have a slightly different reason: Executables end up being flat anyway (all core code needs to be tested and be in a library) and some tooling is easier if important stuff is in the same components (library and executable components are often closely related). And with internal libraries I would argue that making executables have no code cleans up package concepts. \

(*) there is one problem: The cabal-version: 2.2 change breaks my CI which still uses older cabal versions. I don't mind at all dropping support for older cabal versions. The only problem is that I have been really annoyed with some haskell CI setup problems (not specific to brittany and certainly not to this PR) in the past few weeks.

I will push some attempt to upgrade the CI versions to fix this in a few minutes. Might take a few iterations to get it working though, so I probably won't get this ready today.

lspitzner commented 4 years ago

Hmm if I read the logs correctly, the CI stack version does not like the cabal-package version either. Have no idea how to upgrade that, apart from manually installing a new stack version in the image, which would be annoying.

I have instead downgraded package cabal-version to 2.0 which so far looks promising, see https://travis-ci.org/github/lspitzner/brittany/builds/683590901 nevermind it breaks, and I notice that cabal check also has multiple issues with this anyway.

I will think on this, but I might go with the pragmatic choice of reverting the cabal-version/license-field change, and merging the rest.

soareschen commented 4 years ago

@lspitzner I have reverted changes to the cabal version. Hope that helps.

lspitzner commented 4 years ago

great, thanks!