[Haskell-cafe] technical thoughts on stack

[Duncan Coutts]

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