# Windows: The future of powershell.ps1 **URL:** \ **Category:** Ansible Developer\ **Tags:** windows\ **Created:** [November 11, 2015, 4:26pm UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735 "2015-11-11T16:26:42Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\ **Post date:** [November 11, 2015, 4:26pm UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/1 "2015-11-11T16:26:42Z")
Hi all, We’re seeing some patterns where multiple modules might share very similar code (UserSearch is an example of a function which pretty much every module dealing with permissions needs). Currently these are implemented very similarly in each module. I’d like to start discussing how we approach module which may require similar underlying functions such as UserSearch. As far as I can see, we have a couple of options: 1. Move them into powershell.ps1 2. Keep them separate from powershell.ps1, but refer to them in powershell.ps1. This would require us to do a run-time merge of powershell.ps1, “submodules”, variables and the module script itself 3. Keep them separate from powershell.ps1, but allow reference from each module by keywording #WANT\_POWERSHELL\_File\_name.ps1 or similar. This would allow the module dev to choose which “common modules” to pull in. This would also (possibly) allow common shared modules to live outside of ansible core, so for instance if there’s 5 modules which does something using the same api there would be 5 module files + the common functions file for that module. 4. Combination of 2 and 3. I just wanted to get the discussion started, any comments/opinions welcome! ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [November 11, 2015, 4:31pm UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/2 "2015-11-11T16:31:34Z")
3. would make powershell mirror much of how currently python modules work, 2. might be a bit too much magic for my taste. ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [November 12, 2015, 6:13am UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/3 "2015-11-12T06:13:12Z")
Regarding 1, right now I don’t really want powershell.ps1 to get much bigger, but I might feel differently when put\_file performance is increased (as per [https://groups.google.com/forum/#!topic/ansible-devel/aAFdMPvYiFs](https://groups.google.com/forum/#!topic/ansible-devel/aAFdMPvYiFs)) 2 feels like it could be painful to get working right. So I think I favour 3. The trick is going to be getting the granularity right - too many different includes for little functions would be counter productive - too few would just make for bloated modules and/or module writers duplicating bits of functionality which we definitely want to avoid. Jon ---
**Author:** ![Trond\_Hindenes](https://avatars.discourse-cdn.com/v4/letter/t/96bed5/32.png) [@Trond\_Hindenes](https://forum.ansible.com/u/Trond_Hindenes)\ **Post date:** [November 12, 2015, 7:58am UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/4 "2015-11-12T07:58:50Z")
Yep, I completely agree. I guess the changes needed for #3 are: 1. We have to agree on a tag which would work as the “trigger” for including, for example #INCLUDE: .ps1 or whatever. This is what module devs would use to reference functions 2. We need an understandeable search order for referencing function files. Something like: 3. Same dir as the module 4. Any module path 5. module\_utils path (same path as powershell.ps1) Again, not sure how this is solved on Python but it would definetely make sense to re-use any logic (at least as far as it makes sense given the language differences) ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [November 12, 2015, 8:03am UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/5 "2015-11-12T08:03:10Z")
it will be hard to find the correct divide cause it requires us divining what the future needs for common functions will for all the unplanned modules.... [http://dilbert.com/strip/1997-01-28](http://dilbert.com/strip/1997-01-28) I think that adding to powershell.ps1 until there are enough functions that can be grouped and split might be the 'least insane' way forward, I don't know if we are there yet. The module\_utils is really a 'copy n paste' into the final script, so there is a tradeoff with script size and code maintainability. I'm not aiming for getting 'the right one'TM , just a big enough consensus by the maintainers on where we should divide would suffice. ---
**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\ **Post date:** [November 12, 2015, 11:10am UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/6 "2015-11-12T11:10:25Z")
Yeah need crystal ball technology for this one 🙂 Its probably better to derive what needs to be common from things that we already have. Looking at what there is now in powershell.ps1 (and proposed addition here: [https://github.com/ansible/ansible/pull/12806/files](https://github.com/ansible/ansible/pull/12806/files) and here [https://github.com/ansible/ansible/pull/12600/files](https://github.com/ansible/ansible/pull/12600/files) there are Functions for working with ansible (read/create parameters, creating the json response) File-related functions (Get-FileChecksum) User-related functions [https://github.com/ansible/ansible/pull/12806/files](https://github.com/ansible/ansible/pull/12806/files) I think splitting stuff up into lots of different chunks could be counterproductive but I could live with 3 or 4 so something like WANT\_POWERSHELL\_COMMON WANT\_POWERSHELL\_FILETOOLS WANT\_POWERSHELL\_USERTOOLS … all of which just pull in .ps1 files from module\_utils. Then there’s just one folder to look in for common code and the ‘api’ doesn’t start to get intimidatingly complex. I’m not sure we need a way for modules to import their own copy-n-paste includes from anywhere else, at least at the moment, but maybe I could be persuaded otherwise if there are already some examples. Maybe this is overkill and we can live with 400 lines of common powershell - basic.py is 1907 lines after all. Jon ---
**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\ **Post date:** [November 16, 2015, 4:49pm UTC](https://forum.ansible.com/t/windows-the-future-of-powershell-ps1/19735/7 "2015-11-16T16:49:02Z")
I concur- I don’t think we necessarily need to preemptively split into dozens of pieces, but an easily-extensible dynamic inclusion process is a Good Thing, especially for rarely-needed-but-should-be-shared-for-gods-sake stuff like the proposed “run as scheduled task” extensions. On a related note: _every_ customer I’ve done custom module work with has asked for a way to do this for their own code without hacking their Ansible installs (eg, allow module code-sharing from library/). I know similar things have been under discussion on the \*nix side of the house for awhile, but last I checked, there’s been no consensus on how it should work- we’d face many of the same issues, I’m sure. I’d advocate for something relatively simple that follows the existing extensibility patterns (eg, a well-known directory name under the library path that we’d probe for X in the case of an unresolved #WANT\_POWERSHELL\_X). If we defined the resolution order clearly and added warnings for duplicate definitions of X, I think we could address much of the criticism of previous attempts at this sort of thing. -Matt