Experiment with better "module" import guards

[Ash258]

Something like this could be faster

if ($script:Imported) {
    return
}
$script:Imported = $false

...

$script:Imported = $true

[ZzZombo]

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.

[Ash258]

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.

[Ash258]

/preblock

[ZzZombo]

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.

[Ash258]

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.