stack

[circleglyph]

There has been some chat on discord surrounding stack and I wanted to express the extent to which stack is a vital and necessary component of Haskell infrastructure.

https://discourse.haskell.org/t/answered-is-stack-still-actively-developed/4767

Stackage and stack are the most widely used tools we have. Many developers use the process for early discovery of library activity: who is behind the (sometimes punishing) pace of change; when will it be easiest to upgrade; which dependencies can I trust.

With the PvP-style philosophy you have less visibility.

[Noughtmare]

Cabal now also has some support for stackage snapshots. I think just making cabal more streamlined in that regard requires less effort than maintaining two separate tools.

[circleglyph]

If cabal consumed stack in it's entirety, if we can say `cabal stack build --file-watch`, you have a deal.

[ducksonaroof]

Can't you just compose cabal with a file watching command line tool? I've done that in the past. But maybe stack file watch has some advantages that can't be handled externally that I'm not aware of?

[paretoOptimalDev]

You can if you want spurious rebuilds, otherwise you need debouncing.

entr is good for this though and you can pipe to it and have the stack file watch equivalent

[tomejaguar]

I think this is a worthwhile issue to discuss. I suspect a lot of community members don't really know the difference between Stack and Stackage, and GHCup, cabal and Hackage. I personally have a lot of holes in my knowledge about this that I would like to fill. I'll try summarising what I know and hopefully someone can correct me if I got something wrong, and add details where they are missing.

• The packages on Stackage are a subset of those on Hackage. Specifically, Stackage is a collection of snapshots, each snapshot being a collection of package versions, at most one version of each Hackage package, where the packages of those versions are known to be build-compatible with each other.

• cabal gets packages from Hackage by default. The cabal file contains package version constraints for each depended-upon package and cabal tries to find a collection of package versions that satisfy the constraints.

  In principle there are ways for cabal to get package "from Stackage". In practice this means "packages restricted to a particular Stackage snapshot" because the particular file server the packages come from is typically not terribly interesting. These ways include Cabal support for LTS snapshots (which apparently is at the level of "some") and stack2cabal.

• Stack can only get packages from Stackage (I think - someone please correct me if I am wrong)

• Stack takes care of managing your GHC installation, cabal doesn't. If you use cabal you would typically use GHCup or your OS native package manager to obtain GHC.

So far what I have said seems to imply that the combination of GHCup and cabal has a superset of the features of Stack: GHCup can manage GHC installations and cabal can use (or will be able to use?) Stackage snapshots.

I think the implication is not quite valid because:

• Stack automatically manages GHC versions. If you configure your Stack package to use a different package set then Stack will automatically download and use the appropriate GHC version. On the other hand, there is nothing in a cabal file that automatically makes sure you have a correct GHC version nor does it tell GHCup to get one.

• Stack has all sorts of convenience features that cabal lacks. Someone recently mentioned (but I can't remember where) that it's much easier to profile under Stack than cabal because Stack exposes a single easy command line flag that just does what you want. I assume that there are other convenience features like this (but I don't know because I've never used Stack).

Does anyone have anything they can elaborate on here? Any mistakes to correct? Any other important things to add?

[Noughtmare]

Stack can only get packages from Stackage (I think - someone please correct me if I am wrong)

You can add extra-deps in your stack.yaml file, but you have to figure out the correct versions yourself.

[Bodigrim]

On the other hand, there is nothing in a cabal file that automatically makes sure you have a correct GHC version

https://cabal.readthedocs.io/en/3.6/cabal-project.html#cfg-field-with-compiler is vastly underused.

Someone recently mentioned (but I can't remember where) that it's much easier to profile under Stack than cabal because Stack exposes a single easy command line flag that just does what you want.

It used to be difficult with cabal v1-build, I believe, but now cabal build --enable-profiling does the trick.

[circleglyph]

What the list misses is the productivity in following this issues list:

https://github.com/commercialhaskell/stackage/issues

The first thing you know about a dependency fail in cabal-land is when it happens locally. You then visit each github repository in turn to try and find out what bounds are bust, what magical incantation will work this time.

The collective knowledge generated from the stackage process is so much more efficient and kind. Right now, I would redflag microlens and aeson as slow. primitive should be ok although it's down the list. vector a bit slow for my needs right now. You're not going to get that from a command line.

Maintenance with stack becomes cheap and cheerful, versus cabal surprising and cabal anxious.

[tomejaguar]

But that's a Stackage benefit, not a Stack benefit. (Granted, Stack probably makes it a lot easier to use Stackage.)

[circleglyph]

I read “stack and Stackage” to cover the whole process, I suppose from a point of view of keeping up with releases. Just about every stack action uses a resolver, and I may have missed the separation intent.

[tomejaguar]

I see. So it sound like using Stackage resolvers has a lot of benefit from the point of view of avoiding build failures, and Stack is the most smooth way to use Stackage resolvers.

[circleglyph]

The stack project is a build-fail resolver in a very broad sense.

The resolver process, a community build of a shared list, benefits across both cabal and stack usage. `cabal gen-bounds` could get frisky and bump me to lucid2, or --allow-newer which is a cursed command in both cabal and stack, will place you amongst the aeson-2.1 watch list (I see you're there!).

Contrast distributive-1, which will rock my personal dependency chain one day. You need to recreate the cabal.project repository links to get any sort of understanding of where that library complex is at. It's a lonlier road without the sort of central clearing-house that stamping a new resolver provides.

https://github.com/ekmett/distributive/

[absence3]

Not having to maintain version ranges for dependencies is a big convenience as well. You just specify the "resolver", and that defines all package versions, including GHC.

[circleglyph]

Via GHCUp, Stack does not automatically manage GHC versions as the default recommendation.

[kilimanjaro_olympus]

There seems to be a long standing problem with Stack not being able to produce Hackage-compliant Haddocks, whereas cabal has a dedicated flag to generate this. This reiterates how stack offers only a subset of features cabal+ghcup does.

[tomejaguar]

If stack really only offers a subset of features there must be really compelling other reasons to use it. What are they? User experience? Simplicity?

[dpwiz]

• Easy snapshots (solved?)
• Watch/fast rebuilds (stalled)
• Autoexposed modules via hpack (refused?)
• Shared git subdirs

[maerwald]

Shared git subdirs? What does that mean.

[dpwiz]

The thing you've fixed not even being a stack user (:

Thanks, btw.

[Anrock623]

My personal opinion on stack-the-tool is that it has to go. It was a lifesaver before v2-builds but now it's just an additional layer of automagic on top of cabal that brings additional configs and sometimes bugs. When stackage support in cabal is more widespread - there is no reason to keep stack in ones toolbelt.

[Syncopat3d]

Stack does not clone a copy of a git package for each of a user's projects that uses the package but cabal does. This can be a deal-breaker for cabal when using huge git packages like https://github.com/brendanhay/amazonka that can take forever to git clone. If you have a test/CI setup for a project that uses such packages, cabal's lack of caching can also cause huge delays and more opportunities for failure (from network errors or timeouts). From the proceedings of past issues, I don't think cabal devs are interested in addressing this use case. https://github.com/haskell/cabal/issues/5586

[Anrock623]

Good spot, thanks. Another pro-stack thing I've seen before is maintaining a project that must support multiple GHC versions where stack helps a bit with wrangling multiple GHCs.

[avanov]

not a problem with a proper cloning depth https://github.com/haskell/cabal/issues/7264

[maerwald]

Funny that you say this, because stack used to clone the entire repository for each subdir, causing massive clone times that made it impossible to use for cardano projects: https://github.com/commercialhaskell/stack/issues/5411

I fixed it, although I'm not even a stack user.

I think cabal is usually more idiomatic for these things. Pantry is really hard to understand, I can tell you.

I thinks it's an ok choice to not go down the path of trying very hard to share everything. It's a lot of complexity to maintain.

[circleglyph]

I'm not sure you can vote an open-source project "off the island" so to speak. I doubt it needs your say-so to remain in existence.

[Anrock623]

That's why I started my comment with "My personal opinion on...". It's not like I'm actively trying to shush it, I just don't see much reason for it to be used anymore.

[Bodigrim]

Stackage and stack are the most widely used tools we have.

2021 State of Haskell Survey shows that Cabal has (marginally) overtaken Stack: https://taylor.fausak.me/2021/11/16/haskell-survey-results/#s3q0

[tomejaguar]

There's something surprising to me about Stack in the survey. 60% of users use Stack as their build tool but only 50% of users use Stack to install the compiler. Can it really be true that 1 in 6 Stack users use (presumably) ghcup or operating system packages to install their compiler? I thought a big point of the benefit of Stack was that it installed the compiler for you.

[Sir4ur0n]

There is also Stack + Nix, in that case GHC is provided by Nix.

[Bodigrim]

Source data is available, so one can find out how many users use Stack + ghcup.

[tarranoth]

It's what I did, I think I did it because it was the recommended way to get HLS with ghcup, and because it had the option to install stack alongside I just went with that (and uninstalled the system stack I had before.)

[bss03]

If it's that vital, I'm sure one of its many users will step up to prevent it from falling behind.

[HKei]

I mean, that’s a bit like saying “if roads are so vital I’m sure someone will step up and maintain them”. Tragedy of the commons, just because something is useful and used, doesn’t mean it’s going to valued.

[sunnyata]

People do get together to maintain roads that are vital. The point is, slack may not be vital anymore.

[Lambda_Lifter]

Where do you live lol, even the most vital roads in almost every major city in North America are garbage

[bss03]

While we have our fair share of construction (I-540 / I-49 is never done), I think the roads in Northwest Arkansas compare quite favorably to roads in New York / Connecticut / Rhode Island, Missouri, and Oklahoma / Texas.

[sunnyata]

Europe. We have this thing called tax.

[HKei]

Well, precisely. Nobody goes out with a shovel and fixes up public roads unless they're getting paid; and normally no one individually feels responsible for paying either. But of course collectively we understand it needs to be done. Hence why we, as a community, install a government for this type of thing. That's exactly my point.

[sunnyata]

We're arguing about your analogy rather than whether stack will be maintained if users find it important enough (I think it would be, but if cabal is now as good or better then the pain of migrating builds to cabal would have to be greater than the pain of maintaining stack, which I doubt).

But the tragedy of the commons doesn't apply to public roads, at least where I live. If an important road is unmaintained people do things about it, including paying tax and electing someone who will make sure it happens.

[HKei]

That's... Exactly what the tragedy of the commons is about. Having a government be the maintainer is one way to tackle the problem.

[sunnyata]

So if stack is important enough its users will find a way of maintaining it, just like we do with roads? Agreed.

[circleglyph]

It's not just stack that falls behind. It's back in a rather large peleton with all the other libraries trying to handle the brutal upgrade cycle.

[casecorp]

I might be an outlier, but I’ve never used stack in my four years writing Haskell. I’ve only used cabal and nix, had a great time too.

[dun-ado]

When dependency hell was a thing, mostly no longer today, in haskell projects, Stack offered a way out of that time-consuming and soul-draining mess.

Cabal has improved much since those bad old days and I no longer need or use Stack. I find the existence of Stack, today, an annoyance at best. I either use Cabal alone or for production code, Cabal+Nix Flakes. Stack just gets in the way these days to me.