-
Notifications
You must be signed in to change notification settings - Fork 129
Investigation on supporting module isolation #164
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
Conversation
|
||
### Import-Module -Isolated | ||
|
||
The idea is simple: Add the switch parameter `-Isolated` to `Import-Module`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regardless of how we implement this, I don't think we can require the user to use a switch to specify isolation. The majority of users won't understand why this is needed nor when to use it. Only in developer scenarios would such a switch make sense. For regular users, it needs to be transparent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For regular users, it needs to be transparent.
That makes sense, and I think AssemblyLoadContext.AssemblyResolve
event might be a better fit for solving the conflicting NewtonSoft.Json
issue, in a transparent way (see the second section in the Alternative Considerations
).
As for the module isolation, it won't work. The introduced type identity issue will make it impossible to be transparent to the user.
We could split the area on two parts:
In second case it seems we could easily resolve the problem internally in the module. It doesn’t even require any changes to the engine - only documentation. Although we could add some API for developers to create code (ALC) in one standard. Related question. CoreFX can also load assemblies (NewtonSoft too!) - and it is not clear can we change the CoreFX context or not. As for first case. It looks like a dialectic - we want isolation, but we want everything in global! :-) So what do we want? I believe that isolation from global is implied.
|
Not exactly sure about what you mean by
The term |
If it's a module with a custom load context, then the type resolution will search assemblies from the custom-ALC and then the default-ALC to find the `TypeName`. | ||
Otherwise, the type resolution will search the default-ALC only. | ||
|
||
So in the above imagined scenario, it's possible to make it work as expected if you construct the object using `[M\B::C]` from the default-ALC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use [M::B::C]
. Using \
is Windows style and we will have to consider /
. Although with ::
we could get difficulties in parser with provider form.
Note: This RFC focuses on the module-level isolation, but it's written with the purpose to be withdrawn.
While researching the feasibility of this idea, I realized that it's impossible to have it well supported due to the challenges discussed below.
This RFC serves as a summary of the research to explain the reasons why we will not proceed with this idea.
In the
Alternate Proposals and Considerations
section, I briefly discuss theRunspace-level
isolation and usingAssemblyLoadContext.Default.Resolving
to solve the problem of conflictingNewtonSoft.Json
assembly.I think
Runspace-level
isolation is more promising and useful. I can write another RFC about how to supportRunspace-level
isolation in PowerShell.