2016-07-07 22:28:08 +0200 <khumba> Why would calling "cabal install --extra-lib-dirs=..." for a library work but injecting (emptyBuildInfo {extraLibDirs = ["..."]}) via HookedBuildInfo in preConf, preBuild, preTest, preCopy, preInst hooks not?
2016-07-07 18:46:01 +0200 <iphy> is it possible to pass double-dash flags to ld-options in cabal?
2016-07-07 17:41:40 +0200 <Philonous> I'm getting a package version conflict between zip-archive and Cabal with stack init --solver even though both packages are in lts 6.6, what am I doing wrong?
2016-07-07 14:36:15 +0200 <balor> Hmm...stack is telling me `Did not find .cabal file for wreq-0.4.1.0 with Git SHA of 76d8ca4c0629b0e0bec9e23d699f16799f4bc1d2` and similar. What do I have to nuke for stack to rebuild these indexes?
2016-07-07 13:05:43 +0200 <luite> dibblego: that's more heavyweight though, or do you have a neat way to get everythign in a single file, and runnable with a single command? (does "cabal run" require configure first?)
2016-07-07 13:03:05 +0200 <dibblego> I just use executable in the .cabal file
2016-07-07 09:08:49 +0200 <dysfun> and fwiw, i used cabal sandboxes until stack got usable
2016-07-07 09:08:12 +0200 <dysfun> milesrout: well, stack uses cabal
2016-07-07 09:07:51 +0200 <milesrout> ertes: given that I have typed exactly one command starting with ‘cabal sandbox’ into my terminal *ever*, getting started with a more modern build system seems like a good idea
2016-07-07 09:06:20 +0200 <ertes> dysfun: that may be true, but if cabal sandboxes are already working for someone, why would the answer to, "how do i list installed packages", be "must… use… stack!!111"?
2016-07-07 09:03:27 +0200 <ertes> dysfun: i don't think cabal hell is something everybody encounters… sandboxes should work for most people, and deployment is not a concern for many people
2016-07-07 09:02:57 +0200 <dysfun> yes, but on the other hand, do you really want to guide someone through cabal hell?
2016-07-07 09:01:41 +0200 <adarqui> my life has gotten easier since using stack.. cabal before sandboxes was real brutal.. that's when i was just starting to learn haskell ;f
2016-07-07 08:59:47 +0200 <Koterpillar> milesrout: stack is www.haskellstack.org, and is better than cabal sandbox for most tasks
2016-07-07 08:59:13 +0200 <ertes> milesrout: cabal list --installed
2016-07-07 08:59:09 +0200 <Koterpillar> milesrout: cabal exec ghc-pkg --list
2016-07-07 08:58:38 +0200 <Koterpillar> milesrout: cabal sandbox exec (or run?) ghc-pkg --list
2016-07-07 08:58:37 +0200 <milesrout> I typed cabal install transformers-free and then realised I actually want free instead
2016-07-07 08:58:13 +0200 <milesrout> what is stack? i’m using cabal
2016-07-07 08:57:47 +0200 <milesrout> cabal sandbox[tab] gives no good suggestions
2016-07-07 08:57:27 +0200 <milesrout> i might be retarded but how do I list all the packages installed in a cabal sandbox?
2016-07-07 08:43:30 +0200 <mjrosenb> so, I assume that I can specify scripts to install alongside my program in a .cabal file; is there a way to specify some amount of shell environment as well?
2016-07-07 04:40:41 +0200 <mniip> type Stack = 'Cabal
2016-07-07 04:40:08 +0200 <glguy> stack works at a lightly higher "level" than normal cabal, so it probably makes sense that this is missing. cabal commands are run in the context of some local package, stack commands are run in a whole environment, there isn't a main package
2016-07-07 04:39:07 +0200 <glguy> pumita: No, but people have made such things. There's stack exec but it needs an executable argument and doesn't rebuild like cabal run
2016-07-07 04:37:11 +0200 <pumita> is there a synonym for `cabal run` but for stack?
2016-07-07 03:42:09 +0200 <glguy> pumita: then it allows cabal to resolve a set of packages that satisfies the version constraints
2016-07-07 03:31:42 +0200 <pumita> it's in the .cabal file of the project I'm trying to build
2016-07-07 00:18:39 +0200 <kadoban> pumita_: If you just do 'stack init' inside the project you're using, I'm assuming there's a .cabal file there, and then 'stack setup' it should be all great.
2016-07-07 00:12:07 +0200 <ertes> mgsloan: a nix-based environment is not bound to any directory, file or cabal project… one option is to define a bunch of those in your user configuration and then just the appropriate one for each non-cabalised haskell project… not entirely sure, but i think that's what mmachenry is asking for
2016-07-07 00:06:16 +0200 <kadoban> mmachenry: So you have SomeScript.hs you just want to run, and it uses some package as a dependency, that has a .cabal file, that's only available on your local hard drive, correct?
2016-07-07 00:05:37 +0200 <mmachenry> glguy: I don't want the dependent to be a package. But the dependency is a package with a cabal file.
2016-07-07 00:05:04 +0200 <glguy> mmachenry: If you don't have a .cabal file it's not a package
2016-07-07 00:03:28 +0200 <mmachenry> glguy: My one-off package does not have a .cabal file. Not yet anyway. I was hoping to avoid that.
2016-07-07 00:02:55 +0200 <glguy> your one-off package still has a .cabal file so you can install it with cabal-install still