Experiment with better "module" import guards
Ash258 opened this issue · comments
Something like this could be faster
if ($script:Imported) {
return
}
$script:Imported = $false
...
$script:Imported = $true
Why do you seem to reinvert the wheel? Why not use the build-in module features like Import-Module
, etc? These do not require such a thing like an "import guard", PowerShell will import only one instance of a module unless you create a very specific scenario.
And who will cleanup the leaked modules? All of the functions would leak into current powershell user session. And on repeated command it would conflict.
If user would run shovel update
, it would not work, as the module would be loaded, which would prevent the update from removing/updating files.
/preblock
You can unload modules with Remove-Module
at the end of the current activity, or you can load them locally, then you do not have to do this. And like I said earlier, PowerShell will not load the same module more than once (per session), so there is no conflict possible. Also, modules are loaded entirely in memory, and no locks are placed, so it's still possible to change any files. As long as a module is loaded, it's backing files can be changed as you wish cleanly, and only after unloading and importing it again the changes take effect.
In ideal case yes. But not in all. CTRL+C, fails, everything would have to run remove-module. Not possible to achieve.
The conflict would occour on update. The new functions (with new code) would not be loaded, as they would be already loaded, -Force needs to be used, which is not convenient for all cases.
Complete waste of time to discuss more. Not talking I just do not want to have it like that.