-
Notifications
You must be signed in to change notification settings - Fork 123
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
Override config path #141
Override config path #141
Conversation
If the logic around the flag moves into |
927fc78
to
26d1599
Compare
Yeah,
(I'm not yet 100% sure if we should include the cache dir, or the pages dir instead. Maybe the latter would be better?) What do you think? If we have that, we could probably re-purpose (Docs would need to be updated as well.) |
Yeah, |
By the way, why not just |
I guess that would work too and be easier to type 😄 |
See #162! If you agree with that, the config directory should be returned together with |
aa8bfec
to
1bc8bb0
Compare
1bc8bb0
to
8f1b669
Compare
8f1b669
to
11394c7
Compare
@dbrgn I started fresh with implementing this again and I was wondering what variable the flag should target here. In the old implementation (which I left in as a commit for reference) I had it so that if the given path was a directory, the config directory would be overridden and otherwise it would be just the config file location. Right now, I only implemented file overrides for the exact location, because I find the old logic a bit unintuitive by now 😄 If I had to decide which of the two I would want a flag for, I would choose the directory, because then the config path would be relative to that too and future tealdeer files would not have to get their own override flag. However, this can already be done with the environment variable and would not allow to name the tealdeer config file anything other than Maybe this should really be a new environment variable What do you think is best to do here? |
I wouldn't implement any file-or-dir detection. Either the user should specify the file path, or the directory path. Other logic could be confusing and would make maintenance harder.
Yep, I agree. I would rather specify the config file. The reasoning why the main config file should be "special" over other potential config files is that everything else can be configured from within the config file, but not the config file path itself. I think that env vars like With a file path (vs a dir path) we could also in theory implement support for reading the config from stdin, or from any other file-like object. My suggestion: A parameter |
(this is currently waiting until #212 is done to make a design choice here) |
This PR is wildly out of date, a fresh start is probably easier at this point |
Closes #107
This is a first sketch that satisfies the requested behavior.
However, I would like to move the logic into
get_config_path
, so thatall the other config file related functions use the flag as well.
I (for now) decided, that the program should exit, if the given path is not a
file, instead of falling back to a default configuration.
Furthermore, I think there is some work around the naming of all the flags.
I think, that the most appropriate name for this new flag would be
--config-path
, which is already taken though. In my opinion, there shouldbe something like
--show-config-path
for that, but this renaming (if desired)can also wait until there are other (or more significant) breaking changes.
Let me know what you think!