Support user-specific configs

[sellout]

These are just preliminary thoughts

There could be six ways to configure Project Manager (top is the most general):

flowchart BT

project --> defaults
pu["project user"] --> project
hpg["host path glob"] --> defaults
upg["user@host path glob"] --> hpg
wt["working tree"] --> pu
wt --> upg

Loading

• defaults is just what is built into Project Manager itself, all the module defaults. These apply everywhere and is already supported.
• project is configuration committed to the repo (by default this is in $PROJECT_ROOT/.config/project/, and this is already supported).
• working tree is specific to the particular working tree it’s in. This isn’t yet supported. It could default to $PROJECT_ROOT/.config/project/local/ and should not be committed. This is probably the next most useful case.
• project user is specific to a user & a project. This isn’t yet supported. It should be committed and would ideally just be conditionalized config within project, but maybe just stored in like $PROJECT_ROOT/.config/project/user/$VCS_USER/ (where VCS_USER is some VCS-specific identifier, like git config user.email). If a user prefers to not commit their configuration, this can generally be approximated with either working tree or user@host path glob configurations.
• path glob (host & user@host) is a pretty flexible last case (that isn’t yet supported). It should be stored in /etc/project-manager/ or $XDG_CONFIG_HOME/project-manager/, respectively. It applies its configuration based on the working tree directory, relative to HOME. It mostly subsumes working tree, but with some tradeoffs. E.g., a key of "Projects/personal/some-project" would exactly match that one project directory (same as working tree in that project directory), while "Projects/personal/**" would match projects at any depth in $HOME/Projects/personal/. Other patterns like "**/some-project would match project directories with that name at any location (within the user’s home directory), and "**" applies as broadly as possible. The tradeoffs with working tree are that path glob can match multiple working trees and the configuration is resilient to deleting and re-creating the working tree, but the configuration isn’t stored with the project and user@host path glob does not play well with working trees that are shared by multiple users (which is why the paths are relative to home, and why host path glob exists – but host path glob has permission complexities). And another benefit over working tree is that path glob can easily be added to a NixOS, nix-darwin, or Home Manager configuration that is shared between hosts (which can approximate an uncommitted project user config, as alluded to above).

Comparing to Git scopes:

• defaults is akin to Git’s defaults,
• working tree is akin to --worktree (or --local),
• user@host path glob is akin to --global,
• host path glob is akin to --system, and
• project & project user have no equivalent in Git scopes, as Git explicitly tries to prevent you from committing configuration.

[sellout]

There also need to be options to project-manager in order to:

• run only with committed configs (defaults, project, and project user)
• run without any user configs (defaults and project)
• run “as” another user (defaults and project, plus project user of some named user)

These are useful for narrowing down where various hard-to-reproduce failures come from – reducing “works on my machine”.