Repository navigation
Import-Module should support nupkg files #7259
Description
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
Activity
jakerobinson commentedon Jul 11, 2018
How would this work for modules that have dependencies on other modules?
mklement0 commentedon Jul 12, 2018
Related: #6724
Jaykul commentedon Jul 29, 2018
If it were up to me, Jake Robinson (@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 commentedon Jul 31, 2018
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-Typerather thanImport-Module.Given that NuGet packages aren't PS modules, but general-purpose .NET assemblies, integration with
Add-Typemakes more sense to me, which would then enable commands such as the following:Add-Typewould locate packages by their standard locations, as already used byInstall-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
*.nupkgfile in those locations - while keeping only platform-relevant files - could also be built intoAdd-Type.Separately or alternatively, if keeping platform-inapplicable files never makes sense,
Install-Packagecould perform optimized unpacking to begin with.Jaykul commentedon Feb 15, 2019
I agree that we should load assemblies from nupkg Michael Klement (@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
.nupkgpackages 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 byInstall-PackageSo this request is to support importing modules from nupkg without pre-extracting them. I.e. extract them on demand the way
dotnetdoes for builds, as we've already suggested for assemblies...mklement0 commentedon Feb 16, 2019
I appreciate the clarification, Joel Bennett (@Jaykul) - all makes sense (I've amended my previous comment).
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.