diff options
Diffstat (limited to 'haskell/cabal-lib.html')
| -rw-r--r-- | haskell/cabal-lib.html | 12 |
1 files changed, 6 insertions, 6 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 </code></pre> <p>and you can even make that change permanent with <code>cabal install --lib base</code>, which adds (in my case) a line <code>package-id base-4.17.2.0</code> to the aforementioned <code>default</code> file.</p> -<p>In short, a <em>GHC environment file</em> was created by <code>cabal</code> that contains a list of packages in scope for <code>ghc</code> when you're accessing <code>GHC</code> through <code>cabal</code> in the context of a project. +<p>In short, a <em>GHC environment file</em> was created by <code>cabal</code> that contains a list of packages in scope for <code>ghc</code> when you're not using <code>cabal</code>, or outside the context of a project. You need to either manage this file manually or through some <a href="https://github.com/phadej/cabal-extras">helper tool</a>, and you will need to, because <code>cabal</code> won't resolve conflicts for you. You're back to manual, imperative management of dependencies.</p> -<p>Furthermore, this way of installing dependencies is fundamentally separate from the code that <em>uses</em> 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.</p> +<p>Furthermore, this way of installing dependencies is fundamentally separate from the code that <em>uses</em> those dependencies, and there is just <em>one</em> 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.</p> <h2>How to fix the situation</h2> <p>If you got yourself in a pickle due to an unintended use of <code>cabal install --lib</code>, you can undo its effects (apart from having used some disk space in compiling the packages in question) by removing the <code>default</code> file mentioned above. This is in <code>~/.ghc/<em>architecture</em>-<em>OS</em>-<em>ghcversion</em>/environments/default</code>.</p> @@ -101,7 +101,7 @@ This is in <code>~/.ghc/<em>architecture</em>-<em>OS</em>-<em>ghcversion</em>/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. :)</p> <h2>What to do instead</h2> <p>Create a project! -The intended mode of operation of the modern Haskell tooling, that is <code>cabal</code> and <code>stack</code>, is to always work inside of a <em>project</em>. +The intended mode of operation of the modern Haskell tooling, that is <code>cabal</code> or <code>stack</code>, is to always work inside of a <em>project</em>. Often, "project" basically means "package", but you can have projects with multiple packages in them (using a <code>cabal.project</code> file, see <a href="https://cabal.readthedocs.io/en/3.10/cabal-project.html">the docs</a>).</p> <p>Creating a package is easily done using <code>cabal init --simple</code> inside a fresh directory. If you like to be asked more questions, you can also opt for <code>cabal init</code> instead. @@ -111,8 +111,8 @@ Put a comma (<code>,</code>) between the package names in the <code>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 <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#sublibs">the documentation</a>, but don't worry about that.)</p> <p>You can start writing code in the <code>app/Main.hs</code> file (or <code>src/MyLib.hs</code> file if you selected Library) and run using <code>cabal run</code> (or build using <code>cabal build</code> in the case of a library). -<code>cabal</code> will automatically ensure that a consistent set of versions is compiled and made available, if at all possible. -You can add <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends">version bounds</a> to your dependencies if you want to apply some proper software engineering principles.</p> +<strong><code>cabal</code> will automatically ensure that a consistent set of versions is compiled and made available, if at all possible.</strong> +You can also add <a href="https://cabal.readthedocs.io/en/3.10/cabal-package.html#pkg-field-build-depends">version bounds</a> to your dependencies if you want to apply some proper software engineering principles.</p> <p>(If you want to use <code>stack</code> instead of <code>cabal</code>, try <a href="https://docs.haskellstack.org/en/stable/GUIDE/">their getting started guide</a>.)</p> <h3>An even lighter-weight alternative</h3> <p>An alternative to creating a project is to make a <em>cabal script</em>: this allows you to effectively make a self-contained project inside a single Haskell file. |