search

svengeance / Husky

Modernizing the way developers think about installers
3 stars 0 forks source link

[Feature] Modularized API for Installer Phases #2

Closed svengeance closed 3 years ago

svengeance commented 4 years ago

Context

Provide an intelligent approach for putting together commands and modules

Elevator Pitch

One of Husky's primary selling points is extensibility. We should lay down a framework that is very modular in nature such that the application can offer new functionality in completely independent units. Installation modules that are too inherently tied together will make future work impossible to do. With a proper foundation, contributions can be made with confidence due to high testability.

Interested Users

Community contributors Developers

svengeance commented 3 years ago

This has been accomplished by extensive utilization of Microsoft's DependencyInjection Containers, and thorough adherence to the IoC principle.

The following files demonstrates the use of DI: https://github.com/svengeance/Husky/blob/main/src/PoC/Husky/Husky.Services/Extensions/ServiceCollectionExtensions.cs https://github.com/svengeance/Husky/blob/main/src/PoC/Husky/Husky.Tasks/Extensions/ServiceCollectionExtensions.cs

Husky's execution primarily comes in two flavors: HuskyTasks, and Services. The above two extensions will register all available types. The first thing the Installer does is build the DI container: https://github.com/svengeance/Husky/blob/ee8af40598e007c4c4ae319f7fed9f064693c2c9/src/PoC/Husky/Husky.Installer/HuskyInstaller.cs#L32-L47

At the end of the day this approach means that we're trading some initial setup complexity for the ability to rapidly define new Services and Tasks, especially since everything the installer needs at runtime is injected, and all dependencies are declared in the constructor,.