![Mistletoe logo](logo.png) # Mistletoe (WIP) - the Polyglot Kubernetes Package Manager [Site](https://mistletoe.dev/) | [Blog](https://mistletoe.dev/blog/) | [Book](https://mistletoe.dev/book/) **Mistletoe** is a Kubernetes package manager that goes about things in a different way than the rest of the ecosystem. It's built around a runtime where the packages are **WebAssembly** modules: ```rust mistletoe_package! {" name: namespace-example labels: mistletoe.dev/group: mistletoe-examples "} #[derive(Deserialize)] pub struct Inputs { name: String, } pub fn generate(inputs: Inputs) -> MistResult { let name = inputs.name; let output = MistOutput::new() .with_file("namespace.yaml".to_string(), formatdoc!(" apiVersion: v1 kind: Namespace metadata: name: {name} ")); Ok(output) } ``` **The above is a simple package written in Rust. If you run it with:** ```sh mistctl generate my-namespace -p mistletoe/examples/namespace-example:0.1.2 ``` **You get the following YAML back:** ```yaml apiVersion: v1 kind: Namespace metadata: name: my-namespace ``` This is one of a nearly-unlimited number of ways to write a package. ***All you need is a language with a YAML parser that can compile to WebAssembly.*** # Roadmap **Mistletoe** is still very early on in the development lifecycle, but we've made some progress! As of note, we've implemented the **registry system** that's used by the above example -- you can add registries by Git URL and reference packages inside them by name now! There's also a default ***"mistletoe"*** registry added that points to [mistletoe-registry](https://github.com/gsfraley/mistletoe-registry). There's only the example package up now, but more will be coming soon! That said, there are still a handful of things that need to be addressed before it could reasonably be opened up for use: 1. The `mistctl` utility currently only supports YAML generation -- it should be expanded to **support installation to clusters.** This also implies all the usual goodies around lifecycle management, notably upgrades and uninstallation. 2. **Need documentation, documentation, and more documentation.** The only way to guarantee adoption is to provide best-in-class documentation covering everything from general usage, to package development in multiple languages, to the nitty-gritty advanced information about the runtime for eager hackers. There's all that, as well as a number of less-important, but also-desired efforts worth evaluating: 1. **Dynamic dependencies!** We can get a lot more value by adding a way for packages to declare and call dependencies outside of whatever is compiled into the package. This gets really useful when you consider #3 below. 2. **Explicit support for other languages.** While any WebAssembly-ready language will work, the project is written in Rust and provides Rust-first tooling. For the next push, I'm looking to expand library support to TypeScript via the [QuickJS runtime](https://bellard.org/quickjs/). 3. Since the runtime is pretty open, we could theoretically **package other package managers.** This means we could provide a system to install Helm packages as if they were any other Mistletoe package. 4. We could use some **package templates.** The templating engine in Helm is a blessing and a curse -- it makes generating manifests pretty easy, but tends to get really overcomplicated really quickly depending on what logic is entailed in deploying the system. **Mistletoe** addresses the curse pretty well, but we should provide some easy-build package templates to recreate the blessing.