Remove global scope from module variables

[ALuckyGuy]

The module defines a number of global variables: Jobs, JobId, JobCleanUp, RunspacePools and RunspacePoolCleanup. These variables really ought to have script scope, not global scope, to avoid name conflicts. $Jobs and $JobId are particularly bad since these are variable names that are very likely for a user script to use.

In the very least global variables should be renamed to something less likely to have a name conflict, such as $PoshRSJob_JobIDs, etc.

[proxb]

I completely agree with this and it was one of my undocumented things to do. This will hopefully give me a little more of a push to knock this out (along with some testing).

[proxb]

So setting the script scope has not yielded favorable results. I have updated the name to prepend each name with PoshRS_ to prevent naming collisions. I haven't spent a lot of time troubleshooting the issue with variable scope, but will continue to do so.

[proxb]

Gained more traction on the variable issue so that it appears to properly import from the module but more testing is needed.

[proxb]

The latest update should resolve this. Can you test and verify for me?

[ALuckyGuy]

Will do

[ALuckyGuy]

This doesn't appear to be working correctly in 1.5.7.1.

First, immediately after importing the module, execute

 DIR VARIABLE: 

Doing so in v3 reveals the PoshRS variables are global. Doing so in v2 produces an error when it tries to output the PoshRS variables:

Name                           Value
----                           -----
$                              PoshRSJob
?                              True
^                              import-module
_
args                           {}
ConfirmPreference              High
ConsoleFileName
DebugPreference                SilentlyContinue
Error                          {}
ErrorActionPreference          Continue
ErrorView                      NormalView
ExecutionContext               System.Management.Automation.EngineIntrinsics
false                          False
FormatEnumerationLimit         4
Host                           System.Management.Automation.Internal.Host.InternalHost
input                          System.Collections.ArrayList+ArrayListEnumeratorSimple
MaximumAliasCount              4096
MaximumDriveCount              4096
MaximumErrorCount              256
MaximumFunctionCount           4096
MaximumHistoryCount            64
MaximumVariableCount           4096
MyInvocation                   System.Management.Automation.InvocationInfo
NestedPromptLevel              0
null
OutputEncoding                 System.Text.ASCIIEncoding
PID                            2852
format-default : Object reference not set to an instance of an object.
    + CategoryInfo          : NotSpecified: (:) [format-default], NullReferenceException
    + FullyQualifiedErrorId : System.NullReferenceException,Microsoft.PowerShell.Commands.FormatDefaultCommand

I'm also running into errors with some non-trivial scripts in v2... errors in start-rsjob not being able to find $PoshRS_RunspacePools. I'm not entirely sure what the source of the trouble is and why some simple scripts work, but after changing all the -Scope Script references to -Scope Global in PoshRSJob.psm1, the problem goes away completely.

[proxb]

I'm thinking I am going to revert this back to being Global: scope as this gets cleaned up if the module is removed using Remove-Module and the likely hood of a naming collision is almost nonexistent with the PoshRS* variable names.

[proxb]

Weird, that is the first time I have seen the auto close when I publish an update. I made these Global variables (with the updated name to avoid conflicts) which will probably close this anyways.