Comments (6)
Personally, I've started using option 2
and I prefer it - backwards compatibility, sane places for configs to go, standardized way of writing configurations that the community is already familiar with for specifying settings in DSC, the layering has been useful, probably more things I can't remember at this point.
from powershellpracticeandstyle.
Mostly 1 with the added reliance on commands within the module for customization. Where configuration is persistent, it was stored in XML and more recently JSON formatted files.
Configuration in my case is normally drawn in to a script level variable on module load (my a module init script).
I don't personally like the idea of polluting the users session with variables so I've avoided using Global variables. The same applies to environment variables. I felt hiding the configuration variable(s) simplified the amount of validation needed in the relatively unlikely event someone was fiddling with things (or I made a mistake and wrote a conflicting change into a different module).
I've used your Configuration module for changing module manifests (lately, at build time) but little beyond that so far. The module I'm updating now will use the Configuration module instead of my older approaches.
TL;DR: Yes I use external configuration. I would be very happy with 2.
from powershellpracticeandstyle.
Could this work just like format files (without the xml, of course)? A module could contain a default configuration, which could be added to with a command similar to Update-FormatData, maybe Update-ConfigData?
from powershellpracticeandstyle.
For PSCX we created a provider for configuration such that you have a PSCX drive to tweak configuration.
One issue if you create a permanent storage location for configurations is to make sure it is easily findable so when you set up a new machine, you can copy the configuration files to the new machine. For this reason, I'd rather see the user's configuration file stored in the user's $PROFILE dir. And shouldn't the default configuration reside in the module's install dir? Would machine config go in \Users\Public\Documents\WindowsPowerShell
?
from powershellpracticeandstyle.
We already have the functionality in 1) and specifically
In an ideal world, we would add a setting for the module manifest, and PowerShell would automatically run that script at import time (as though it were dot-sourced at the end of the module psm1?).
If you place a ps1 in the module manifest, like so
NestedModules = @('Initialize.ps1')
then at load time this loads this initialization script in the module scope just like dot sourcing would do if it is in the psm1. It will run the RootModule/ModuleToProcess first and then run, in the order that is specified, anything in the NestedModules property. So you could have 2/3/4 etc scripts in there if you wanted.
Whereas if you had the ps1 in the module manifest like this
ScriptsToProcess= @('Initialize.ps1')
then this runs in the caller scope prior to running the import of the psm1 or dll listed in the RootModule/ModuleToProcess property in the manifest. Which is exactly what we dont want.
This is documented (albeit not very well) via the NestedModules Parameter in the help for New-ModuleManifest which is at
https://msdn.microsoft.com/powershell/reference/5.1/microsoft.powershell.core/New-ModuleManifest
When we think of personalisation of modules and how I wish I could easily manipulate how they would function, I do quite like the Ideals behind how @Jaykul has implemented it in the Configuration module as personally I prefer to see any machine level information in the C:\ProgramData folder than in the Public User location. Though this is just a preference of mine. In regards to @rkeithhill point on the using the $Profile directory, I think that it could be quite useful for those in the enterprises that have mapped home drives and move between systems regularly.
So in a way if you combined 1 & 2 a little you would already have all the functionality that you are looking for and although I do think the ModuleLoad Event could be interesting and useful however as noted it's not backwards compatible.
Only other thing would be that I'd be suggestive of dropping the need of CompanyName from the Configuration Module and keep the paths to match up with how modules are currently stored (v5 & above) so
$env:LocalAppData\WindowsPowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
$env:AppData\WindowsPowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
$env:ProgramData\WindowsPowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
However there is 1 small snag and that is that in theory you'd need to also have the following for use in PowerShell Core
$env:LocalAppData\PowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
$env:AppData\PowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
$env:ProgramData\PowerShell\Modules\<Module Name>\<Version>\Configuration.psd1
and potentially the following for v4 and below
$env:LocalAppData\WindowsPowerShell\Modules\<Module Name>\Configuration.psd1
$env:AppData\WindowsPowerShell\Modules\<Module Name>\Configuration.psd1
$env:ProgramData\WindowsPowerShell\Modules\<Module Name>\Configuration.psd1
BUT
I like the idea and I've been spending time overhauling PowerShellGet partially due to a similar reason and as linked to I think this would make a good way forward to helping solve some of the PowerShellGet issues that have been considerably irritating over time.
from powershellpracticeandstyle.
@kilasuit Apart from scoping and loading order weirdness, there are two problems with solving the 1) Module initialization script by using nested modules:
- If a nested module doesn't exist, your module fails to load
- Configuration needs to be outside your module folder
One or the other of those I can solve:
- I could ship a default config file
- I could use
NestedModules = @("$env:LocalAppData\PowerShell\Modules\<Module Name>\<Version>\Settings.ps1")
But the solution to each one makes the other one intractable....
For what it's worth, in principle, I agree about leaving the company out of the module paths, but I was nervous about the fact that it's possible to work around module name collisions by installing one as "current user" and one as "all users" ... so I chose to go with something I was more confident of. In retrospect, it makes the configuration files harder to find, so I'd probably be better off using Modules\ModuleName\GUID\Version
if necessary...
However, I'm not sure about the location. Technically Microsoft PowerShell owns that, and could blow it all away... <AppData>\<CompanyName>\<ProductName>\PowerShellModule\<Version>\
is technically a more correct location, but again, even harder for a user to guess at?
Of course, the exact path doesn't matter if this is built in via dependence on PowerShell or a 3rd party module, because people will learn use the cmdlets to discover it.
from powershellpracticeandstyle.
Related Issues (20)
- Question: Best Practice fot HOT 3
- Indentation advice is bad/wrong HOT 9
- Constant variables placement with in a script. HOT 1
- Is it better to use $PSItem vs $error[0] or $_ HOT 2
- Add Set-Variable vs. $foo = "bar" best practice HOT 2
- Correct formatting HOT 5
- Unquoted strings HOT 3
- Indentation on Comment-Based help HOT 5
- Consider revising PERF-02 HOT 1
- Naming-Conventions refers to a broken link
- Guidance on External Module Dependencies HOT 3
- Suggestion - explain why the second command in PERF-01 is faster
- Capitalization of function parameter type HOT 2
- Broken link and sentence fragment on naming conventions page
- Module structure HOT 4
- Avoid Using Semicolons (`;`). HOT 3
- Parameter Comments and Get-Help HOT 2
- Begin/Process/End or Process only. No Process/End, Begin/End, Begin/Process. HOT 5
- Indentation for lines after a pipe character HOT 3
- How to deal with a module that contains multiple interdependent classes? HOT 6
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 powershellpracticeandstyle.