RFC: correctness checks, ordereddates, balance assertions [hledger]

General
1

Cc'ing from the hledger mail list:

Here are some recent changes in master, let me know if you have concerns:

  1. The order in which correctness checks are performed is now documented, and tweaked: commodities are now checked before accounts, and tags are now checked before ordereddates. (The order is relevant because we show only the first failure.)

  2. ordereddates now ignores --date2 and secondary dates; it checks primary dates only (simplifying internals and UX).

And here are two more which have been held back, as they might be too controversial:

  1. Move the balance assertions check to --strict mode (ie, don't check them by default).

  2. Move the ordereddates check to --strict mode, and check it before balance assertions.

In other words, emphasise ordereddates a bit more and balance assertions a bit less.

This might be a bad idea. Some possible benefits:

  • My main goal was to get ordereddates failure reported before balance assertions failure. When I get a failing balance assertion during data entry it's often because I copy-pasted an old transaction without updating the date, and it would be more useful to see the ordereddates error, pointing me directly at the cause.

  • Moving them both to strict mode allows the checks to still be explained as a nice linear sequence, with the most basic/useful checks coming first.

  • Also, balance assertions fairly often get in the way, forcing you to run commands again with -I. Eg when you want to run reports to troubleshoot problems during data entry, or when you are piping hledger print output to a second hledger command.

  • ordereddates is IMHO a useful check with no major downsides. If you want to keep some entries outside the overall date order you can always move them to their own file. It would be ok to be a little less flexible and a little more opinionated on best practice here.

And costs:

  • hledger would do less correctness checking by default. Now unless you use -s/--strict, you could see and use report output without realising you have failing balance assertions. This cuts both ways.

  • The meaning of -s/--strict changes. To start using it, or keep using it, you'd now also need to conform to ordereddates. (Or use a backward compatibility flag, or use 'hledger check' instead.)

There are other ways to get some of these benefits.. though I haven't found any quite as straightforward.

1 Like
2

I appreciate the new order!

3

In particular I'd like to poll hledger users:

  1. How would you feel about balance assertions being checked only in strict mode, not by default ?

  2. How would you feel about ordereddates being added to strict mode ?

4

Another possibility:

  1. How would you feel about ordereddates being added to the default checks, like assertions ? Possibly with a flag to disable it, like --ignore-assertions.
5

I always run hledger in strict mode with all extra checks enabled except for uniqueleafnames so I guess it wouldn’t make a difference to me, but it would be surprising for balance assertions to be ignored outside of strict mode.

ordereddates being enabled by default in strict mode seems logical. It may be overkill for the default checks, though.

1 Like
6

Thanks for the input all. Latest update: https://groups.google.com/g/hledger/c/8bqkD13BqnQ/m/steriPRzBAAJ

7

This seems resolved for now:

On Wed, May 1, 2024, at 20:16, Simon Michael wrote:

I guess it'll be the least disruptive path: keep assertions and ordereddates checks where they are, and just add an inelegant special case so that when ordereddates are enabled they get checked early, ahead of assertions.

I've pushed this to master (along with some updated check docs).

TLDR: I deployed a kludge to prioritise ordereddates errors above balance assertion errors, but it shouldn't disrupt anyone; let me know if you see any issues.

1 Like