Config Location

[runeimp]

Love the concept of this program. The one aspect that struck me odd though was that there was only one location to store the config. Granted it is a completely reasonable location and it should work for most of your potential users that only have one large project to manage. But I had these additional thoughts that I hope may be a consideration.

1. ~/.local/localstatus.toml for a config that is unique to that machine for the user. Some merging possibilities:
   1. Don't merge. Just prefer ~/.local/localstatus.toml over ~/.config/localstatus.toml
   2. Merge treating ~/.config settings as defaults but only if it's allowed by a setting in ~/.local
   3. Merge automatically treating ~/.config settings as defaults
2. /path/to/project_name/.local/localstatus.toml for when you have multiple large and disparate projects that share almost nothing on any given machine but are scattered across machines in different distributions and may have incompatible needs with one or more local projects

Benefits for number 1

1. Safest, no accidental settings contamination possible
2. Safety managed, accidental settings contamination less likely
3. Should be safe as long as the settings don't get too complex

Safety is a relative concept as I don't believe anything your tool does is potentially destructive. So safety is a concept of settings for one project being incompatible with another project on the same machine. Something that is highly unlikely to happen for many devs but is a definite possibility. For instance many projects on the same machine may reference the same environment variables. Checking only system environment variables may not be good enough as some projects may use .env files or similar tools to make the project environment unique for itself.

Example for number 2

• MachineA has ProjectA and ProjectB
• MachineB has ProjectB, ProjectC, and ProjectD
• MachineC has ProjectA, ProjectD, ProjectE, and ProjectF

Benefits of number 2

• May be much easier to keep the config local to the project instead of the local or network user account
• Updated config changes could be updated in each project with a simple git pull or what have you
• Running localstatus in a project would not give you errors for things not related to that specific project

[tylermumford]

Thank you for taking the time to provide such a thoughtful discussion. I completely agree; having only one config location is a pretty big limitation. I fully intend to support more config locations, especially per-repo configs.

The exact implementation of this is going to require some thought, so I'm glad you've provided this. I'll leave this issue open until this is implemented somehow.