GHC and Cabal: the big picture

Learn
#21

Yeah, that line jumped out at me as well, given our previous discussion about wishing it did!

Interesting to hear how we “lost” this feature.

#22

Thanks for linking to that! I knew I’d discussed it before somewhere, but couldn’t remember where.

#23

I have an empty project that looks like:

script
- src
-- Main.hs
- script.cabal

with script.cabal looking like:

cabal-version: 3.0
name:          script
version:       0.1.0

executable Program
    default-language: GHC2024
    main-is: Main.hs
    hs-source-dirs: src
    ghc-options: -rtsopts -threaded
    build-depends: base

It’s basically cabal init --simple without the verbose explanations.
I copy paste the script folder when prototyping.
Afterwards it’s just cabal clean, build and run from your shell of choice.

If you don’t want -rtsopts or -threaded, remove them. (Why do I keep them? Because otherwise I forget that they are indeed a thing.)
If you want to make a lot of modules and don’t want to fill in exposed-modules, add -Wno-missing-home-modules if the warnings bother you.
If you want all warnings, add -Wall to ghc-options.
If you want to add packages, append them to build-depends.
If you want to generate core or change optimization level, ghc-options again.

If you are done and want to coalesce this into a project, check the generated plan.json to see what versions you need and set the package bounds as you see fit.

Admittedly, creating a script file and just doing “ghc Main.hs” to --make a project is very convenient. But I appreciate a lot being able to just grab anything from Hackage to play with it.

If you feel intimidated by GHCup you can download the kindly provided binaries for GHC or cabal-install.

To be fair, JAR hell, DLL hell, npm hell, and crate hell are real, and the errors are obscure too. Or you end up importing react 10 times. It’s an enterprise rite of passage to have an obscure error because dependency B (depends on A-0.1) and dependency C (depends on A-0.2) get mad at runtime when you feed them types from A-0.2 and A-0.1 respectively. Semver helps up to a point.

The moral of the story is:

  1. Do not abuse dependencies.
  2. Pin them.
  3. Separate interfaces from implementation so when the day comes, it’s playing dependency puzzle over logic refactoring.
  4. No, you can’t escape.
2 Likes
#24

Users can indeed learn to work with the current tools, but there is also plenty of room for improvement in cabal (even if there are other tools that are worse).

4 Likes
"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?"
#25

(I’ve changed the link in that message to point to Artem’s reply to Simon):

Better yet, you could upgrade your cabal-install to version 3.10.3 (recommended by GHCup), where this behavior was reversed (base is added by default).

  • “3.10.3.0 is strictly a bug-fix release” – which is what I’d expect as a lowest-order digit change vs 3.10.1 that Simon was running.

  • And yet Artem’s message goes on to consider several controversial consequences. Is it the norm to sneak behaviour changes in under “bug-fixes”?

  • Is cabal-install stable enough yet that GHC should be inflicting it on newbies? Do newbies want or need to be grabbing packages from hackage? The GHC distro comes with heaps of libraries and utilities. It alone was fine for my first few years of hobby-Haskell.

So it seems, and Python package managers (several of) also concede dependencies can get tangled. Again, do we need to inflict any package manager at all on newbies? Or is it they’re all coming from other languages with as bad/worse package managers, and they somehow accept this much pain as what ‘real’ programmers do? (I’m happy to concede I was last a ‘real’ programmer several decades ago.)

1 Like
"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?"
"Is cabal-install stable enough yet that GHC should be inflicting it on newbies?"
#26

2 posts were split to a new topic: Is cabal-install stable enough yet that GHC should be inflicting it on newbies?

#27

…meanwhile, and since 2002:

So can anything from there be reused here? If cabal-the-command is only one build system, while the package DB is part of a common architecture, which has caused confusion and actual problems as to where “one stops and the other begins”…something has gone very wrong somewhere, and a “big picture” overview will either:

  • miss completely the (data) point showing where this overlap began,
  • or will lose that point in a vast space of other points of varying relevance.

It seems what’s needed here is something like:

an investigation to determine when and where:

  • that original Cabal proposal’s design was exceeded,

  • or where the implementation of the various Cabal “pieces” went beyond that original Cabal proposal (and presumably started to depend too closely on GHC).

Otherwise we can all probably look forward to another (attempt at a) “big picture” overview in a few year’s time (when things are worse).

#30

Can we please try to not derail at least one thread?

10 Likes
#31

Folks, this thread is about the nitty gritty details of the interaction between GHC and cabal, and specifically the document that Tom and Simon prepared. Please let us keep this discussion on topic :slight_smile:

7 Likes