Graduating Bootstrap from 'Collection of Scripts' to an 'Environment Manager'

Contrary to how I started bootstrap, it has outgrown the scope of a project that's just "a collection of scripts"

With changes like #16 (Three strategy install model) and procedural rollback implementation and #5 in the future, bootstrap is taking shape of declarative, distro agnostic environment manager.

Like a personal package manager that installs and tracks CLI tools, runtimes and system packages that a user relies on all behind a single audited registry.

To achieve this, bootstrap needs to do the following:

• #23

  • The CLI, planned async exec graph, registry.json engine, the plugin runtime, and the auth server integration remains as the Bootstrap Core (b)

  • The collection of base-only installers are yanked out of bootstrap into a Default Registry. These installers do not touch the ~/.config yet.

  • Personal Overlays (Taps): Personal dotfiles, aliases, and specific configurations become a separate repository. This is added as a "tap" (Borrowing from homebrew). Taps work pretty straightforward b tap add johndoe/bootstrap

    So when a user runs b install nvim, they get the base. If they want another person's exact setup they would need to add their tap and then install it

    b tap add johndoe/mybootstrap
    b johndoe/nvim-conf
    

    The specifics and UX is subject to revision.

• #24

  • We standardize installers to expose Targets (or Phases).

  • An installer should be a standard bash file that defines specific, named function. Bootstrap's CLI then parses these and allows the user to invoke them directly as well.

    b ware nvim:base|system-symlink
    this would install the base and system-symlink targets.

• #25

  • Instead of using the old installers/install_<toolname>.sh structure, use a tools/<toolname>/tool.sh scaffolding for registries.
  • Each tool gets its own namespace directory
  • Allows for per-tool extras: patches, hooks, etc

• Structured Documentation and basic wiki