Pinned (lockfile) Import support #27636
Replies: 3 comments 2 replies
-
|
Overall, I appreciate the direction of introducing a lockfile. Having modules and their dependencies loaded into the default Assembly Load Context (ALC) enables effective sharing of dependencies and objects across modules. However, further analysis is needed to validate whether isolating each loaded module within its own ALC would work reliably in all scenarios—particularly where cross-module object sharing is required. It is also important to assess whether this approach could introduce unnecessary runtime overhead or complexity. |
Beta Was this translation helpful? Give feedback.
-
|
To clarify, when I'm talking about dependencies I only mean PS package dependencies, not whatever .NET assemblies they are dragging along. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
@adityapatwardhan I'm willing to contribute the impl, assuming PS team agrees with this proposal in principle. |
Beta Was this translation helpful? Give feedback.
-
|
Attached the RFC based on actual code findings instead my guesses. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Problem
Historically the manifest's
RequiredModulesdependencies specification in PowerShell was overly optimistic wrt to semver and major version changes, i.e.Versiontranslates to[x,)- so, basically fromxonward, which is guaranteed to break at some point for all packages.RequiredVersionsolves the problem, but obviously can only be applied to the packages you author.We're seeing this issue most acutely with PowerCLI, which breaks even across minor revisions - installing 2 PowerCLI versions side-by-side is guaranteed to fail imports for older versions.
What I've tried
I've tried addressing it in user-space which kinda works, but apparently import does some things that cannot be replicated in user-space - I'm occasionally hitting hard to reproduce problems importing the ordered dependency graph. It looks like earlier in the import order module/command is not visible to the next module that depends on it, leading to either missing commandlet or "assembly already loaded" errors depending on w/ autoload is enabled. I must be missing something, but I don't see what.
Proposal
These days every package management comes with support for lockfiles, which I'm sure everyone could appreciate the importance of and it would be good to have that 1st class supported in PowerShell, at least for import.
How I imagine this working:
-LockFile <file name>and/or-LockMap <Hashmap>CDR mentioned above implements semantics of the proposed module mapping.
RFCNNNN-Import-Module-VersionMap.md
Beta Was this translation helpful? Give feedback.
All reactions