[Answered] Is Stack still actively developed?

#41

While I understand your idea… I’m not sure what you mean with “deprecate”? Who would deprecate stack? Only the maintainers can do that… and even if they do, their users might decide to just fork and keep maintaining it.

There’s no collective decision to be made about it. The only decision a community can do is where to put effort in, maybe what ideas to promote. But that’s about it.

As long as stack has a strong user base and is in a usable state, ghcup will support it (despite the problems it causes for HLS and VSCode).

2 Likes
#42

Well yeah the HF, Stack maintainers (who I understand are all volunteers now), and Cabal maintainers can sit down and come to a big agreement. The deprecation message would be something like be:

We the stack maintainers are retiring Stack.

Stack has been an excellent project that pushed the Haskell ecosystem forward in many ways, but by this point in 2023 cabal / GHCUP have now caught up and implemented what we think are all the core features Stack pioneered. Furthermore, there are a number of other new features (Backpack, multiple public libraries, etc.) that would be quite difficult to implement in Stack.

At this point, we no longer think the community needs Stack to push it along; our major points have been made and are no longer controversial. We thus are officially retiring Stack because it doesn’t make sense to maintain two separate tools which no longer have any major disagreements.

1 Like
#43

That sounds… interesting. Let me know how it goes.

3 Likes
#44

I wish haskell community had great deceptive politician who could settle these kind of matters.

1 Like
#45

Does Cabal natively support package.yaml and hpack? The reason I still use Stack is that I simply set the resolver in stack.yaml and via package.yaml have hpack automatically generate dependencies in cabal. This is why I’ve always recommended Stack over Cabal especially for new users. Also, Stack automatically resolving and managing GHC version is one less burden new users have to deal with delving into the world of Haskell. I’d be truly upset if Stack falls by the wayside because I still don’t think Cabal meets many of the use cases that make Stack so seamless and intuitive, especially for new users.

4 Likes
#46

If anyone spots something wrong in the Stack documentation, please do raise an issue in the repository (or bring an existing issue to my attention). Those are the sort of issues I can usually fix myself. The exception is where they are specific to Unix-like operating systems (a recent issue about ‘Nix flakes’ being an example).

4 Likes
#47

I just want to show some love and support for the stack maintainers here; I use stack daily; in many projects, and my life would be significantly more frustrating without it. I really appreciate all the effort that has gone into it.

I also appreciate my cabal friends and users and developers.

I believe that we will be able to find a nice way forward, somehow :slight_smile:

11 Likes
#48

  • mark all older documentation as being deprecated; if it’s possible to do so then augment the meta-data so search engines don’t rank older documentation so prominently.

  • According to:

    • https://github.com/commercialhaskell/stack/blob/master/ChangeLog.md#v211

    both the --resolver and solver options were dropped from Stack, but --resolver appears in the current documentation:

    • https://docs.haskellstack.org/en/v2.7.5/GUIDE/#resolvers-and-changing-your-compiler-version

    …was it reinstated?

#49

Until your post, I had not realised that there were old versions of the Stack online documentation available. I’ve always gone (usually via Google) to https://haskellstack.org (which redirects to Home - The Haskell Tool Stack) and had not spotted the small ‘version’ box in the bottom right corner. When people fix the documentation, they are asked to target the stable branch. I do not know where the earlier online versions are picked up from. I’ll see if I can find out.

2 Likes
#50

On stack --resolver=RESOLVER ..., it is available. See also stack --help (… Override resolver in project file).

On the ChangeLog entry for v2.1.1, I can see where it says --solver was dropped but cannot see where it says that --resolver was dropped.

#51

While trying to find the URL again, I found this:

…so it seems the problem with --resolver was only with GHC 8.2.2 - I must have encountered a proverbial “red herring”: apologies for the confusion.

#52

Hi, just chipping in my 2 cents here. I am not familiar with the background history for the past one or two decades, to find the answer to the question as it’s titled (though it seemed more of a rhetorical question), I went on to github and compared the objective metrics:

image
image1506×507 63.8 KB

image
image1473×472 54.1 KB

It seems to be me quite a indisputable answer from an outsider point of view, without knowing about the drama?

3 Likes
GHCUp button on www.haskell.org
#53

Useful, thanks. Bear in mind that the scales are quite different though. You should mentally divide the cabal peaks by more than 3! (200 / 60)

4 Likes
#54

Is there a guide available for the stack-using people how to migrate to cabal? Maybe just to try it out.

6 Likes
#55

I love this idea! I think it can serve as a great touchstone for the claim that Stack workflows can be replicated simply with Cabal. If it’s simple, it should be easy to write a simple guide to explain it!

7 Likes
#56

If it’s simple, it should be easy to write a simple guide to explain it!

And if it isn’t, there would be a list of pain points to mend.

11 Likes
#57

Does Cabal support constraining one’s project with Stackage’s snapshots? To me that’s stack’s killer feature, and I am not able to imagine why anyone would want to step away from stack and no longer be able to use this feature.

4 Likes
#58

Apparently it’s in progress, though it’s not clear to me what the status is.

1 Like
#59

You can do it today by copying the stackage snapshot cabal.config files into your projects (e.g. this one for lts-19.16). Linking to these remotely is part of the soon to be released version 3.8 of cabal.

It remains to be seen how well it can deal with packages that are not in the snapshot, and how easy it is to use other versions of packages that are in the snapshot.

1 Like
#60

It is done and available in 3.8 pre-release (available through ghcup).

What doesn’t work is overwriting constraints. Constraints in cabal.project are simple union. Duncan had a proposal to add a constraint algebra where you can specify how constraint sets are combined. Afaik, no one is working on that. So if you wanted to overwrite specific constraints from the stackage set, you’d have to process it yourself. That’s actually not very hard to write a small script tool for.