Repository navigation
Project level default configuration should be possible without user intervention #2194
Description
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.
Activity
simonmichael commentedon Apr 10, 2024
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
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 ?
[-]Project level defeault configuration should be possible without user intervention[/-][+]Project level default configuration should be possible without user intervention[/+]simonmichael commentedon Apr 10, 2024
Brainstorming more alternatives:
*.hledger,*.journal,*.ledgeror*.jfile in the current directory or above (if LEDGER_FILE is unset ?).alerque commentedon Apr 10, 2024
Using hledger as a shebang is an interesting idea. In fact it already works!
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_FILEis 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.hledgeror.hledgeror 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 viainclude real_main_file.ledgeror whatever.simonmichael commentedon Apr 12, 2024
How about (ignoring parent directories for now since this is complicated enough):
(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
addand hledger-web add form. .hledger could also be a symlink, avoiding that problem.)[Edit:
the latest non-future year journals (
./YYYY*.{hledger,journal,ledger,j})or any journals (
./*.{hledger,journal,ledger,j})(or other supported formats too ?)
NEW
]
simonmichael commentedon Apr 12, 2024
pwseo commentedon Jun 10, 2024
I think option no. 3 is a good one: one can always symlink
.hledgerto point it to their main journal file (and in filesystems with no support for symlinks, a simpleinclude main.journalwould 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.journalfiles, easily). They're an interesting addition, I'm just not sure they're actually worth the effort at this stage.simonmichael commentedon Sep 13, 2024
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.
reesericci commentedon Jan 7, 2026
Is it possible to set LEDGER_FILE with the config file as described in this issue? I can't find a way to make it work.
simonmichael commentedon Jan 7, 2026
.in your PATH so that ahledgerscript in the current directory will be preferredmakeorjustfile that runs hledger appropriately