Replies: 10 comments
-
|
Kirk's point of module extension is very good and I always liked the idea and tried to implement in the past. The hard thing to get right is again how to discover and install extensions. It's not practical to extend by adding files within your module's folder, after it's deployed (I tried and that causes problem, such as permission for non admin). Ideally, IMO, Module extension should be external, such as another module, or another psm1 file, so that we can leverage the PowerShellGet functionalities to manage those similarly. A subfolder such as $PSModulePath\Plaster could work, but it's not a 'supported workflow'. I found that modules accepting configuration should accept them in a standard way (both by Argument List, or by having a file that auto-loads based on the importing script). Import-Module moduleName -myArg1 MyVa1 -myArg2 MyVal2Or if script.ps1 is importing moduleName then that module would automatically look for, say, moduleName.xml or moduleName.config or moduleName.json... you get the idea, in the script.ps1's parent folder. The dirty trick I use to implement that, while allowing for parameters, is looking for an hashtable as the first item from the Import-module's ArgumentList. or if no argument look for the file. Import-Module moduleName @{'myArg1'='MyVal1';'myArg2'='MyVal2'}Then both ways (file or ArgumentList) will call a function for the module: Set-Config (that needs to be a convention). Alternatively, that could be managed by the Main module, if the naming convention for extension is followed: moduleName.extensionName it can look at all the Extensions available, and load them by default as submodule, scriptToProcess or global extension (although, I'd prefer having a way to pick only the extension to load). Any thought/comment welcome, I've got a proto there: |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I didn't mean extending modules you don't manage (in which case permissions becomes an issue). I meant using modules as the package to deliver, and having the Plaster engine automatically recognize and consume extensions to it (templates or other extensions) that are defined under a supported Plaster folder in other modules. Modules and the Gallery are the distribution channel, and the feature lights up new value when that value is available on the local system automatically. |
Beta Was this translation helpful? Give feedback.
-
|
Hey Kirk, thanks for the ideas! I've actually been thinking about your first point a lot already. It'd be awesome if Plaster templates could be distributed on the Gallery with new and existing modules for easy discovery. The first idea I thought of for that was having a Plaster template shipped with Pester to auto-generate certain types of test files. That may not be the best example, but it seems we're thinking on the same wavelength. Definitely looking forward to your help in defining how we accomplish this. As far as providing extensions to Plaster is concerned, that's a great idea. I think the goal there would be to allow extensibility in a way that still maintains some level of security so that someone doesn't cause a user to run a malicious template generator. I'd definitely like to spitball some idas about what this could look like. For the DSL idea, you know I love DSLs :) What do you think a DSL that enables usage of templates might look like? I'm having a hard time visualizing it. |
Beta Was this translation helpful? Give feedback.
-
|
By the way, check out our design notes file to see some of the other things we've been thinking about: https://github.com/PowerShell/Plaster/blob/master/DesignNotes.md |
Beta Was this translation helpful? Give feedback.
-
|
@daviwil I'll review the design notes as soon as I can. We should figure out a mutually convenient time when we can discuss/hash through a bunch of this stuff. This week I'm at the Midwest Management Summit and busy today tomorrow (today = session prep, tomorrow = sessions), but I may be able to fit it in on Thursday depending on whether or not I have a session I want to attend, or failing that I'll be home Friday at around 4PM AST (GMT -4) so that would work or anytime next week. |
Beta Was this translation helpful? Give feedback.
-
|
@KirkMunro interesting idea on distribution. I had originally been thinking these would be more like NuGet pkgs, downloaded from some online repo and cached on your machine. But a regular PS module - deployed to PSGallery (which is a NuGet repo) - could act as a sort of "Trojan horse" for these templates. I know you mean templates that accompany some other functionality. But perhaps you could have modules that contained only templates? RE the design notes - keep in mind that those are sort of a "stream of consciousness" set of notes. :-) I need to update them. I'll try to get to that tonight. |
Beta Was this translation helpful? Give feedback.
-
|
@rkeithhill I was thinking about modules that contain nothing but templates, but that works as well with manifest modules. It's really not much different from a nupkg file except it's less dev-focused and a more IT-targeted approach, discoverable via PowerShellGet, plus support for dependencies on other modules (which I think is really key). |
Beta Was this translation helpful? Give feedback.
-
|
We can definitely jump on a Skype call to chat at some point soon. Maybe you, me, and Keith whenever you're back from MMSMOA? |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good. Either send me an invite for a time that works for you or *Kirk Munro * Need a PowerShell SME for a project at work? Contact me On Tue, May 17, 2016 at 12:06 PM, David Wilson [email protected]
|
Beta Was this translation helpful? Give feedback.
-
|
I like a lot of Kirk's ideas. I feel PowerShell is a unique language with a unique user base. We should think a little more outside of the box with Plaster and not just try to clone Yeoman. We should try to adopt practices that PowerShell users have already grown accustomed to. I would say a huge percentage of your everyday PowerShell users have never used yeoman(or heard of it for that matter) or even NuGet, and aren't familiar with how it works. I am a little unique and have used Yo a decent amount because I have always been big into these little light and hackable editors and was introduced to it when creating extensions and themes to publish for Atom when it was in alpha/beta. Then I have used it for over 300 themes for VS Code. As a PowerShell user, Yo never had a "PowerShell" feel to it. It feels like a Web dev tool written for web devs. Coming from someone with a background in Operations and no Developer background, I see issues following the Yeoman model. It makes perfect since for Yeoman to work the way it does for say a JS project, because that's the sort of workflow a JS dev is used to. However, I would argue that does not translate to the majority of PowerShell Users. If we try to make Plaster a Yeoman clone, I don't think it will get much traction outside of the PowerShell users with a Developer background or a small percentage of people like me. Kirk's way of thinking is what I love to see. He immediately thinks outside of the typical Yeoman distribution and use cases, and applies those same ideas but with a PowerShell infused perspective. This to me is what we should be embracing and trying to get community feedback on. If the community were to have a PowerShell based template generator that easily built out templates for them, how would they answer these questions?
With PowerShell being such a diverse language in terms of people using it, the question I want to ask is, do we want to base Plaster's design off of a Developer's tool that defines itself on it's website as, "The Web's Scaffolding Tool For Modern Webapps." I think Plaster should be more open ended and try to embrace the idea that this is PowerShell, think outside of the box and come up with cool uses that none of us would have ever thought about. I was talking to David about how it might be interesting to try to play around with integrating Plaster and something like SnipperPX or some other form of snippets to build dynamic scaffolding for Advanced functions. You just walk through building all of your parameters setting all of their validations, default values, parameter sets and it is dynamically executing snippets as you walk through the template. I think a barrier to snippets for many is they are overwhelmed by them. They either have a few very specific snippets or a hundred little small snippets that you cant remember the snippet for. I am still on a high from starting to learn Pester 5-6 weeks ago and discovering Validation/Operational Validation tests with Pester. It has inspired me to try to look at the norm and think, how can I make this better, or how can I use existing tools in ways that I have overlooked. Examples of Pester I have come up with so far are:
This makes me want to look at Plaster in the same way. Something about Plaster makes me just know there are some amazing uses that are being overlooked. I feel strongly that Plaster should try to embrace this sort of thinking and try to offer mechanisms where people can get creative. |
Beta Was this translation helpful? Give feedback.
-
Hi guys,
I just saw the news about the Plaster project. Very cool concept! I haven't tried it yet, but had some ideas immediately come to mind that I wanted to share, so typing frantically while the mental iron is hot! :)
First, I personally feel that there are many not-so-obvious module extension points in PowerShell that people overlook that are worth considering. One of my personal favorite extension points is to extend functionality within PowerShell automatically via inclusion of a file structure underneath a particular module. Modules are already the vehicle for broad distribution of PowerShell artifacts, and we have PackageManagement plus the Gallery to facilitate that. Why not then have a tool like Plaster automatically discover Plaster templates that are located in any module in a Plaster folder that is under the root folder of a module? The same could be done for Pester, with tests being automatically discovered and invocable by name if they are in a Tests folder (great for reuse of tests across modules). Or DSC even, where DSC resources/configurations could be defined as an extension to a module (makes sense when both use resources in the same module). But those ships have sailed, and this ship is brand new. I personally love the idea of new PowerShell extensions that bring some new file structure or DSL to the mix being located in modules themselves, because I get all of the module goodness I'm already used to: versioning, discoverability, auto-load, PowerShellGet support, etc.
For example, I could create a module (SnippetPx -- already exists even) that includes a Plaster subfolder under the root that defines templates that can be used in Plaster. Then if that module was installed but not loaded, I could invoke Get-PlasterTemplate and get a list of all Plaster templates that are located in modules on my system. Templates can be overridden (sometimes a user may want to override a specific template) by leveraging their WindowsPowerShell\Plaster path. I already set this up for SnippetPx so that I could have a discovery mechanism that just lights up new functionality when a module containing Snippet definitions is on the system with no additional work to manage the registration/location/path/etc., and I've been meaning to share that code as part of a broader PowerShell extension library.
Going further (again, I haven't tried Plaster yet), maybe under my Plaster folder in my module I have two subfolders: templates and extensions. In templates I can offer Plaster templates that are ready to use. In extensions can I have extensions to the Plaster engine, allowing me to define Snippets as a feature that can be used in Plaster and providing whatever metadata/commands are necessary to make that happen, and my templates can automatically use the extensions in my module. If PowerShell commands are involved in those extensions, I can define them within my module and everything will just work because the entire package is just a module.
Thinking beyond that, DSLs come to mind as a nice way to consume templates. Hashtables/splatting works, but it might be nice to see a mini-DSL that can be used in place of Invoke-Plaster or that perhaps offers features that go further than Invoke-Plaster that provides interesting options that users may want. DSLs are great for structured output (generating files is a great example), and there may be some interesting ideas here that can be best realized by using a DSL.
I'm happy to discuss these at length here or in the PowerShell Slack channel, or demonstrate what I'm talking about via a Skype session anytime. Just say the word and I'll make time for it in my schedule.
Beta Was this translation helpful? Give feedback.
All reactions