### What are the objectives and benefits of an extension framework? * It facilitates functional extensions tailored to specific users or domains. Finch remains extension-neutral, meaning these extensions can be managed by users independently, even privately. For instance, an enterprise user could develop a credential helper extension to seamlessly authenticate our company’s internal container registry. * It ensures Finch’s default installer’s size and boot time remains scalable by delegating non-core features (core/non-core scope can be always negotiated and changed based on community's consensus) like credential helpers, lazy pull, and image signing to extensions. * It enables users to deploy a minimal version of Finch based on specific use cases. For example, if a user solely wishes to build images and has stringent size requirements, container runtime and image builder could be two separate built-in plugins. The user could then select only the image builder built-in extension during installation. (Minor benefit comparing to the first two) ### What functionalities will the extension framework provide? The extension framework will furnish two key functionalities for each extension. These are not exclusive to extension types, and an extension can possess both: * Customized Provisioning: Users can devise personalized Finch VM provisioning scripts, such as configuring specific setups or installing packages from local archives. * Customized Commands: Users can add their own commands to the default command set, e.g., `finch my-command` or `finch image my-command`. The extension framework will do the comamnd conflict check error handling properly. (https://github.com/spf13/cobra/issues/691#issuecomment-652619429) * More functionalities... ### What will Finch look like after extension framework refactoring? Post-refactoring, Finch will comprise a barebone VM equipped with an extension loader, devoid of any real functionalities. Finch will load all extensions from a designated extension directory during booting. Core functionalities like pull, push, build, and run, (although the core/non-core scope is subject to change based on community consensus) will be restructured into built-in extensions. These will be included in the default Finch installer. Users could deselect them if they seek a more compact Finch sans unnecessary functionalities. The default Finch installer size will be the sum of the barebone Finch’s size and all the built-in extensions’ sizes. The existing non-core functionalities will be reconfigured into optional Finch-managed extensions. Some may even be contributed to third-party repositories if they tightly integrate with specific third-party tools. All other extensions are managed by users or third parties, and can be placed in the extension directory to be loaded by Finch.