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.
Moved from Hledger.Utils.Debug to Hledger.Utils.Print:
pshow
pshow'
pprint
pprint'
colorOption
useColorOnStdout
useColorOnStderr
outputFileOption
hasOutputFile
dlog has been replaced by more reliable functions for debug-logging
to a file, useful for debugging TUI apps like hledger-ui:
dlogTrace
dlogTraceAt
dlogAt
dlog0
dlog1
dlog2
dlog3
dlog4
dlog5
dlog6
dlog7
dlog8
dlog9
Monochrome pprint' and pshow' have been added.
New dependency: deepseq
May also fix#1154, #1033, #708, #536, #73: testing is needed.
This aims to solve all problems where misconfigured locales lead to
parsers failing on utf8-encoded data. This should hopefully avoid
encoding issues, but since it fundamentally alters how encoding is dealt
with it may lead to unexpected outcomes. Widespread testing on a number
of different platforms would be useful.
And remove the last vestiges of older more complex behaviour.
ordereddates now always checks all transactions in each file,
unaffected by a query. (But still affected by --date2).
Hledger.Data.Balancing.
Both Hledger.Data.Transaction and Hledger.Data.Journal are massive
module with many things in them. Placing the balancing functions, which
are conceptually related, into a separate module helps keep things more
modular.
It also reduces the risk of import cycles, as right now balancing
functions cannot depend on any functions defined outside of
Hledger.Data.Transaction or Hledger.Data.Journal, respectively, if those
modules require basic transaction or journal functions.
There are no modules which depend on Hledger.Data.Commodity which don't
also depend on Hledger.Data.Amount. Though Hledger.Data.Amount is a very
large module and might be broken up, Hledger.Data.Commodity only defines
three very small functions which are used, and so can be combined with
little cost.
POSIXTime.
This eliminates old-time, which has been deprecated for a while, from
our dependencies.
This introduces a slight incompatibility, as a small number of functions
now take/return POSIXTime instead of ClockTime. Generally you will be
using the current time, in which case you should use getPOSIXTime from
Data.Time.Clock.POSIX instead of getClockTime.
utcTimeToClockTime has been removed, as it is now equivalent to
utcTimeToPOSIXSeconds from Data.Time.Clock.POSIX.
We officially support GHC 8.6+ (and 8.8+ for hledger-web) now.
Hackage matrix builder shows all packages building successfully
with GHC 8.4+, somehow, so we'll adjust the base bound to
allow that but prevent any attempts to build with older GHCs,
functions to AccountTransactionsReport.
If you use transactionsReport, you should either use entryReport if you
don't require a running total, or using accountTransactionsReport with
thisacctq as Any or None (depending on what you want included in the
running total).
Prior to this commit,
- hledger still builds with GHC 8.0
- hledger-ui does if you use the build plan specified by stack8.0.yaml,
but you are likely to hit problems if you let cabal pick one
(https://github.com/jtdaugherty/vty/issues/198 and others)
- hledger-web might, if you could find the right build plan
The hassles are enough and GHC 8.0 is old enough (first released in
2016) that I'm letting it go; 8.2 is the new minimum version for all
hledger packages.
This allows a bunch of cleanups to conditional imports, which I leave
for later.
Also, updated the tested-with minor versions.
Decimal 0.5.1+ changed to banker's rounding (round to nearest even
number), and math-functions 0.3.3.0 (used by roi) fixed various
precision-related issues. Now we require the latest versions of these.
This was causing some functional test failures when building with old
GHCs/snapshots.
