proxb / PoshRSJob

Provides an alternative to PSjobs with greater performance and less overhead to run commands in the background, freeing up the console and allowing throttling on the jobs.
MIT License
541 stars 87 forks source link

Add ImportPSModulesFromPath support #178

Open beargle opened 6 years ago

beargle commented 6 years ago

Add Start-RSJob parameter ModulesFromPathToImport that accepts a single path, from which module(s) will be imported into background runspace jobs. Modules in this path are not required to be listed by name, and the path does not have to exist in $env:PSModulePath. Fixes #177.

Changes proposed in this pull request:

How to test this code: The snippet below allows manual verification of Get-Module output when either a full or relative module path name is passed. I'm relatively new to Pester, but would like to learn if someone has suggestions on how to setup the automated test cases.

# assuming PoshRSJob is in $env:PSModulePath or imported, setup a sample custom module path.
# get both a full and relative path name for testing
$ModulePath = New-Item -Path ([Guid]::NewGuid().ToString()) -ItemType Directory
$RelativeModulePath = Resolve-Path -Path $ModulePath -Relative

# export sample modules for import in runspace
svn export https://github.com/psake/psake/tags/v4.7.0/src $ModulePath\psake | Out-Null;
svn export https://github.com/ramblingcookiemonster/PSDeploy/trunk/PSDeploy $ModulePath\PSDeploy | Out-Null;

# start single runspace job, passing full name of module path.
# Get-Module output in the runspace should show imported psake and PSDeploy modules.
"Modules from full path" | Start-RSJob -Name { $_ } -ModulesFromPathToImport $ModulePath -ScriptBlock {
    Get-Module;
} | Wait-RSJob | Receive-RSJob;

# do it again, this time with a relative module path
"Modules from relative path" | Start-RSJob -Name { $_ } -ModulesFromPathToImport $RelativeModulePath -Verbose -ScriptBlock {
    Get-Module;
} | Wait-RSJob | Receive-RSJob;

# cleanup
Remove-Item -Recurse -Force $ModulePath;
Remove-Variable -Name @("ModulePath", "RelativeModulePath");

Has been tested on (remove any that don't apply):

proxb commented 6 years ago

@beargle Any chance you could look at using the method shown here: https://github.com/proxb/PoshRSJob/issues/177#issuecomment-371038089? It would be nice to keep all module importing down to a single parameter if possible. If it doesn't work out though, I can move forward to accept this PR.

beargle commented 6 years ago

@proxb Sure, I saw the comment, but am not sold on readability of pre-processing module paths before passing to Start-RSJob.

It seems more intuitive to be able to pass a single "root" module path, so that everything (properly organized as importable, of course) gets loaded into the runspace jobs.

I totally get the usability issue with having two parameters that could be used for module import...do you think it would be confusing to wrap functionality of both InitialSessionState.ImportPSModule and InitialSessionState.ImportPSModulesFromPath into the single -ModulesToImport parameter?

proxb commented 6 years ago

do you think it would be confusing to wrap functionality of both InitialSessionState.ImportPSModule and InitialSessionState.ImportPSModulesFromPath into the single -ModulesToImport parameter?

@beargle I think that would be a better way to go at least to support both the module name and module path requirement even though it will require a little more work to handle both of the possible values being supplied to the parameter. While I get the ease of just supplying a single root math containing all of the modules, I'm just not sure about having multiple module import parameters.

beargle commented 6 years ago

@proxb Makes sense, I've consolidated the module path import into existing -ModulesToImport parameter, and updated the original PR text. It should accept these different ways of specifying modules for import:

Let me know your thoughts, thanks!