New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Project level default configuration should be possible without user intervention #2194
Comments
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 ? |
Brainstorming more alternatives:
|
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 |
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 [Edit:
] |
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.
|
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 theLEDGER_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 couldalias 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 defaultLEDGER_FILE
. Perhaps this could be a default args file that is read that could include-f=filename.ledger
perhaps other args.The text was updated successfully, but these errors were encountered: