-
Notifications
You must be signed in to change notification settings - Fork 11
Description
The vision here is that it becomes easy to get started, and that some things that require deep uderstanding of the documentation do not anymore.
This is roughly what I imagine:
I download a binary called cola (brew install, go install, etc). This will not be my launcher, but it is useful as a starting point to build other launchers and to do maintenance tasks.
I can then do this:
cola meta make-launcher --description "Foo Launcher" fooThis builds me a foo launcher.
cola meta init-package --dropin --launcher foo PACKAGENAMEor
foo meta init-package --drop-in PACKAGENAME
And it creates a scaffold of a (optional drop-in) package in the right place for the given launcher or the launcher that is running if no other launcher given.
foo meta build-package PACKAGEDIRWill build the package zip in a manner that is compatible with the launcher (I learned the hard way that some forms of valid zip file make the launcher unhappy)
foo meta check-package PACKAGEDIRLints the package: tells me if the manifest is correct, tells me if some of the binaries I have listed is not executable.
Wilder dream:
- Something under
foo metacan build the full web structure necessary to serve launcher updates and packages - Something under
foo metacan actually serve the contents
Is there an appetite for changes like this in the project? I came to this from having created some custom scripts for this when I built my homelab launcher. They served their purpose but were not general enough to be transferred to other launchers, so when I built a second and third launcher, I ended up having to rebuild or do tedious manual work. It could help to make this a first-class citizen.
The reason why I suggest bundling everything under a single group is to avoid cluttering the whole top-level namespace with more internal commands (I already believe there are too many).
If you are interested, we can discuss design, and I'm happy to (slowly) work on this.