[Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

That's good news. I think the community will benefit from a healthy
competition among the tools. It is good to have choices in terms of the
front end but I would rather prefer a unified specification of
configuration. Currently with a stack workflow one has to deal with two
config files i.e. stack.yaml and project.cabal. There is no reason why the
stack and cabal configs cannot be unified. The concept of frozen snapshots
is generic and useful enough to be incorporated as a common specification
used by all tools. If there is a unified config then the same package can
be used with stack or cabal, with hackage or stackage without any problems,
choose what you prefer.

Another point that I want to make is that I have found the cabal config
files hard to deal with. There are a number of annoying problems with it
and it lacks in reuse. That is the reason for tools like hpack (
https://github.com/sol/hpack) to be built to overcome those problems. I
think the problems that hpack solves should be natively solved by cabal. I
guess these problems are long pending and cabal did not evolve fast enough.
That could be one of the reasons for wrappers on top of cabal or competing
tools like stack getting created.

Are there any thoughts going towards a better config specification? While
we are at it it maybe good to have an extensible config which can provide
optional tool specific extensions.

-harendra

On 15 September 2016 at 06:12, Duncan Coutts via Haskell-Cafe <
haskell-cafe at haskell.org> wrote:

> 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
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-community/attachments/20160915/8ce087b0/attachment.html>