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.
When running `cd hledger-lib && ghci test/unittest.hs`, ghci complains
with:
```
test/unittest.hs:7:1: error:
Could not find module ‘Hledger’
It is not a module in the current program, or in any known package.
|
7 | import "hledger-lib" Hledger (tests_Hledger)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.
```
This commit removes the "hledger-lib" package-qualified import, such
that above ghci command works as expected.
However, there is a comment in hledger-lib/test/unittest.hs that says:
> package-qualified import to avoid cabal missing-home-modules warning
> (and double-building ?)
The missing-home-modules warning and the double building can indeed be
reproduced by running (after removing the "hledger-lib"
package-qualified import): `cd hledger-lib && cabal build unittest`. It
will first build `hledger-lib`, then show a warning about
missing-home-modules, and then build `hledger-lib` again.
After comparing the unittest sections of hledger.cabal and
hledger-lib.cabal, the solution turned out to be to remove `./` from
hs-source-dirs for unittest. Don't ask me why though!
Overall it's a nice cleanup.
Previously, hledger could read CSV files containing non-ascii
characters only if they are UTF8-encoded. Now there is a new CSV
rule, encoding ENCODING, which allows reading CSV files with other
encodings.
This adds a dependency on the encoding library, which supports fewer
encodings than text-icu but does not require a third-party C library.
To avoid build issues on various platforms, we require version 0.10+.
This adds some use of the ImplicitParams language extension, required
by encoding's API, but only in a small code region.
This also changes the type of Reader's rReadFn; it now takes
a `Handle` rather than a `Text`, allowing more flexibility.
Hledger.Utils.IO's ansi style/color helpers now respect --color=yes,
so that eg `hledger --color=yes | less -R` shows bold headings as
you'd expect.
Hledger.Utils.IO.rgb' now takes Float arguments instead of Word8.
This fixes the error displayed when quitting the pager with long output.
It also replaces the pager lib with more robust homegrown pager utilities,
which should prevent a number of failure modes.
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.
CSV rules files can now be read directly, eg you have the option of
writing `hledger -f foo.csv.rules CMD`. By default this will read data
from foo.csv in the same directory. But you can also specify a
different data file with a new `source FILE` rule. This has some
convenience features:
- If the data file does not exist, it is treated as empty, not an
error.
- If FILE is a relative path, it is relative to the rules file's
directory. If it is just a file name with no path, it is relative
to ~/Downloads/.
- If FILE is a glob pattern, the most recently modified matched file
is used.
This helps remove some of the busywork of managing CSV downloads.
Most of your financial institutions's default CSV filenames are
different and can be recognised by a glob pattern. So you can put a
rule like `source Checking1*.csv` in foo-checking.csv.rules,
periodically download CSV from Foo's website accepting your browser's
defaults, and then run `hledger import checking.csv.rules` to import
any new transactions. The next time, if you have done no cleanup, your
browser will probably save it as something like Checking1-2.csv, and
hledger will still see that because of the * wild card. You can choose
whether to delete CSVs after import, or keep them for a while as
temporary backups, or archive them somewhere.
