PSGet needs to support selectively installing modules that support multiple platform runtimes

[SteveL-MSFT]

As more module authors are trying to support cross-platform and cross-PowerShell (Windows PowerShell versions and PSCore6), PSGet should adopt same packaging as nupkg for multiple runtimes. Conceptually, the module author would layout their module like:

• MyModule
  • Runtimes
    • osx-x64
    • win-x64
    • win-x86
    • linux-x64
    • linux-arm32

When user does install-module, it should only install the bits for the runtime that matches the system. save-module should probably save all the runtimes. Similar structure for differentiating PowerShell versions.

[edyoung]

Seems like this would require an update to the packaging format because older versions of PowerShellGet would not understand them. So new-style modules would only be installable with a sufficiently-recent version of PowerShellGet. I'm not sure how much of an issue that is for module authors and users.

One alternative possibility would be to leave install-time alone (just install every runtime) and have some standardized code that can be injected into the module to load the appropriate runtime's resources at import-module time.

[SteveL-MSFT]

What is the support lifecycle for PSGet? Seems like we should have users move forward to latest version of PSGet. Is the packaging format versioned for PSGet?

[bmanikm]

Yes, packaging format is versioned in PSGet. During the install operation, PSGet throws an error to update the PSGet version if it can't understand the newer format versions.

[vexx32]

What's the status on this? Would be really nice to get this support in PSGet. 🙂

[Jaykul]

This really isn't the whole answer -- it would require every module to actually package copies of every dependency.

If we think the right solution is to build NPM-like warrens of dependencies inside every module folder, we still need to do it the way NPM does: by taking dependencies on the assembly packages -- so they can be downloaded once to the nuget cache, and copied into every module that needs them.

That means PowerShellGet needs to support references to NuGet packages at install time.

Personally, I think PowerShell still needs to do the heavy lifting: we need to be able to add nuget package references to RequiredAssemblies:

1. PowerShellGet would download those dependencies and put one copy of them in the package cache (or a PowerShell assemblies folder)
2. PowerShell would go find them and load them

[KirkMunro]

I'm with Joel Bennett (@Jaykul) on this. The approach presented in the OP opens the door for dependency duplication across modules. Contrast that with the NestedModules or NuGet package approaches, which supports the creation of small, focused packages that are used as dependencies in multiple modules without creating unnecessary bloat when they are installed.

I'd like to see NuGet package support in PowerShellGet.

I'd also like to see support for additional variables in a module manifest as proposed in [PowerShell/PowerShell#9908](https://github.com/PowerShell/PowerShell/pull/9908], so that packages can be isolated in nested modules and reused across many modules without duplication.

The latter seems like lower hanging fruit that we could leverage quickly, although it doesn't cover processor architecture cross platform as well (maybe there should be a core PowerShell variable for that).

[SteveL-MSFT]

For the record, this issue is more than a year old! Since that time, I also would prefer the ability for a module to declare a dependency on a nupkg rather than bundling it with the module.

[Jaykul]

We also need to add WindowsARM :-p