My thinking is that there are multiple plugins, so that they can be used by companies AND third parties to (for example) support installation of development environments for particular languages, etc.
During installation you could define a list of plugins. Each plugin can either be a script URL or a GitHub repo. For example:
export OMARCHY_PLUGINS=andyjeffries/omarchy,basecamp/internal,https://omarchy.example.com/install
wget -qO- https://omarchy.org/install | bashThe Omarchy install will, after installing itself normally, loop through each plugin effectively doing the following:
- If it's a URL then download and execute it
- If it's a public GitHub repo then clone it locally to a known plugin folder
- If it's a private GitHub repo (i.e. failed to clone it as public), ask for the username/password or SSH private key location (which can be copied to
~/.ssh/and then clone it locally to a known plugin folder
I believe Omarchy installs to ~/.local/share/omarchy/, so as that's already a Git repo, rather than potentially have uncommitted changes or subrepository voodoo, maybe plugins are installed to ~/.local/share/omarchy-plugins/ in the format ~/.local/share/omarchy/PROVIDER/REPO.
Upon initial install it should simply follow the mechanism of looping through each PROVIDER/REPO, within it finding all migration/*.sh file, executing them and updating some config file to say the last version executed for each plugin.
Then also upon doing an Omarchy update, it can do the same thing it does for Omarchy - run back through each PROVIDER/REPO, pull changes and run any not-yet-run migrations.
That feels fairly consistent with the way Omarchy runs (I believe, but correct me if I'm wrong), allows for independent developers to hook in to install company-specific stuff or multiple layers on top.
It explicitly doesn't cover dependencies between plugins, for future consideration.