From ae2086c1b9dd4e6095d2e83bf4fb428296ae3a64 Mon Sep 17 00:00:00 2001
From: Tom Smeding and you can even make that change permanent with In short, a GHC environment file was created by In short, a GHC environment file was created by Furthermore, this way of installing dependencies is fundamentally separate from the code that uses those dependencies, and is just one such list.
-So if you have multiple scripts that you'd like to work globally, outside of a project, their dependency sets had better be compatible. Furthermore, this way of installing dependencies is fundamentally separate from the code that uses those dependencies, and there is just one such global list.
+So if you have multiple Haskell programs that you'd like to work globally, outside of a project, their dependency sets had better be compatible, or things will break. If you got yourself in a pickle due to an unintended use of cabal install --lib base
, which adds (in my case) a line package-id base-4.17.2.0
to the aforementioned default
file.cabal
that contains a list of packages in scope for ghc
when you're accessing GHC
through cabal
in the context of a project.
+cabal
that contains a list of packages in scope for ghc
when you're not using cabal
, or outside the context of a project.
You need to either manage this file manually or through some helper tool, and you will need to, because cabal
won't resolve conflicts for you.
You're back to manual, imperative management of dependencies.How to fix the situation
cabal install --lib
, you can undo its effects (apart from having used some disk space in compiling the packages in question) by removing the default
file mentioned above.
This is in ~/.ghc/architecture-OS-ghcversion/environments/default
.~/.ghc/architecture-OS-ghcversion/en
Removing the entire store folder for a particular GHC version is safe, however -- even though this does of course mean that you may need to recompile a lot of things later. :)
Create a project!
-The intended mode of operation of the modern Haskell tooling, that is cabal
and stack
, is to always work inside of a project.
+The intended mode of operation of the modern Haskell tooling, that is cabal
or stack
, is to always work inside of a project.
Often, "project" basically means "package", but you can have projects with multiple packages in them (using a cabal.project
file, see the docs).
Creating a package is easily done using cabal init --simple
inside a fresh directory.
If you like to be asked more questions, you can also opt for cabal init
instead.
@@ -111,8 +111,8 @@ Put a comma (,
) between the package names in the build-depend
A package (a single thing in the package repository, should you decide to upload it to Hackage at some point) can contain multiple components: possibly one public library, as well as zero or more executables, test suites, or benchmarks.
(There is also the concept of an "internal library", for which see the documentation, but don't worry about that.)
You can start writing code in the app/Main.hs
file (or src/MyLib.hs
file if you selected Library) and run using cabal run
(or build using cabal build
in the case of a library).
-cabal
will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.
-You can add version bounds to your dependencies if you want to apply some proper software engineering principles.
cabal
will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.
+You can also add version bounds to your dependencies if you want to apply some proper software engineering principles.
(If you want to use stack
instead of cabal
, try their getting started guide.)
An alternative to creating a project is to make a cabal script: this allows you to effectively make a self-contained project inside a single Haskell file. -- cgit v1.2.3-70-g09d2