localstatus icon indicating copy to clipboard operation
localstatus copied to clipboard

Config Location

Open runeimp opened this issue 1 year ago • 1 comments

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

runeimp avatar May 06 '23 02:05 runeimp