From ae2086c1b9dd4e6095d2e83bf4fb428296ae3a64 Mon Sep 17 00:00:00 2001 From: Tom Smeding Date: Sun, 22 Oct 2023 23:11:39 +0200 Subject: haskell/cabal-lib: Edits --- haskell/cabal-lib.html | 12 ++++++------ haskell/cabal-lib.md | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/haskell/cabal-lib.html b/haskell/cabal-lib.html index 9f93c19..80be102 100644 --- a/haskell/cabal-lib.html +++ b/haskell/cabal-lib.html @@ -89,11 +89,11 @@ active package flags: -package-id brick-1.10-1f76dfaf75736c0f6e2a4a2cf992bb12da05f6bbc7985f9787547739947e4696

and you can even make that change permanent with cabal install --lib base, which adds (in my case) a line package-id base-4.17.2.0 to the aforementioned default file.

-

In short, a GHC environment file was created by cabal that contains a list of packages in scope for ghc when you're accessing GHC through cabal in the context of a project. +

In short, a GHC environment file was created by 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.

-

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.

How to fix the situation

If you got yourself in a pickle due to an unintended use of 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.

@@ -101,7 +101,7 @@ This is in ~/.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. :)

What to do instead

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 even lighter-weight alternative

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. diff --git a/haskell/cabal-lib.md b/haskell/cabal-lib.md index 2504fc8..3688d05 100644 --- a/haskell/cabal-lib.md +++ b/haskell/cabal-lib.md @@ -131,12 +131,12 @@ active package flags: and you can even make that change permanent with `cabal install --lib base`, which adds (in my case) a line `package-id base-4.17.2.0` to the aforementioned `default` file. -In short, a _GHC environment file_ was created by `cabal` that contains a list of packages in scope for `ghc` when you're accessing `GHC` through `cabal` in the context of a project. +In short, a _GHC environment file_ was created by `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](https://github.com/phadej/cabal-extras), and you will need to, because `cabal` won't resolve conflicts for you. You're back to manual, imperative management of dependencies. -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. ## How to fix the situation @@ -151,7 +151,7 @@ Removing the entire store folder for a particular GHC version is safe, however - ## What to do instead 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](https://cabal.readthedocs.io/en/3.10/cabal-project.html)). Creating a package is easily done using `cabal init --simple` inside a fresh directory. @@ -164,8 +164,8 @@ A package (a single thing in the package repository, should you decide to upload (There is also the concept of an "internal library", for which see [the documentation](https://cabal.readthedocs.io/en/3.10/cabal-package.html#sublibs), 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](https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends) 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](https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends) 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](https://docs.haskellstack.org/en/stable/GUIDE/).) -- cgit v1.2.3-54-g00ecf