config.yaml should not be searched based on the current directory.

[jkbecker]

There should be a central location for config.yaml (see this discussion).

I'm making this issue mostly because @altendky suggested I split this feature off of #61.

[ericaltendorf]

I'm not sure how you want to group things here, but it sounds like we want

• A default location (like ~/.plotman.yaml? ~/.plotman/config.yaml?)
• A way to create such a default config
• A way to override the config file location on the command line (useful if you're plotting as a service for others, or if you're benchmarking and doing testing with different config settings)

[altendky]

Sounds right to me.

IIRC @jkbecker suggested appdirs. I haven't used it but it is what I would reach for. It would use ~/.config/plotman/ for config on Linux, for example, and the appropriate locations on other OS.

https://pypi.org/project/appdirs/

[jkbecker]

appdirs gives you good default locations for config files, as well as logfiles.
I would definitely implement it in a way that allows for the search path to be extended + overridden, i.e. by passing in optional arguments or setting an environment variable.
Also, plotman should maybe have a plotman config command which can print the logfile location to make it easier to find - that command should be sensitive to environment variables as well, so something like

> plotman config path
/home/chia/.config/plotman/config.yaml
> export PLOTMAN_CONFIG=/somewhere/else/plotman.yaml
> plotman config path
/somewhere/else/plotman.yaml
> plotman config info
FILE                                    TYPE              EXISTS   SCHEMA      ACTIVE´
/somewhere/else/plotman.yaml            $PLOTMAN_CONFIG   Yes      OK          Active
/home/chia/.config/plotman/config.yaml  default           Yes      OK          Inactive ($PLOTMAN_CONFIG override)
> plotman --config custom-config.yaml config path
/home/chia/custom-config.yaml
 > plotman --config custom-config.yaml config info
FILE                                    TYPE              EXISTS   SCHEMA      ACTIVE
/home/chia/custom-config.yaml           --config          Yes      ERROR       Active
/somewhere/else/plotman.yaml            $PLOTMAN_CONFIG   Yes      OK          Inactive (--config override)
/home/chia/.config/plotman/config.yaml  default           Yes      OK          Inactive (--config override)

Is this over-engineered?
I feel the same thing could be done for logfiles (appdirs also has defaults for that) - that would help a lot with the tons of support requests that result from a faulty logfile location in the config file.

One advantage of something like this would be that even though the config file is now in a hidden directory "somewhere", you can always edit it by going

vim `plotman config path`

(or your favorite text editor) without worrying about typing out the path.

[altendky]

The environment variable bit makes me think of having an env var for every cli option. I think Click has some helpers for that. But at least on a first pass of reading the ideas, I like them. Also made me wonder about overlay configs... Definitely a separate task there though. Maybe a config in the current directory should be considered somewhere in the priority list? plotman config edit could use $EDITOR and $VISUAL (Click's got something for that too). But, most of this is extra stuff that should be done separately, if it is done.

[jkbecker]

Maybe a config in the current directory should be considered somewhere in the priority list?

... on the one hand: yes, on the other hand... I expect chia to behave the same way no matter which directory I'm in, same as control applications, same as general status monitor-type applications such as glances or htop...

I fear that it could result in a lot of d'oh! moments when you set up your config and then move around just to find that next time you run it it's actually using a different config - just imagine being in ~/.chia/mainnet/config and running plotman and it loads the chia config as the plotman config for no good reason, just because they share the same file name... 😱

If the current directory is considered, plotman should explicitly print out the active config file on every command, to avoid confusion? But that feels noisy as well... I guess I'm fine with it because existing users will expect nothing else, but personally I'd like the env var option to be prioritized higher, such that I can set that and avoid loading a random config I didn't expect to be there.

Proposed prio order (DESC)

1. passed in command line argument
2. env var
3. cwd file -> should probably only respond to plotman.yaml or something in that case, to avoid the scenario I described above
4. canonical location according to appdirs

[altendky]

@jkbecker I agree with your concerns. I'm not certain that cwd should be checked. If I come up with a specific use case I'll share it and we can discuss possible solutions. If deemed appropriate, it can presumably be added in later without much more work than if it were included initially.

@coderasm yeah, that had been mentioned somewhere in some form. If you can't find a ticket then make one. I'm sort of split on it being a good thing. On the one hand I do stop and restart plotman regularly when I save the config. On the other, do I want plotman reloading it every time I stash my local config changes, pull an update from git (my own chia setup repo, not plotman), unstash my changes, and go make some manual updates? Not really. :]

Not that I've made out any plan or have specific expectations or anything, but in my head plotman is really primarily a thing that ought to be run as a service. Usually we will want it to start on boot, the process should be restarted if it crashes, etc. The TUI is then a monitor for the service. Services, afaik, don't reload config files on-write, generally. Though, I believe it is reasonable to reload on request without restarting if the code supports it. If a command is involved to request a configuration reload, it's probably just as well for the plotman process to just restart. Anyways, there are some vague off-the-cuff ramblings of my initial thoughts.