DISCUSS: Drop support for older Cabal library versions

[snoyberg]

Stack's design involves shelling out to the Setup.hs file for most activities it performs. IIRC, we currently support Setup.hs files compiled against Cabal versions as old as 1.18. However, keeping this support involves conditionals in the codebase. At some point, we will likely want to drop support for older versions of the Cabal library.

As we're looking at Stack 2.0 and adding support for Backpack, it looks like adding conditional support for component-based builds may add quite a bit of complexity to the codebase. I'd like to propose that we drop support for older versions of the Cabal library.

Upside: simplified code base, more thorough testing

Downside: users of older snapshots that include an older GHC and/or Cabal version will need to stick to older versions of the Stack executable

We should make a decision about this soon to allow those interested to start diving into component-based builds sooner rather than later.

[DanBurton]

Are there any known examples of Setup.hs files in the wild that work with old versions of Cabal but not new ones? The vast majority of Haskell packages just use defaultMain, so perhaps it would help if we could figure out who exactly would be impacted by this sort of change.

[snoyberg]

I don't remember any examples off hand, but they definitely happen. But more directly, any snapshot using an old version of Cabal will no longer work, and will need an extra-dep added for compatibility.

…

On Sun, Dec 30, 2018, 10:28 PM Dan Burton ***@***.*** wrote: Are there any known examples of Setup.hs files in the wild that work with old versions of Cabal but not new ones? The vast majority of Haskell packages just use defaultMain, so perhaps it would help if we could figure out who exactly would be inpacted by this sort of change. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4475 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBB2oVnkqKdgq2bjjh-hrRz3X7vTHlks5u-SHxgaJpZM4Zk7Ep> .

[juhp]

Do you want to define older? :-)
Do you mean say Cabal < 2?

[snoyberg]

I was vague on that, good point. I think we'd be dropping Cabal < 2, but until someone jumps into the work I don't think we'll be 100% certain which library versions will be the most important to try dropping.

[qrilka]

+1 on that, I think it makes sense to check how good is support of component-based builds in Cabal 2.0 and 2.2, from what I have seen on the topic it's not quite clear if we'll be good enough already with 2.0

[borsboom]

I think this is reasonable. It's already pretty common for OS upgrades to break support for older GHC versions, so the idea of not being able to use old GHC versions indefinitely is not new. The standard for build reproducibility that's emerged is that if your environment (stack version, OS version, etc.) stays the same then builds should be reproducible, but if any of those change then there's no guarantee (although we try not to break things unnecessarily).

Tangentially related: if we're going to break support for old GHC versions (via breaking support for older Cabal versions), I wonder if it'd be worth starting with a new stack-setup-X.yaml file so we can clean up some of the cruft that's accumulated to maintain compatibility with older Stack versions. We'd add new GHC versions in both places for a while but eventually older Stack versions will stop supporting newer GHC versions anyway.

[mihaimaruseac]

I'm also ok with dropping support on a major change of Stack.

[mgsloan]

Would this mean dropping support for lts snapshots earlier than lts-10.0? Or would the snapshot's selection of Cabal version be ignored?

Edit: Ah, from the downsides I see that probably lts earlier than 10.0 would no longer work. Hmm, not a great user experience, but I can see why it would be helpful for the codebase. Maybe automatically download an old version of stack when this happens? 🤣

While initially joking about that it would actually be pretty seamless to download the old version of stack and just forward along the cli arguments along to it. Unprecedented and weird, true, but it wouldn't be much extra code.

[snoyberg]

Closing, there are no objections to dropping the older Cabal versions it seems. We'll do this when #4745 happens.