FriedrichWeinmann
commented
1 month ago Heya @merddyin , thanks for the quite thorough feedback and thought spent on this! This discussion has come up repeatedly through the years (especially at the conferences I usually hang out), and I don't think this is ever going to end. Not a bad thing either, as it shows, that people are interested in the toolkit, so I much appreciate it. I also get the opposite feedback, where people are happy about having one dependency handle all their needs (and don't care about the extras it offers that they don't use).
I've put together my conceptualization on module types at the beginning of this year's conference talk on templating and module mass production. Summarizing: PSFramework is basically most of my Framework stack, splitting it up into components is against its design.
From a technical perspective, it is not designed to be split up, and other than some of the less integrated extra features that do not make up much of its code, they all tie into each other - logging uses configuration, configuration uses messages, messages use logging, messages use configuration, configuration uses debug, messaging uses debug, tab completion uses messages, tab completion uses debug, configuration uses tab completion, ... Trying to meaningfully break it down would be an incredible effort and a lot more fragile. It's an effort I cannot deliver on, even if I agreed with the approach.
Nesting components internally has further risk of invisible collisions between different consuming code parts and I shudder at the support impact that would cause. Could it be done? Possibly. The complexity required would make this a full-time effort I am very, very far from being able to commit to, sorry.
In the meantime, internal module deployment to offline environments can be simplified using an internal PSGallery, which you can even host in a file-share. This would allow you to run install-module from that offline computers and solve the package management requirement. It would also allow you to integrate internal code-signing before re-distributing approved modules. Here's some docs describing that
On October, 15th, there is an online mini-conference from the PSConfEU team - this may be for you, as Sydney Smith will talk on that very topic and what's the current state, including the new versions of packagemanagement. If you can distribute PS7 internally, your offline machine will have the new tools available out of the box - though I can understand if that is not possible for you from an organizational perspective (native PS7 integration with OS is a common issue requested and discussed).
What I do with several customers is maintain an internal repository and satisfy the zero-trust needs by manually verifying all modules before introducing them to the internal environment. For that we clone the github repo into an internal repository and code-review there. This allows us to later do a delta-PR and see what has changed, rather than having to do a full review for the entire module each time I want to update. Then we build it from source and publish internally (all my module repositories include the automation tools needed to build them locally without being bound the a particular service, such as Azure DevOps or Github).
merddyin
One of the items that holds me back on leveraging PSFramework for module dev, if only slightly, is the need to have a separate dependent module. While this is fine for many modules run from standard workstations, I tend to do a lot of work focused on implementation of zero-trust. Because of this, I often end up needing to run modules from systems without internet access, such as servers or privileged admin workstations. I know I can copy the dependent module over, but might it not be far easier to incorporate the required elements more directly? These are just thoughts, so feel free to disregard of course.
My thoughts/suggestion here is to achieve integration along the lines of one of the approaches outlined below.
Explicit Integration
This approach involves adding more options, in terms of specific features of PSFramework that the module maker wishes to implement. For example, providing the options to incorporate configurations, classes, protected commands, and logging, while excluding other features. In this scenario, required component elements would be copied to the target module as private component elements that would load as native to the module, perhaps as internal cmdlets. To reduce complexity for the user, the build process could also institute checks for PSF command calls for features that weren't included initially, and offer the option to update the module to add the required bits.
Pros:
Cons:
Implicit Integration
This approach could be achieved by implementing a sort of 'plugin' type approach, in similar manner to that used by ModuleBuild. In this scenario, the entire PSFramework module can semi-easily be incorporated into the main module as a single package as sort of an additional set of "private" cmdlets by only loading the plugin within module scope. I've attempted this approach in the past with ok results, though there are some loading challenges that would need to be worked through.
Pros:
Cons:
You could also, in theory, sort of combine the two approaches. In that scenario, you'd probably want to separate the main module into discrete feature sets that get copied to the Plugins location set by the template. You'd also likely want to incorporate some elements by default. There are lots of quality of life things that would make sense to include in every build, such as the protected command functionality.