Comments (10)
@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).
from plaster.
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'd rather have a new module that is clearly an extension: moduleName.extensionName and manage its lifecycle like any module (it has an obvious dependency as well), and manage my moduleName's extension via a config file (see below).
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).
In short, I would have liked to do
Import-Module moduleName -myArg1 MyVa1 -myArg2 MyVal2
Or 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).
So this is not conflicting in the above, and can probably be made generic enough so it can be re-used by anyone.
Any thought/comment welcome, I've got a proto there:
https://github.com/gaelcolas/lib.common/blob/master/ReceiveModuleParams.ps1
Used there: https://github.com/gaelcolas/log4ps/blob/master/Log4PS.psm1
from plaster.
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.
from plaster.
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.
from plaster.
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
from plaster.
@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.
from plaster.
@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.
from plaster.
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?
from plaster.
Sounds good. Either send me an invite for a time that works for you or
reach out early next week in the PowerShell Slack channel and we can
coordinate schedules/times then.
*Kirk Munro *
Poshoholic, Microsoft MVP
Blog http://poshoholic.com/ | Twitter http://twitter.com/poshoholic |
LinkedIn http://ca.linkedin.com/in/kirkmunro | GitHub
http://github.com/KirkMunro | Facebook
http://www.facebook.com/#%21/kirk.munro
Need a PowerShell SME for a project at work? Contact me
http://poshoholic.com/contact-me/!
On Tue, May 17, 2016 at 12:06 PM, David Wilson [email protected]
wrote:
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?—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3 (comment)
from plaster.
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?
- how would they want it to work?
- how would they want to find new templates?
- would they want modules to come with templates Plaster can find?
- Would they want these distributed in their own store, PSGallery, in existing modules, some new format, etc.
- What uses can they think of? (I think this is a huge question we should really consider early on)
- Would they want to see a sort of extension/plugin model for their own integrations?
- Would they want to see something like Pester's Before/After where a user can specify scripts, commands, or things like that to be executed outside of the template.
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:
- Using VirusTotal api to validate files in my deployments/repos.
- Using Pester to validate my urls in my Repo Markdown (Really useful if running a Github pages Jekyll blog).
- Using Pester for Validating PSVersions by running scripts with powershell.exe -v 2-5. ( $Object.blah.blah always gets me on V2)
- Operation Validation tests to ensure local GPOs are being applied properly to non Domain PCs
- and another i'm currently at the planning stages of is Validating spelling and grammar of my repos with Pester.
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.
from plaster.
Related Issues (20)
- Paths shouldn't be validated when the condition evaluates to false HOT 5
- set up release build HOT 9
- Multi Choice Allows for a Duplicate Shortcut Key HOT 2
- Get-PlasterTemplate -IncludeInstalledModules return templates from all installed module versions HOT 2
- Completely suppress output of invoke-plaster HOT 7
- Copy folder with content HOT 2
- Test-ModuleManifest fails in Core HOT 1
- Is anyone maintaining this? HOT 2
- %homedrive% and %homepath% vs %userprofile% HOT 1
- Example 2 of Invoke-Pester doesn't work HOT 2
- Absolute Paths for Templates? HOT 2
- Transfer of Ownership HOT 16
- Module Manifest Template Tests Don't Work with Pester 5 HOT 3
- How does one make a module "Plaster Aware" HOT 2
- Plaster - Past, Present, and Future HOT 2
- Change Github references to PowerShell.org HOT 3
- Pester tests throw error when using version 4 or higher HOT 3
- Folder Creation - Skipped Folders HOT 2
- Validating input from Plaster parameters HOT 1
- Error in implementation of SupportsShouldProcess
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plaster.