The threaded runtime is required at least for hledger's pager output,
and probably for other things. It's controlled by the "threaded" build
flag for some historical reason. Now, that flag is marked as manual,
so that it can no longer be toggled by cabal. (Probably the build flag
should be dropped, that can be tried later.)
Related: Debian bug #1120833, causing an unusable hledger-1.50.2 package.
System.IO.hGetContents' was the latest paper cut; I could keep
supporting ghc 8.10.7, or at least 9.0-9.4, released 2021-2023;
but feck it. Debian Stable has 9.6 and this time can be better spent.
Serving the OpenAPI JSON schema means that clients can auto-discover how
to use the API. I am particularly interested in this because open-webui
can use OpenAPI to add context to LLM responses.
Previously our cabal files used cabal-version 1.12, and were in theory
buildable with any ancient version of cabal. Now at least cabal 2.2
(or a version of stack built with with similar Cabal version) is
required to build hledger.
Builds made with ghc 9.10+ and the 'debug' build flag, will show
(some kind of, partial) stack traces when the program ends with an
error. (And also will have ghc-debug support enabled.)
The stack traces will probably improve in due course.
When built with the ghcdebug flag and started with --debug=-1 (or -2
to pause at startup, or -3 to pause before exit), hledger can be
controlled by ghc-debug clients like ghc-debug-brick or a custom
ghc-debug query script.
Also, refactor version string code.
Changes:
1. rename the sandstorm "manage" permission to "edit"
(old permission names: view, add, manage;
new permission names: view, add, edit).
Rationale: "edit" best describes this permission's current powers, to users and to operators.
If we ever added more manager-type features we'd want that to be a new permission,
not a rename of the existing one (which would change the powers of existing users).
2. rename the sandstorm roles for consistency with permissions
(old role names: viewer, editor, manager;
new role names: viewer, adder, editor)
Rationale: it's needed to avoid confusion.
3. add a new option: --allow=view|add|edit|sandstorm (default: add).
'sandstorm' sets permissions according to the X-Sandstorm-Permissions header.
Drop the --capabilities and --capabilities-header options.
Rationale: it's simpler and more intuitive.
4. replace "capability" with "permission" in ui/docs/code.
Rationale: consistent with the above, more familiar.
