-
Notifications
You must be signed in to change notification settings - Fork 511
Script file directive to select scope during import. #4873
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
Comments
@drstonephd Thanks for your submission! Can you clarify how you think the vscode-powershell extesnion would solve this problem? This seems like it's already covered in PowerShell/PowerShell#4568 and would need to be implemented in PS and not the extension. Thanks. |
@JustinGrote You are correct that this is a PS feature request, not a vscode extension request. It's not a solution to issue 4568, but a work around. Don't assume modules honor preferences... set them in global. If PS had the directive, then we could use the global scope to set module preferences. At the same time, we could use a special scope for the preferences of other non-module scripts. There is value in such a directive to make sure scripts are loaded into the correct scope. The author can define the scope in which the script is design to work... if it makes a difference. Trying to control this in the vscode extension might not be a good idea. Is the choice defined in vscode file by file or for as setting that applies to all files? If I have scripts that load other scripts, it can get pretty tricky if they are not run in the correct order. As it is, I need a special wrapper script to call my scripts if I want the initial script scope in vscode. When using F5, is the choice of global or script enough? I'm confused. |
Prerequisites
Summary
A module provides a single "script" scope for the module that's shared even if the module spans multiple files. Non-module scripts do not have such a shared, non-global scope. Also, a script can be loaded into the current scope (dot sourced) or a new script scope (not dot sourced). The script might not be designed to work correctly with both load methods. There should be a means either to use the desired scope or to raise an error if loading into the incorrect scope.
Proposed Design
Add an optional "#RequiresScope" directive to control the scope into which a file loads. A SCOPE parameter will, if required, override the scope that would be selected by the method of the load (dot sourced or not dot sourced). A FORCE directive parameter could control if the desired scope is always selected automatically or if an error is raised if the default scope does not match that required.
#RequiresScope Default - uses the either the current or script scope as if the directive was not present
#RequiresScope Global Force - uses the global scope when loaded
#RequiresScope Current Force - uses the current scope when loaded (always behaves as if dot sourced)
#RequiresScope Script Force - uses a new scope when loaded (always behaves as if not dot source)
#RequiresScope Scripts Force - uses a non-global named scope 'scripts' to be the parent one or more script scopes.
The "Scripts" scope would have global as a parent. All scripts added using the "Scripts" directive would be added to this one scope. Basically, it's a special place to dot source scripts other than to global or into another script file's scope. It's sort of like treating one or more non-module scripts as being in a "non-module" module under global.
I don't think there is any value to allowing additional named 'scripts' scopes. "MyScopeForThese5Scripts" and "MyScopeForThose10Scripts"?
The text was updated successfully, but these errors were encountered: