Expose main function as a module #293

2020-04-07T10:39:46+02:00

soareschen commented

2020-04-07 10:39:46 +02:00

(Migrated from github.com)

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

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 [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/lspitzner/brittany/293)

arybczak commented

2020-05-05 20:34:48 +02:00

(Migrated from github.com)

Ping. Is there any problem with this PR?

lspitzner commented

2020-05-05 23:27:28 +02:00

(Migrated from github.com)

@soareschen @arybczak

Sorry for the slow response.

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

<rambling> 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. </rambling>

(*) 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.

@soareschen @arybczak Sorry for the slow response. No, this all looks good (*), and I have recently been thinking about the same change. \<rambling> 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. \</rambling> (*) 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

2020-05-06 00:24:25 +02:00

(Migrated from github.com)

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.

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

2020-05-06 13:39:49 +02:00

(Migrated from github.com)

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

lspitzner commented

2020-05-07 00:42:25 +02:00

(Migrated from github.com)

great, thanks!

🎉 1

Sign in to join this conversation.

No reviewers

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#293