--You received this message because you are subscribed to the Google Groups "hledger" group.To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/f1175a8c-3495-4156-b048-ea2339d5dbd5%40app.fastmail.com.
And here are two more which have been held back, as they might be too controversial:3. Move the balance assertions check to --strict mode (ie, don't check them by default).4. Move the ordereddates check to --strict mode, and check it before balance assertions.
In principle, the question of what does and doesn't belong in strict mode seems more like a per-journal (or per-user) one than a global one. I'm not sure if it's feasible, but I can easily imagine having each journal (or user) indicate the set of optional checks that it's committing to. Presumably with a cli override along the lines of -I.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/a9b8aa61-6a47-44cb-b178-e1d4d574dbe7%40app.fastmail.com.
In particular I'd like to poll hledger users:How would you feel about balance assertions being checked only in strict mode, not by default ?How would you feel about ordereddates being added to strict mode ?
Still another possibility:How would you feel about ordereddates being added to the default checks, like assertions ? Possibly with a flag to disable it, like --ignore-assertions.
--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/15f2dec2-b6b3-48f5-b7ff-eb65186f7fdf%40app.fastmail.com.
--
You received this message because you are subscribed to the Google Groups "hledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hledger+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hledger/f1175a8c-3495-4156-b048-ea2339d5dbd5%40app.fastmail.com.
On ordereddates being on by default, with an option to disable it: I am indifferent, as long as there is a way to disable this (and just this) check. Why I would disable it: because in my "manual entries" journal I group transactions into sections, and while each section is ordered by date, the whole file overall is not (and I am not keen to split it into several files, because I will have to create 5-7 small files for every year I have records for, which seems counterproductive)
On balances not being checked by default: it will not be hard for me to run "hledger check balances -f ..." every time I generate reports (assuming that "hledger check balances" will do the same set of checks that happens now to check that transactions are balanced). However, I am going to be sad overall. Why:
a)I will now have to run "hledger check balances -f ..." for every file, which will roughly double the amount of hledger invocations I do.
This can be alleviated with global or per-user config, or maybe even per-file config,
b)This violates the rule of least surprise in a big way, I think. If I write "= $124" in the journal, and this is called "balance assertion" by the docs, I would not expect it to be an ... aspirational note, to be checked at some point later, or not at all. I would've expected it to be enforced, in the same way "transaction is balanced" is enforced.
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.
Thanks for your input, all.On Sun, Apr 28, 2024, at 02:06, Dmytro Astapov wrote:On ordereddates being on by default, with an option to disable it: I am indifferent, as long as there is a way to disable this (and just this) check. Why I would disable it: because in my "manual entries" journal I group transactions into sections, and while each section is ordered by date, the whole file overall is not (and I am not keen to split it into several files, because I will have to create 5-7 small files for every year I have records for, which seems counterproductive)If ordereddates moved into strict mode, it becomes a bit harder to avoid. Dmytro, do you use --strict currently ? Would ordereddates in strict mode affect you ?
On balances not being checked by default: it will not be hard for me to run "hledger check balances -f ..." every time I generate reports (assuming that "hledger check balances" will do the same set of checks that happens now to check that transactions are balanced). However, I am going to be sad overall. Why:hledger check assertions - yes, that's equivalent to the the parseable / balanced transactions / assertions checks that currently happen by default.a)I will now have to run "hledger check balances -f ..." for every file, which will roughly double the amount of hledger invocations I do.It shouldn't require extra invocations, it would "just" require you use -s (strict mode). (Which would mean also satisfying accounts, commodities, more explicitly balanced transactions, and possibly ordereddates checks.)
This can be alleviated with global or per-user config, or maybe even per-file config,Re per-file strictness configuration: having thought about it a little more, I think there would be complexities, and quite possibly the kind that are hard to discover in a timely manner, and I'm not going to pursue it. But if someone else wants to, I'd be glad to help test it.b)This violates the rule of least surprise in a big way, I think. If I write "= $124" in the journal, and this is called "balance assertion" by the docs, I would not expect it to be an ... aspirational note, to be checked at some point later, or not at all. I would've expected it to be enforced, in the same way "transaction is balanced" is enforced.My thinking was that by default it is in forgiving edit mode, letting you get things in order, and maybe do casual reporting when you are confident in your data, but everyone would know that when you are doing serious reporting and want assurances, you turn on strict mode. I feel that would be pretty intuitive, since you add -s and get a bunch of new failures, you fix them all at once, and you feel good about strict mode.But I know we are all used to balance assertions being on by default. And even though we have top-notch correctness checks in hledger, this change of default could look like hledger "weakening correctness checks" which isn't good.To go back to the/my original problem, I think it's that
- As an ordereddates user I want ordereddates checked before assertions for more useful errors
- Everyone expects assertions to be always checked
- Only some of us want ordereddates checked (I don't know how many, and we are biased by the designhistory)
- It's awkward to have an optional, low priority check performed before a default, high priority check.
The majority of responders so far don't seem too worried about any of the changes I proposed. But - unless my answers above changed your thinking - 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.