Repository navigation
Import-Module should support nupkg files #7259
Description
Activity
How would this work for modules that have dependencies on other modules?
Related: #6724
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.
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:# 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-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.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...Reacted by Rain Sallow (/u/ta11ow) and Michael KlementReacted by Rain Sallow (/u/ta11ow)I appreciate the clarification, Joel Bennett (@Jaykul) - all makes sense (I've amended my previous comment).
microsoft-github-policy-service commented
on Nov 16, 2023 ContributorThis 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 commented
on Nov 16, 2023 ContributorThis 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 commented
on Nov 16, 2023 ContributorThis 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 commented
on Nov 23, 2023 ContributorThis issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.
The goal here is for manual module install instructions to just be:
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
dotnetandmsbuildsystems 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...
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