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

Expose main function as a module #293

Merged
merged 2 commits into from
May 6, 2020
Merged

Conversation

soareschen
Copy link
Contributor

@soareschen soareschen commented Apr 7, 2020

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
Copy link

arybczak commented May 5, 2020

Ping. Is there any problem with this PR?

@lspitzner
Copy link
Owner

@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
Copy link
Owner

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
Copy link
Contributor Author

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

@lspitzner lspitzner merged commit 55f84c3 into lspitzner:master May 6, 2020
@lspitzner
Copy link
Owner

great, thanks!

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 this pull request may close these issues.

3 participants