ArchLinux环境下Haskell开发环境搭建最佳实践及工具（ghc、cabal-install、stack）相关疑问解答

Hey there! Let's tackle your questions about using Haskell on Arch Linux—this is such a common pain point for new Haskell developers, so you're absolutely not alone in feeling confused about all these tools. Let's break everything down clearly.

First: What Each Tool Does (and Their Pros/Cons) #

1. GHC (Glasgow Haskell Compiler) #

GHC is the core foundation of Haskell development—without it, you can't compile or run Haskell code at all. Tools like Cabal and Stack are just wrappers around GHC to make your life easier.

• Pros:
  • Lightweight, no extra setup needed once installed.
  • Gives you direct access to ghc (compiler) and ghci (interactive REPL) for quick scripts or testing snippets.
  • The Arch ghc package is system-wide, so it's available everywhere out of the box.
• Cons:
  • Managing dependencies manually is a nightmare. You'd have to download, compile, and link every dependency yourself, and version conflicts will quickly become unmanageable for real projects.

2. cabal-install #

Cabal is the official package manager and build tool for Haskell, maintained by the Haskell Foundation. Think of it like pacman, but for Haskell packages hosted on Hackage (Haskell's equivalent of PyPI).

• Pros:
  • Deep integration with the full Haskell ecosystem—every package on Hackage is accessible via Cabal.
  • Modern versions use Nix-style local builds (default now), which isolates project dependencies from your system and other projects, so no more "global pollution" issues.
  • Works directly with your system's GHC, so you don't need to download a separate compiler if you're happy with Arch's version.
• Cons:
  • New users might hit dependency conflicts early on, especially if a package requires a specific GHC version that doesn't match your system's.
  • Older versions had clunky sandboxing, but that's mostly fixed with the new Nix-style setup.

3. Stack #

Stack was built by the Commercial Haskell team to solve the "reproducible builds" problem—meaning you get the exact same build results no matter where you run the tool.

• Pros:
  • Self-contained GHC installations: Stack downloads and manages its own GHC versions in your user directory, so it never touches your system GHC. Perfect if you need multiple GHC versions for different projects, or if you don't want to rely on Arch's GHC updates.
  • Beginner-friendly: stack new creates a ready-to-go project, stack build handles all dependencies, and stack ghci launches a REPL with all your project's packages loaded. No manual dependency juggling.
  • Uses Stackage: A curated subset of Hackage where all packages are tested to work together. This eliminates most dependency conflicts by design.
• Cons:
  • Initial setup can be slow—downloading a full GHC version takes time and disk space.
  • Stackage updates lag behind Hackage, so if you need the absolute latest package versions, you'll have to tweak your stack.yaml to pull from Hackage directly.
  • Can feel disconnected from system-level tools (like your haskell-* packages) since it uses its own isolated environment.

Can They Coexist? Will They Conflict? #

Short answer: Yes, they can coexist perfectly—but you need to be mindful of which environment you're using at any given time.

• Stack runs in its own isolated environment by default. If you use stack ghci or stack build, it'll use its own GHC and dependencies, completely separate from your system's ghc or Cabal setup.
• System-level ghc and cabal are global, so they'll use your Arch-installed GHC and any haskell-* packages you've added.
• The only potential "conflict" is if you mess with your PATH variable: if you put Stack's bin directory before your system bin, running ghc directly will call Stack's GHC instead of the system one. This isn't a bug, but it's easy to forget which version you're using. Just be intentional about which commands you run.

Are Any Tools Redundant? #

• GHC is never redundant—all other tools depend on it one way or another (either your system's copy, or Stack's downloaded copy).
• If you primarily use Stack, you might not need the system-level cabal-install—but it's harmless to keep around for quick tests outside Stack projects.
• Conversely, if you use Cabal with system GHC, Stack is optional—but it's great for projects where you need reproducible builds or specific GHC versions.

Key Notes for Your Current Setup #

You mentioned you have ghc, stack, and a bunch of haskell-* packages installed. Here's what you need to know:

• Those haskell-* packages: These are pre-compiled by Arch against your system GHC. They work fine for global tools (like hlint for code linting, or stylish-haskell for formatting), but for project-specific dependencies, you don't need them. Stack will download and compile its own dependencies in its isolated environment, and Cabal's local builds will do the same. If you update your system GHC, Arch will automatically recompile these haskell-* packages—but sometimes outdated packages might break temporarily until maintainers update them.
• Vim as an IDE: Stack is actually a great fit here! Most Haskell Vim plugins (like haskell-vim or language server integrations) can be configured to use Stack's GHC and tools. This ensures your editor uses the same environment as your builds, avoiding "works in editor but not in build" issues.
• Things You Might Be Missing:
  • Environment isolation: Avoid using Cabal's --global flag or system haskell-* packages for project dependencies. Let Cabal/Stack handle project-specific dependencies locally—this prevents version conflicts across projects.
  • Clean up old files: Stack stores GHC versions and build artifacts in ~/.stack, which can get huge over time. Run stack clean --full to clear old build outputs, or stack purge (carefully!) to wipe the entire Stack environment if you start fresh.
  • ghci tips: If you use the system ghci and get "could not find module" errors, use ghci -package vector-space to load specific packages. For projects, use cabal repl (with Cabal) or stack ghci (with Stack)—these commands automatically load all your project's dependencies into the REPL.
  • Update strategies: System GHC updates with Arch's pacman. For Stack, update your project's GHC version by changing the resolver field in stack.yaml. Cabal will automatically use the latest system GHC, so you may need to rebuild project dependencies after a GHC update.

内容的提问来源于stack exchange，提问作者Enlico