Repository navigation
RFC0015-PowerShell-StartupConfig #48
Description
Committee voted to REJECT this RFC: https://github.com/PowerShell/PowerShell-RFC/blob/master/X-Rejected/RFC0015-PowerShell-StartupConfig.md
issue to solicit feedback on https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0015-PowerShell-StartupConfig.md
Metadata
Metadata
Assignees
Labels
No labels
Activity
SteveL-MSFT commentedon Dec 6, 2016
Should there be a New-PowerShellConfig cmdlet to make it easier to generate a template for users?
WSMAN should be Wsman (staying with Pascal casing rules) and probably under a Remoting top level key.
We should probably add a parameter to powershell.exe to consume a specific config file.
JamesWTruher commentedon Dec 6, 2016
a template for creating powershell config files seems quite reasonable, but IMO not needed for a minimal viable.
i would be worried about the parameter to start powershell.exe with a specific config file. One of the things I was interested in was maintaining the behavior that our registry provides which is a "locked" config for settings. It seems that by providing a way to not use the global config file it gives the user the opportunity to avoid the settings which the admin has created. If, however, this isn't needed/desired, then I don't have any problem with a config file parameter.
Hmm, case is something I didn't consider - should this be case insensitive? The keys correspond to well known knobs in a case-insensitive manner?
RamblingCookieMonster commentedon Dec 7, 2016
Tangent:
A note tangential to this - given that psd1 is used in a few places, It would be nice if there were Cmdlets to import, export, and modify PowerShell data files (vs. just import).
Ideally these would be published to the gallery and offer downlevel support (perhaps PowerShell 3.0 or later).
At the moment, relying on components of Joel Bennett (@Jaykul)'s Configuration module.
On topic
psd1 makes sense to me. Another option not mentioned would be yaml. It allows comments, and has standard libraries in most languages. Wait! Not PowerShell. Would be nice to have Cmdlets for this as well : )
Lastly, nesting XML in another data format? Isn't this a mortal sin? Please no. Please. Abstract it out into whichever configuration data type you choose (also: don't pick XML). Please.
Cheers!
daviwil commentedon Dec 7, 2016
To add to Warren Frame (@RamblingCookieMonster)'s tangent, I'd also like to see schemas for .psd1 files :)
JamesWTruher commentedon Dec 7, 2016
That XML is what is currently used to configure remote connection endpoints for PowerShell. I really didn't want that to be the focus of the RFC, (the underlying providers should take what they need), but I still wanted to be sure that we could cover our current configuration, and I chose the remoting config data because that's what we have now.
I also didn't want to suggest that we do both of those activities (change our config store and all of the code which reads that config) in this single RFC as it is contra-fast-iterate. I just want to be sure that we have a way to handle the configuration that we have right now in an environment where the registry is not present. I fully expect that over time we can migrate current settings (and their format) into something more consistent.
yaml isn't bad, for the reasons that you mention, but yet another format for which we don't have tools seemed like a pretty long path.
The schema is a good point, not quite how to represent that - suggestions?
Jaykul commentedon Dec 7, 2016
I'm concerned about the version thing.
It's safe to assume that at some point in the future, changes will be made to the configuration schema.
Putting a minimum version in the config file is one way of avoiding dealing with that, but I don't think it's the best way, because it doesn't a.) help us configure side-by-side versions differently, nor b.) allow us to still configure the old versions the way they were before the changes.
Will the config file support an ARRAY of hashtables at the top level, each with a (minimum) version specified? Or should the (minimum?) version be in the file name, allowing for PowerShell-6.0.Config.psd1 and PowerShell-6.0.0.21.Config.psd1 to exists side-by-side?
Also slightly concerned about the layering
I understand the motivation. However, your description of config file layering seems like precisely the opposite of how any other apps that I know of do config file layering. That is -- normally, the more specific config file (Enterprise -> Machine -> User) overrides the less specific config file.
Is there any precedent for this that you can point to?
If the configuration is layered backwards as described, then I think I disagree that a template for config is not necessary for a minimal release, because you won't be able to ship a default config file -- since it would result in locking down everything.
I agree with Steve about the WSMAN
WSMan vs Ssh vs ... I don't know. It seems there should be a top-level "remoting" key.
And I definitely agree that putting XML into strings in a PSD1 is a mess.
SteveL-MSFT commentedon Dec 7, 2016
PSModulePath should be moved to the config. Thinking about this, remoting config should be outside of powershell startup config. I would also suggest targeting this config to preference rather than policy.
JamesWTruher commentedon Dec 7, 2016
As for precedence, think GroupPolicy which doesn't allow you to override some settings. I was initially seeing this as way to replicate our current behavior on Windows. However, we also need a way to set preferences, which would definitely want precedence which is reversed to what I've spec'd.
If It's ok to table the Policy discussion, and make this more about preference, I'm happy to reverse the spec'd precedence.
In my mind, the versioning question is only about the config file in the users $HOME directory. Since each PowerShell installation lives in its own location, there's only ever one $PSHOME config file per installation. However, since the $HOME confiig file will have to address any version, it needs to have more flexibility. That flexibility can easily be done on a file-by-file basis (although reductio ad absurdum suggests that you could have dozens and dozens of those files hanging about in $HOME). A file-by-file approach would certainly be easier to deliver.
For the last comment, don't get me wrong, *i completely agree that putting XML into strings is a mess, I'm not happy about it either (it's just what we have today), and I was hoping to avoid changing the parsing code which handles what we have today - a measure of expedience, and fast-iterate model: first make it possible to just change where the config comes from, then change the config format to something reasonable.
And now that I think through all scenarios for the WSMAN bit, I'm thinking that all of this remoting config has to be done differently and not part of this spec/config file at all. The config of services should not be part of this config at all, so I'm going to remove all of that WSMAN stuff entirely.
I'll put together a PR which implements all of these changes
BrucePay commentedon Jan 5, 2017
WRT to schema - you can use classes with null constructors to represent the schema. To validate, simply cast the PSObject returned from the .psd1 file into that type and you end up with a strongly typed object instance. (Note: representing schema this way makes it independent of the data file format as long as there is a way to read the file into PSObjects i.e. and Import-* cmdlet). On the whole, I'd suggest rewriting the proposal to include a set of classes to representing the schema and have the data format follow from there.
Velocet commentedon Mar 16, 2017
The configuration should definitely use .psd1 since it is easily usable inside PoSh.
Maybe the top level config should be separate for Linux/macOS/Windows?
How about a different config for different hosts? (VSConfig/ISE/etc.)
SteveL-MSFT commentedon May 31, 2017
I think startup perf impact is a major consideration and even using psd1 may be significant and perhaps we should consider a simpler format to parse
SteveL-MSFT commentedon Jun 1, 2017
We need to also move the existing PowerShellProperties.json config to this