2016-09-06 20:37:31 +0200 <the_2nd> cabal repl
2016-09-06 19:50:54 +0200 <kurt11_> In a cabal file, if I define different executables/test-suites with different dependencies, what are the cabal entries called? Are those packages? Or just cabal entries?
2016-09-06 19:50:40 +0200 <maerwald> cabal is not a tool for sharing dev environments
2016-09-06 19:48:56 +0200 <geekosaur> cabal did, once. the results were not good
2016-09-06 19:48:53 +0200 <nitrix> maerwald: In other words, Cabal created a feature that cannot be depended on reliably for homogeneity.
2016-09-06 19:48:50 +0200 <maerwald> nitrix: I can do that in my cabal sandboxes
2016-09-06 19:48:27 +0200 <nitrix> maerwald: Okay. Let me state the problem again. It's not about the flag being able to change the API or not. That, it can already do and some people are stupid enough to incorrectly misuse the feature. What bugs me out, is that stack lets you specificy a flag for the project (assuming you commit the stack file) but cabal can't.
2016-09-06 19:44:04 +0200 <maerwald> nitrix: you asked for a feature in cabal though ;)
2016-09-06 19:44:01 +0200 <nitrix> maerwald: stack supports it, cabal doesn't.
2016-09-06 19:43:20 +0200 <nitrix> maerwald: I understand the risks and complexity involved, but why is there no way out in cabal, since Cabal itself introduce this very flag feature, yet its stack that has to take the lead on the matter.
2016-09-06 19:41:57 +0200 <maerwald> otherwise we have another "cabal hell"
2016-09-06 19:23:32 +0200 <nitrix> merijn: If cabal offer flags, it needs to support dependencies that needs those flags. Not in a local file; for everyone using that project.
2016-09-06 19:20:03 +0200 <maerwald> nitrix: well, you put that configuration in your local cabal file
2016-09-06 19:18:28 +0200 <nitrix> geekosaur: I agree... but meanwhile, cabal allows projects to define flags, so it should also also flags on dependencies.
2016-09-06 19:15:52 +0200 <merijn> nitrix: Cabal (note, cabal, not cabal-install) was intentionally designed to make this hard to stop people from doing things they shouldn't
2016-09-06 19:15:51 +0200 <maerwald> nitrix: you don't fix those problems by using methods of a tool that can be optionally used on top of cabal. There are only two options: 1. make cabal understand package configuration (that's the devils path, ask gentoo devs) 2. don't change API based on flags
2016-09-06 19:14:06 +0200 <hvr> nitrix: i.e. you impose additional constraints on your install-plan; but that's outside of .cabal
2016-09-06 19:13:18 +0200 <nitrix> If stack has it, why cabal is doing such a poor job?
2016-09-06 19:12:59 +0200 <merijn> hvr: Cabal can't handle it either, afaik?
2016-09-06 19:12:46 +0200 <hvr> nitrix: fair, but you can't declare a dependency on a flag setting inside a .cabal file
2016-09-06 19:12:35 +0200 <nitrix> stack doesn't uses cabal, it uses Cabal.
2016-09-06 19:12:13 +0200 <nitrix> hvr: I refered to cabal as the executable, which is cabal-install, not Cabal the library.
2016-09-06 19:12:10 +0200 <hvr> nitrix: and the kind of flag settings you can set in stack.yaml, you can set via cabal.project for cabal
2016-09-06 19:11:37 +0200 <hvr> nitrix: stack can't either, since it uses cabal
2016-09-06 19:11:24 +0200 <nitrix> I'll just use stack and make it clear I wont support cabal anymore.
2016-09-06 19:11:11 +0200 <nitrix> Should or shouldn't, there are still many packages that have those flags and cabal is unequipped to make this easy.
2016-09-06 19:09:26 +0200 <maerwald> it's a bug. Cabal doesn't know about flags, so you can't properly depend on them (ofc you can configure cabal to do that, but that's not part of the dependency resolution... the build will just fail)
2016-09-06 19:07:46 +0200 <nitrix> Some hackage packages actually have flags (that sometimes modify their API). How do I go about putting those in my cabal file so those are already preselected to ease others work on the project out of the box?
2016-09-06 15:56:31 +0200 <byorgey> mrm: are you in a cabal sandbox?
2016-09-06 15:56:03 +0200 <mrm> I've installed a package through cabal install, but it's not working with import. Is there some extra step?
2016-09-06 13:15:33 +0200hackagebotstackage-upload 0.1.0.6 - A more secure version of cabal upload which uses HTTPS https://hackage.haskell.org/package/stackage-upload-0.1.0.6 (lehins)
2016-09-06 01:02:19 +0200 <kurt11> I have a stack+cabal project with a single unit test. haskell-mode in emacs doesn't seem to recognize that my test source file is part of the test-suite and doesn't recognize the `import Test.HUnit`. How do I fix?
2016-09-06 00:25:32 +0200 <eAio> I installed ghc-heap-view using Cabal and now I need to "load the included ghci script". How do I do that?
2016-09-05 14:26:09 +0200 <zoran119_> my cabal project has src/Main.hs and i have added src/api/Core.hs but cabal keeps saying that 'Failed to load interface for Api.Core'. do i need to add the new file to cabal config somehow?
2016-09-05 14:20:03 +0200 <saurabhnanda> aaaand yet another boilerplate. what's with enumerating every single module in cabal files?