-
Notifications
You must be signed in to change notification settings - Fork 9
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" foo
This builds me a foo
launcher.
cola meta init-package --dropin --launcher foo PACKAGENAME
or
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 PACKAGEDIR
Will 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 PACKAGEDIR
Lints 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 meta
can build the full web structure necessary to serve launcher updates and packages - Something under
foo meta
can 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.