Project level default configuration should be possible without user intervention

[alerque]

I've seen #1013 and that covers some of my issue, but the scope is still not right, so here I am...

I've just setup a couple more projects using plain text accounting and am now pretty aggravated with needing different commands for the same workflow in different projects.

Out of the box hledger has a user oriented scope. It assumes that the user is going to be doing one thing with their journals no matter where they call it from. This is strongly reflected in the LEDGER_FILE default walue that is relative to the $HOME directory. Instead of using the current directory and moving up the tree looking for a project root, then eventually stopping on the user directory if reached, it jumps straight to taking it's queues from the $USER. This might be convenient for some folks, but not for me. All my PTA projects are in specific directories and tracked as Git repositories.

When you run git diff, you expect it to operate in the current project, using setting first from .git/config and then falling back to ~/.gitconfig and /etc/.... I have some project with specific filters that help process files into a format that can be diffed, e.g. for diffing binary file types using speciall tooling. It doesn't matter what project I clone or what system I do it on, git diff comes ready to run for that project.

Not so with hledger that at the very least needs to have a file name specified via -f. I tried for a while to try to keep the main entry point ledger for all projects named the same thing so I could alias hledger='hledger -f main.ledger', but working with projects in other languages that has proved unattainable. There are solutions such as .env files and various utilities to load environment variables per project, but this requires all users of the project to use the same tooling in their shell (and that typically affects other projects). I've event tried setting up all projects with similar arg file sets, but again this just doesn't always work out.

It would be really nice if there was some file that could be placed in a project that would be found by ledger to at least set a default LEDGER_FILE. Perhaps this could be a default args file that is read that could include -f=filename.ledger perhaps other args.

[simonmichael]

I hear you @alerque. That's true, hledger currently prioritises ease of working with "user's journal", not a project-scoped journal. The latter is a more advanced use case for technical users, but perhaps adding more support for it would not disturb the former.

Let's not if we don't need to though. So alternatives include

• 1013's shell one-liner that emulates config file support

• Using a consistent journal file name across projects, and aliasing "hledger -f main.ledger" or setting LEDGER_FILE to "main.ledger"
• Automatically setting LEDGER_FILE in project directories, using direnv or similar

It sounds like these aren't working for you because you want this feature usable by others (not just yourself) and they are all too much overhead ?

[simonmichael]

Brainstorming more alternatives:

• Add the hledger command as a shebang line in project journals so they can be accessed uniformly by executing them
• Add some heuristic to hledger that prioritises a local journal file, without configuration. Eg, use the alphabetically first (and if the file names begin with YYYY, prefer the current, otherwise the latest, year) *.hledger, *.journal, *.ledger or *.j file in the current directory or above (if LEDGER_FILE is unset ?).

[alerque]

Using hledger as a shebang is an interesting idea. In fact it already works!

#!/usr/bin/env -S hledger -f

The caveat of course is that you have to set an executable bit on a data file. Given the file may import un-escaped data that gets saved via a web API it seems a bit sketchy.

My suggestion would be to have some default ledger file read from the CWD provided LEDGER_FILE is not set. This wouldn't need to be variable like an alphabetical first match, just a fixed name that could serve as a place to import other files if necessary: default.hledger or .hledger or something of that nature... that could be excused in a non-english project where the actual data file might have a different name and is just pulled in via include real_main_file.ledger or whatever.

[simonmichael]

How about (ignoring parent directories for now since this is complicated enough):

1. use -f FILE if specified
2. or $LEDGER_FILE if set
3. or ./.hledger if it exists # NEW
4. or alphanumerically first of ./THISYEAR*.{hledger,journal,ledger,j} # NEW
5. or alphanumerically first of ./LATESTPREVYEAR*.{hledger,journal,ledger,j} # NEW
6. or alphanumerically first of ./*.{hledger,journal,ledger,j} # NEW
7. or $HOME/.hledger.journal

(There is a slight cost to adding a top-level including file: the top-level AKA primary file gets some special treatment, like being the default target for add and hledger-web add form. .hledger could also be a symlink, avoiding that problem.)

[Edit:

1. use -f FILE if specified
2. or $LEDGER_FILE if set
3. or ./.hledger{,.EXT} if it exists. (Optional extension allows it to be any hledger format, not just journal ?) NEW
4. or alphanumerically first of the latest non-future year journals (./YYYY*.{hledger,journal,ledger,j}) or any journals (./*.{hledger,journal,ledger,j}) (or other supported formats too ?) NEW
5. or $HOME/.hledger.journal

]

[simonmichael]

I usually regret and roll back these over clever heuristics because they're unpredictable, but maybe it would be mostly harmless here:

1, 2 and 7 are as before, and predictable.

3 is new, predictable, and would solve your wish. It's a normal hledger journal so wouldn't cause too much chaos (just loading the wrong file, if you forget it's there, because it's hidden).

4, 5 and 6 (really just 4: fancy file name search) are new and would solve my wish (zero config detection of obvious journal files in the current directory). This would change the behaviour only if you have avoided using 1-3 and there's a detectable journal file in the current directory.

If needed we could add informational output for some or all cases to show which file it's choosing.

[pwseo]

I think option no. 3 is a good one: one can always symlink .hledger to point it to their main journal file (and in filesystems with no support for symlinks, a simple include main.journal would suffice).

While all the other additional options presented (4..7) are nice additions, they don't seem to bring as much value as option no. 3, since it largely depends on the user's journal/directory organization (eg. one can have YYYY/bank-MM.journal files, easily). They're an interesting addition, I'm just not sure they're actually worth the effort at this stage.

[simonmichael]

https://hledger.org/dev/hledger.html#config-files support (#1013) was shipped in hledger 1.40, including project-level configuration, so I'll close this. Testing and feedback is welcome.