On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote:
I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray.
Since this is all being discussed now, it is perhaps worth explaining what the cabal developers are working on and the direction they're going. The cabal tool is getting a major overhaul. At this point there's a relatively large group of people who have been "dogfooding" it in their normal daily work for months (and for a few brave users since the beginning of the year). There is a tech preview of this in the 1.24 release. The latest git version has a user guide which explains things in more detail, and what you can expect to work already and what is known to be incomplete (including several temporary workarounds for missing features). https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html What is broadly the same is that it still supports the "library solver- based, work with my current ghc / environment" style that people have mentioned in this thread. For example by default it picks up the ghc on your path (and will automagically do the right thing if you change your path). That said, the intention is also to better support a "application frozen / package collection" style, which is the style that stack supports well currently. What is new is that it does what it does a whole lot better, more conveniently, more predictably. There's a lot fewer cases where you have to use multiple commands to do various steps. Much of the time you can simply ask to build/repl something, and everything else is automatic (and quick to not do much if not much changed). It's more predictable in that it's much more deterministic. The choices about what versions etc are picked depend only on your environment (e.g. ghc version), hackage snapshot and local explicit project state. In particular it does not matter what you installed previously. (To support the application/frozen workflows these aspects of the environment can all be captured and frozen in a project file.) It also avoids the "cabal hell" issues of clashing installed versions. Or to put it another way, it's a bit like sandboxing but without the mental overhead or the waiting around for everything to build (because there's automatic maximal sharing of built packages, a la nix). It *is* project based, but a minimal project can actually be implicit, and most projects don't need to specify anything more than a list (or glob) of the directories of the packages in the project. One of the things you were mentioning was how nice it is to just be able to run ghc or ghci on a source file, or even without any file, just to play around. A feature that will be landing soon in cabal- install head is the ability to simply run ghc/ghci within a cabal project directory and ghc will start up in the environment of the project. No extra wrapper scripts, shell sessions or env vars necessary. So the short term goal is to get all this to the stage where it can replace the default UI in the cabal tool, and thereafter one goal is to better support the workflow style that stack currently supports well, ie applications with frozen / carefully change-controlled environment, and package collections/snapshots chosen by 3rd parties. I should also say that any help is most welcome. Development takes place on github. We now have several active reviewers so review & feedback on contributions is very quick. It's not all just hard problems, there's plenty to do for newcommers too (e.g. write that tutorial!). There's an active #hackage IRC channel. Newcommers are always welcome. Duncan