a stacker does cabal

You are not Skykru or Treekru,, you are Wonkru now.

This will sound bat crazy, but it works.

An iron law of haskell is to develop using a very small hard drive footprint (about 40g of SSD). In this way, no more than 2 versions of ghc can co-exist on your machine (and in your worries) at a time. No more than a single stack resolver, really, and it gets pretty squeezy with both stack and ghcup.

The upside is that compilation will not consume your days and years. Compilation times for GHC will remain problematic and unlikely to improve anytime soon. Consider an O(NLogN) as a guide to how your compilation concern will scale.

The downside is that hard choices get created from iron laws. I am desperate to read SystemFC and improve on my performance understanding. To do this, I need ghc-9.0.1 to get me that ghc-lib-parser refactored goodness, so I can spawn a real live core Expr in ghci. Wish me luck.

I type this having deleted ./.stack. All stack.yamls have been erased, which stack points to null.

Sorry, Monty, but I’ve burnt the farm. I know the algae was nutritious and all but that’s no way to live.

Onward we march to cabal or bust!

cabal configure –enable-tests

So this is how you spell it as a permanent feature of a build. and it gets dropped in cabal.project.local. ok!

Warning: The package has an extraneous version range for a dependency on an
internal library: numhask >=0 && ==0.8.0.0. This version range includes the
current package but isn't needed as the current package's library will always
be used.


Spurious. Fix blocked on this.

cabal build

My first encounter with a build issue:

➜  numhask git:(ghc901) ✗ cabal build --minimize-conflict-set
Resolving dependencies...
cabal: Could not resolve dependencies:
[__1] rejecting: numhask:!test (constraint from config file, command line
flag, or user target requires opposite flag selection)
[__2] next goal: doctest (dependency of numhask *test)
[__2] rejecting: doctest-0.18.1, doctest-0.18 (conflict: numhask *test =>
doctest>=0.17 && <0.18)
[__2] trying: doctest-0.17
[__3] next goal: ghc (dependency of doctest)
[__3] rejecting: ghc-9.0.1/installed-9.0.1 (conflict: doctest => ghc>=7.0 &&
<8.11)
[__3] trying: ghc-8.10.2
[__4] next goal: base (dependency of numhask)
[__4] rejecting: base-4.15.0.0/installed-4.15.0.0 (conflict: ghc => base<0 &&
>=4.14 && <4.15)
[__4] skipping: base-4.15.0.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0,
base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0,
base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0,
base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0,
base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0,
base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0,
base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (has the same characteristics that
caused the previous version to fail: excluded by constraint '<0 && >=4.14 &&
<4.15' from 'ghc')
[__4] fail (backjumping, conflict set: base, ghc, numhask)
After searching the rest of the dependency tree exhaustively, these were the


No, -minimize-conflict-set didn’t help1.

You say cabal hell and I say allergic reaction to wading thru constraint solver output. My POV is already exhausted and a bit guilty, and it’s my first step into the wilds. Like, as kind as the thought may have been, I did not ask you to wade through the bowels of base-3 like some insane archivist, looking for how we did things prior to fmap.

This is a clear example of Le Chatelier’s principle in Systemantics2; that a complex system tends to oppose it’s own function. Gall describes it thus:

Administrators, whose original purpose was to keep track of writing supplies for the professors, now have the upper hand and sit in judgment on their former masters.

I’m not the constraint solver, you are. Go on, hunt around in the depths of your own ineptitude until you see what you did wrong and get back to me.

This is stack (from memory)

Almost there, champ! doctest upper bound just needs a slight bump.


sniff

but ever onward.

cabal test

I added a -v, as suggested.

  numhask git:(ghc901) ✗ cabal test -v
this build was affected by the following (project) config files:
Build profile: -w ghc-9.0.1 -O1
In order, the following will be built:
creating
creating
Using self-exec internal setup method with build-type Simple and args:
/Users/tonyday/.ghcup/bin/cabal-3.4.0.0 act-as-setup --build-type=Simple --
build --verbose=2
Component build order: test suite 'test'
creating
creating
creating
Preprocessing test suite 'test' for numhask-0.8.0.0..
Building test suite 'test' for numhask-0.8.0.0..
creating
creating
whenReRegister: previously registered
Using self-exec internal setup method with build-type Simple and args:
["act-as-setup","--build-type=Simple","--","test","--verbose=2","--builddir=/Users/tonyday/haskell/numhask/dist-newstyle/build/x86_64-osx/ghc-9.0.1/numhask-0.8.0.0/t/test","--log=$pkgid-$test-suite.log","--machine-log=$pkgid.log","--show-details=failures","test"] /Users/tonyday/.ghcup/bin/cabal-3.4.0.0 act-as-setup --build-type=Simple -- test --verbose=2 --builddir=/Users/tonyday/haskell/numhask/dist-newstyle/build/x86_64-osx/ghc-9.0.1/numhask-0.8.0.0/t/test --log=$pkgid-$test-suite.log --machine-log=$pkgid.log --show-details=failures
test
Running 1 test suites...
Test suite test: RUNNING...

Use -v (or :set -v in ghci) to see a list of the files searched for.
|
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Test suite test: FAIL
Test suite logged to:
0 of 1 test suites (0 of 1 test cases) passed.



Now I know from vast experience that this chain of non-words will not make the slightest sense to me, and lead to more riddles. I am fairly certain that cabal knows where my library is, but just in case I looked through the list, and it might be there if inplace means what I think it means.

Otherwise, the core error proves too common to pattern match on.

A bisectional diversion

I had already resigned myself to no more stack templates - hand-editing a new project gives some space to think at the start, to craft a really good synopsis, description and example usage. I thought the build problem would reveal itself with a ground-up following of the cabal docs.

cabal init --cabal-version=2.4 --license=BSD-3-Clause --lib --tests

But inserting the guts of the tests into the newly created project gave the same error.

Houston, we have a go for launch.

doctest was the dog not barking. By that deduction I eventually found #6087, which led me to a needed cabal.project tweak.

packages: numhask.cabal

write-ghc-environment-files: always

-- Might be helpful when hackage doesn't build properly...
keep-going: True


A new pipeline

cabal clean && cabal configure --enable-tests && cabal build && cabal test


Nou Blodreina nowe!

But forget my moaning; I have a green for my personal production prelude on day one. I hadn’t arrived at cabal heaven but it was a good day’s march!

Next week

What environment do I run whilst waiting for haskell-language-server to bump up? Hello, haskell-mode, anyone home? Have you fixed indentation? Do I need to brush up on my emacs comint/flycheck chops?

Why do I have to say ghcid -c cabal repl, and how did people expect me to find this?

There is no –file-watch. Am I your personal refresh button?

1. The cabal team’s recent plea for feedback is a wonderful spirit, and I hope any criticism that may attach to this piece is taken as a considered response, and can also be regarded as an offer to help out. ↩︎