[Answered] Is Stack still actively developed?

#1

Answer: At the time of me asking this question stack was in a bit of a transition from FP complete to new maintainers. I’m happy to see that @mpilgrem has stepped up and picked up development of stack now.

Continuing the discussion from GHCUp button on www.haskell.org:

I haven’t seen much presence of official stack communication online in recent years. Is (the command line tool) stack still actively developed? I’ve heard about bugs that have been known for years. They don’t have support for backpack and cannot install HLS, and they don’t seem to want to add support for GHCup. Looking at their contributor activity on GitHub shows that the volume of commits and changes is fading since about 2019-2020.

I have once recommended stack to newcomers because it seemed like a more streamlined experience, but now I fear that it is slowly fading out as the competition (cabal and ghcup) are incorporating all of its features. That might be a good thing, but I would at least hope to see some official announcement about the direction of the project.

And of course I don’t want to downplay the achievements of the developers of Stack. Although I wasn’t really around yet, I’ve heard that it was quite a big improvement at the time and it seems to have made Haskell more attractive for industry. And of course stackage will probably still stay relevant, but I want to focus on the command line tool for this discourse topic.

3 Likes
#2

“actively developed” I’m not sure, but it has a maintainer: https://github.com/commercialhaskell/stack/commits?author=mpilgrem

1 Like
#3

…who seems to be doing the bulk of that work, if Commits · commercialhaskell/stack · GitHub is any measure of recent activity.

That would seem to explain why hasfuell’s recent PR has apparently stalled.

The mystery deepens:

1 Like
#4

This is the most recent communication I could find:

The slack channel mentioned there looks like invite-only, and a haskell-foundation centric approach that never happened. Does anyone know where the stack people interact?

1 Like
#5

There was some discussion about that here on discourse too: Proposal: unified installer

But I consider that more a Haskell Foundation initiative than a Stack initiative.

2 Likes
#6

Oh. I thought there were competition/conflict preventing the inter-ops. This thread suggests another possibility: stack is losing activity and falling out of fashion.

(Either sounds depressing to me though)

EDIT: The remark of call-out to stack seem to confirm both. Unamended conflict with loss of activity (perhaps through loss of interest). More sad.

#7

There was also this a few months later in September 2021:

No mystery; stack’s lead maintainer got busy elsewhere and it currently doesn’t have much active maintenance. (Or if it does, the results are not showing yet.)

5 Likes
#8

That does explain a lot. Especially the part about stack:

Special call out: Stack

Stack is by far the largest project I maintain. I don’t maintain it alone, but none of the maintainers are spending a significant amount of time on it. Frankly, for all of my needs, it’s checking the boxes right now. Most of my pain points come from changes coming upstream from GHC or Cabal causing breakage, or introducing new features (like multiple libraries per package) that require large overhauls to how Stack operates.

I haven’t said this before, but I’ll say it now: I’m not interested in investing any time in staying on that treadmill, or introducing new features to Stack. I had hoped that with the Haskell Foundation launch this year, we would have an affiliation process for projects that allowed better interproject communication and reduced the maintenance burden. That never came into existence, and so now I feel pretty comfortable in saying: outside of making sure Stack continues to work for my primary use cases, I’m not going to be investing my own time much going forward.

People are free to take those statements as they will. I’m not sure how large an overlap there is between Stack users and people looking to use the latest GHC and Cabal features that it doesn’t support. I know that it becomes a blocker for the Stackage team sometimes. And I know regressions in Stack with newer GHC/Cabal versions (like overly aggressive recompilation, or broken deregister support for private libraries) causes the Stackage team pain and suffering. I’d love to see these addressed. But I’m not going to do it myself.

In other words, this is a more serious call to action than I’ve made previously. If people want to see changes and improvements to Stack, you need to get involved personally. I’ll continue maintaining the project in its current state, together with other maintainers currently doing so. But in the past few months, as I’ve been thinking about where I wanted to spend my limited time after the babies were born, I decided that it was time to call out Stack as needing motivated maintainers, or to see it sit in a feature complete, non-evolving state. I’m quite happy with either outcome.

I’m not happy with the current situation which is that Stack is “feature complete” and blocking innovation (Backpack) and is not integrating well with other tools (HLS & GHCup).

5 Likes
#9

Hello! I came across this ‘discourse’ tonight, via Stack Governance. @hasufell mentions me above, so I thought I would explain my interest in Stack.

I code as a hobby, outside of work. For better or worse, I am a Windows user. I came across Haskell in 2013 and was hooked. Back in 2013, I struggled with Cabal (the tool) and Stack helped me to use GHC. Trying to understand how Stack works has also taught me a lot about Haskell and GHC over the years - although parts of Stack are a mystery to me (especially parts unsupported on Windows). So, when I have some spare time, I try to help on the repository to give something back. I would describe myself as more of a janitor than an architect. If I spot something that looks wrong, in the code base or in the online help, I try to understand it and then, if I can, to fix it. Much of that is small stuff - just sweeping up.

Most recently, I have been trying to reduce the total number of open issues and pull requests by finding ones that fall within the scope of my experience.

I would be sad if Stack fell into disrepair, especially while Michael Snoyman has his family commitments.

21 Likes
#10

@jaror I think this is the answer to your question. :slight_smile: FYI I’m pretty sure Discourse has a “this answered my question” button similar to quora or stackoverflow, assuming that functionality is included in this instance of Discourse.

#11

I can’t find it on this discourse instance. I think that feature is only enabled on some more Q&A focused instances. Edit: but I can change the title!

2 Likes
#12

It is an awkward idea for many people given memories of the Cabal Stack drama a few years ago, but I think Stack should be officially deprecated. It is a waste of resources to maintain two increasingly similar large software projects.

I would suggest the Haskell Foundation reach out to existing stack users, figuring out any missing functionality Cabal/cabal-install still needs. For sake of a smooth migration, this should include either a tool to convert stack.yamls to cabal.projects, or support for stack.yaml as an alternate project format directly within cabal-install.

After the missing functionality is implemented, we can officially deprecate Stack.

3 Likes
#13

If Cabal and Stack are now that similar, another option is to abstract out the commonalities into one or more libraries which both projects can then share. Future “development suites” could also benefit: they can more easily built a prototype using the new libraries.

1 Like
#14

Good idea! Let’s call that library Common Architecture for Building Applications and Libraries (or Cabal for short) :stuck_out_tongue:

9 Likes
#15

…only if the entire Stack community agrees to it :-p

(Apologies if the intent wasn’t clear: my previous message was meant to be a serious suggestion…)

Attempting to be serious again: “Common Build Infrastructure” as a name, since the building of applications and libraries would appear to be self-evident…

#16

When I say give Cabal some support / migrations for stack.yaml, that is basically tantamount to the same thing. Cabal / cabal-install implementing features like backpack that would require a massive overhaul for stack to support make starting from Cabal / cabal-install the obvious choice.

1 Like
#17

Then this should also be obvious:

cabal --stack [other options]

which brings up an UI that Stack users can use right away, and incorporates supporting/migrating Stack configurations. Or is this thread going to degenerate into yet another screaming contest about the relative virtues of Cabal vs Stack?

#18

Stack has heaps of domain knowledge that you can’t obtain from cabal. When things stuff up it’s much easier to hack into the problem with stack.

An example. If you look at https://github.com/digital-asset/ghc-lib/ aka how we actually create ghc artficacts, you would find stack at the core of our critical infrastructure.

You can’t even get a file monitoring loop going for cabal yet, so a presumption that stack should be deprecated just doesn’t appreciate the gap between cabal functionality and the real world, that stack has solved for many years.

9 Likes
#19

If I can just add some contextual information about stack and it’s positioning in the ecoverse.

It is underappreciated that a main point of stack is stackage. As a maintainer, I see the pointless friction of PvP on library maintenance and development. Stackage and the nightly/lts resolver system is a joy versus firing up cabal and crossing fingers. stack is thus a productive and less painful process.

Also underappreciated is the extent to which stack has propped up cabal usage for so long. Cabal is an old and creaky piece of engineering. The maintainers do the work of angels, but it is a bloated mess, impossible to fix really. stack is what the community used to paper over this.

Both PvP reform and cabal replacement have been in the too hard basket for a decade, and, for the majority of Haskell coders still, stack keeps some sort of sanity for the average build process.

8 Likes
#20

Like what? I’m not sure I understand what you mean with domain knowledge here. Stack isn’t really usable as a library.

You mean https://github.com/haskell/cabal/issues/5252 ?

Seems like a rather small feature to add.

The next Cabal version will have support for remote freeze files, which allows you to directly import a stackage set.

Sure, there’s some more edges that can be worked on (like an algebra to combine constraints). But it’s already usable. I’ve worked on many stack projects by just converting stack.yaml to freeze files without anyone noticing and it worked like a charm.

It seems to me you really haven’t used cabal in a long time.

I tend to agree in terms of code. I’ve contributed to both projects (not too much though). But I find it an odd argument, given that cabal clearly has the upper hand in terms of features.

Stacks’ complete lack of a constraint solver really doesn’t make it a viable choice for many users.

Cabal has already catched up in many areas, covers way more use cases, is actively developed and can easily add the last few missing features that users desire… and yes, including automatic toolchain installation (see https://github.com/haskell/cabal/issues/7394 ).

Note: I’m not really agreeing to deprecate stack. That’s not a community decision. It’s a maintainer decision. But if we ask ourselves the question “which tool to fix?” then I think cabal is the very clear answer.

5 Likes