Powershell: Import-Module should support nupkg files

[Jaykul]

The goal here is for manual module install instructions to just be:

Put the .nupkg file in your PSModulePath

This seems like an obvious next step in the ease-of-use story for cross-platform modules. PowerShell should inherently support nupkg files similar to the way the dotnet and msbuild systems do: dynamically unpacking and loading the platform-appropriate files on demand, keeping the whole module (all platforms) on disk in the .nupkg file.

Not only would this reduce the disk space needed for modules that are installed but infrequently used, it would make installing modules via sneaker-net so much easier: no need to manually figure out the folder paths! No more explaining that...

the module file has to be in a sub-directory of a folder that's in your PSModulePath, but the sub-directory name has to _exactly_ match the psd1 file name (without the extension), and it might have an extra sub-directory with a number, but in that case, it has to _exactly_ match the version number that's _inside_ the psd1...

Bonus points if you implement it with .nupkg and also .psmodule so that we can implement file-type association for "install" in Windows (i.e. if you download a .psmodule and double-click, PowerShell will put it in your user scope location).

NOTE: support for nupkg files should consider existing requests regarding assembly dependencies, including #3901 and #6642

[jakerobinson]

How would this work for modules that have dependencies on other modules?

[mklement0]

Related: #6724

[Jaykul]

If it were up to me, @jakerobinson, you'd get a warning during install for each dependency you didn't already have installed.

It could also support finding them as files in the same folder as the one you're installing, in which case it would be as user friendly as if you'd configured the folder as a repository.

[mklement0]

Thinking some more about this: #6724 (which I created) is not just related, it is an _alternative proposal_ for solving the same problem (it turned out not to be; it tries to solve a related, but distinct problem - see next comment):

It suggests integrating the NuGet-package support into Add-Type rather than Import-Module.

Given that NuGet packages aren't PS modules, but general-purpose .NET assemblies, integration with Add-Type makes more sense to me, which would then enable commands such as the following:

# Install a NuGet package from the NuGet Gallery and add its types to the session.
Install-Package -Provider nuget Mono.Posix.NETStandard  | Add-Type

# Add the types of an already installed NuGet package to the session.
Add-Type -Package Mono.Posix.NETStandard 

# Equivalent, via Get-Package.
Get-Package Mono.Posix.NETStandard | Add-Type

Add-Type would locate packages by their standard locations, as already used by Install-Package (e.g., /usr/local/share/PackageManagement/NuGet/Packages (all-users) and $HOME/.local/share/PackageManagement/NuGet/Packages (current-user)).

If you wanted to add NuGet packages manually, you'd have to place them in one of those locations.

The logic to automatically unpack a *.nupkg file in those locations - while keeping only platform-relevant files - could also be built into Add-Type.

Separately or alternatively, if keeping platform-inapplicable files never makes sense, Install-Package could perform optimized unpacking to begin with.

[Jaykul]

I agree that we should load assemblies from nupkg @mklement0, but it's not an alternative, it's solving a different set of problems (including the cross-platform ones which I also raised when I asked for it, in #3091 😉). That's arguably the first step.

However, about PowerShell modules. They are shipped in .nupkg packages the same way that .NET assemblies are -- we use a different default web repository to avoid confusing them, but they are still nupkg files which get extracted by Install-Package

So this request is to support importing modules from nupkg without pre-extracting them. I.e. extract them on demand the way dotnet does for builds, as we've already suggested for assemblies...

[mklement0]

I appreciate the clarification, @Jaykul - all makes sense (I've amended my previous comment).