-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Moving Import-PowerShellDatafile from script to compiled cmdlet #2750
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Hi @powercode, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution! The agreement was validated by Microsoft and real humans are currently evaluating your PR. TTYL, MSBOT; |
520dced to
60da0d9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@HemantMahawar should we have copyright preamble on the new files?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given it is open-source code, I don't think it is needed. @joeyaiello Can you weigh in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removing
vors
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, avoid copy-paste
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's probably not needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is copied from
PowerShell/src/Microsoft.PowerShell.Commands.Utility/commands/utility/MatchString.cs
Line 1723 in 9a195f4
| private List<string> ResolveFilePaths(string[] filePaths, bool isLiteralPath) |
Can we avoid such copy-paste?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really agree, but I actually think it would be a good Idea to provide these kind of helpers in a public API. This needs to be done by everyone who wants to handle Path and LiteralPath.
What is the right way to go here?
See #2729
2470581 to
ba64f8f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we use this pattern of sharing the backing store for parameters elsewhere? If not, it seems like potentially a bad idea to start doing this.
One maybe non-issue is the parameter binder copies all parameters in the cmdlet instance before parameter binding and restores them. It seems unlikely, but possible, that a non-null value in Path could cause problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A quick search gives that the pattern is in
AclCommands.cs
CertificateCommands.cs
CSVCommands.cs
ExportAliasCommand.cs
MatchString.cs
Out-File.cs
SaveHelpCommand.cs
SignatureCommands.cs
StartTranscriptCmdlet.cs
UpdateHelpCommand.cs
WriteFormatDataCommand.cs
XmlCommands.cs
But the cost of changing is very small.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to
get { return _isLiteralPath ? Path : null; }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't ValueFromPipeline be on LiteralPath?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this is just a translation of the PowerShell, but it seems overly fancy. I think it would be clearer if the caller just passed errorId, it would make searching for the error string easier too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
corrected.
Rebased version pushed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realize this is just a translation of the PowerShell implementation, but a psd1 can contain much more than a simple hashtable. For example, the psd1 file contain 2 hashtables as an array, and this implementation would ignore the second one.
As implemented, the cmdlet is mostly useful for typical module manifests, but psd1 files are used for other things, e.g. localization, and sometimes use commands like ConvertFrom-StringData.
We should, as a minimum, not ignore any part of the ast.
We should also consider supporting more than a simple hashtable. Ast.SafeGetValue can certainly handle more (e.g. an array of hashtables).
We might also consider doing something more like what Import-LocalizedData does, though we'd need feedback from @LeeHolmes to understand the important differences and why this cmdlet was introduced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we start with just the move as descripted in the issue, and open a new issue for the functional changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 don't block the PR and open new Issue.
6186748 to
bc2b766
Compare
bc2b766 to
141cce0
Compare
| [Parameter(Mandatory = true, Position = 0, ParameterSetName = "ByPath")] | ||
| [ValidateNotNullOrEmpty] | ||
| [SuppressMessage("Microsoft.Performance", "CA1819:PropertiesShouldNotReturnArrays")] | ||
| public string[] Path { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need a change as this code is just following a somewhat broken pattern.
If LiteralPath was set, _isLiteralPath will be set to true. Then, if Path is set, _isLiteralPath is not cleared. This isn't really a scenario I guess, but it is handled correctly in some places in our code base, but in many others it is not.
Fixes #2734