-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Fix lint in activate.ps1 #1371
Comments
Thanks for taking a look at the activate.ps1 file and filing this @jayvdb! :D
Indeed. I think it'll be great if someone familiar with PowerShell would file a PR, fixing these lint warnings and more consistently styling the script. :)
I'm ambivalent on this since I don't expect this file to change often. I defer to others on this. |
Probably useful to get opinions of the previous authors, to see if any particular style is preferred. If none, the best choice would be the PSScriptAnalzyer default (1TBS), which also happens to be the required setting for a nice helper https://github.com/sqlcollaborative/dbatools/blob/4f424b72b394a7c6b8fa7918768daad134ae7db8/functions/Invoke-DbatoolsFormatter.ps1 which happens to have been broken in the latest release dataplat/dbatools#5800) |
Pinging for any strong powershell style preferences @bskinn, @gaborbernat, @ferdinandvanwyk, @pfmoore, and also @regisf due to https://github.com/regisf/virtualenvwrapper-powershell , though I am not sure that is the same as http://code.philsturgeon.co.uk/guillermooo/virtualenvwrapper-powershell/overview mentioned in 1084103 If there are no strong opinions, I'll go ahead with PSScriptAnalzyer default 1TBS style |
No style prefs at all here, I'm all for standardized/automatic formatting! And, if a linter would be easy to set up, I don't see why not to do so. The Python code is linted, so why not also lint the scripts? Are there any linters for the other supported non-Python shells (cmd/bash/fish/csh)? |
https://www.shellcheck.net/, maybe? |
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormattingOTBS Closes pypa#1371
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormattingOTBS Closes pypa#1371
I dug around a bit more and the default style rules appear to be I do have confirmation from the maintainers that PSScriptAnalyzer needs to be run twice to get both syntax (std) and style errors (using one of the above settings files) https://gitter.im/PowerShell/PSScriptAnalyzer?at=5d12f28a11ba925f6a253968 But it might be possible to create our own settings .psd1 file which explicitly contains both sets of rules. I think two invocations using defaults is better than adding a custom .psd1 that needs to be maintained. |
The main difference I can find is that OTBS requires |
Definitely agree a double-run with defaults is far preferable. Should be as simple as I personally like the |
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormattingOTBS Closes pypa#1371
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormattingOTBS Closes pypa#1371
@bskinn , I ended up down a rabbit hole there and eventually found their builtin style formatting style definitions are incompatible with the linter PowerShell/PSScriptAnalyzer#769 The difference doesnt make much difference in this repo, but for any significant chunk of code, a custom .psd1 is needed. https://github.com/coala/coala-bears/blob/master/.ci/PSScriptAnalyzerSettings.psd1 is the one I used to reformat activate.ps1 , and I have a hacky linter script https://github.com/coala/coala-bears/blob/master/.ci/PSLint.ps1 to run the pssa linter and formatter and keep the file in the repo in Unix EOL. activate.ps1 is currently using DOS EOL. I suggest that should also be changed. I could do that in my PR if desired, as a second commit so it is easy to see that the DOS->Unix EOL commit did "nothing". |
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormatting Closes pypa#1371
Man, sounds like it was quite a pain. Thanks for investigating & getting the infrastructure in place! Why are the DOS EOLs an issue? Do they choke the linter? Currently, AFAIK all of the tests are set such that @gaborbernat, thoughts? |
DOS EOLs are merely annoying, but were not causing any problems. I suggest using Unix EOLs only so that the repo has more consistent EOLs. I'm not a frequent Windows user/developer, so I dont know if there are bugs caused by using Unix EOLs for .ps1 or .cmd, but it seems most Windows tools can handle Unix EOLs now. |
Fix PSScriptAnalyzer warnings, and follow style from -Setting CodeFormatting Closes #1371
I would be hesitant to convert activate.bat (especially) or activate.ps1 to Unix EOLs at this point. In the past, Unix EOLs have caused me mysterious and ~random problems at times...I'm pretty sure cmd syntax is (or has been) EOL-sensitive, at least. Probably better to give these recent improvements to cms/posh time to penetrate before attempting an EOL conversion, IMO. And, even then, a quick reversion might be needed if things blow up on older systems. |
PSScriptAnalyzer is the defacto standard PS linter, and it isnt very good at ignoring files. c.f. PowerShell/PSScriptAnalyzer#1230
As a result, a few times I have had activate.ps1 appear in my results in CI, and it is usually rather hard to get eliminate those results. I'm now wrapping the linter and post-processing the results, but a better solution is to fix the problem at the source. The lint warnings are quite reasonable.
Also I notice that activate.ps1 has been switching between various brackets styles. PSScriptAnalyzer also has a code formatter built in, with a few preset styles available. The formatter is a bit trickier to invoke as it processes a code string rather than recursing through a file path, but that shouldnt be a problem here because there is only one .ps1 file in this repo. It it can also dedent everything incorrectly if the code didnt have sufficient blank lines or indentation at the right spots -- if that happens, reset the file, format the code a little better, and then it will Do The Right Thing.
A simple helper can be added to lint this file as part of the Windows CI, to ensure there are no lint or style problems.
The text was updated successfully, but these errors were encountered: