Much better version coming soon.

Mason is a plugin framework for statically compiled Go. Plugin systems are messy. Inversion of control is messy. This Go module was named after stone masons because it aims to provide a simplistic API for constructing application pyramids.

go get -u github.com/pedregon/mason/v2

There may be better examples in a future revision, but for now check out TestModules or TestMortar.

The recommended design pattern for plugin registration is to mimic database/sql with anonymous package imports as the plugin discovery mechanism. Build tags may also be used for compile-time inclusivity.

Mason was developed to offer an alternative to the Go standard library, plugin, RPC solutions such as github.com/hashicorp/go-plugin, and network-based solutions. Mason works by constructing Scaffold(ing) to apply Mortar on Stone from Module(s). On Module load, Scaffold creates a Context for hooking API logic. Module(s) are hooked by the Context and provide Stone as building blocks that extend the API. Mason takes care of the plugin dependency plumbing and empowers custom discovery, registration, and hooking. Mortar is the underlying glue. Initially, github.com/uber/fx was first-class supported as the inversion of control mechanism because it was arguably the best documented and easiest to use (no code generation or type inferring) dependency injection framework, but it has since been decided that a) users do not want to be forcibly dependent on an external library and b) some consider dependency injection systems to be an unnecessary anti-pattern. Therefore, to remain idiomatic, Mortar inversion of control via Stone hooking was abstracted. Context, itself, even implements the Mortar interface to foster chain of responsibility. Mason by no means claims to be a perfect solution, and is open to feedback!

This project is open to pull requests! For discussions, submit an issue. Please sign Git commits and adhere to official Go module versioning when publishing. Version 1 is deprecated.