Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import-Module should support nupkg files #7259

Open
Jaykul opened this issue Jul 10, 2018 · 6 comments

Comments

@Jaykul
Copy link

commented Jul 10, 2018

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

This comment has been minimized.

Copy link

commented Jul 11, 2018

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

@mklement0

This comment has been minimized.

Copy link
Contributor

commented Jul 12, 2018

Related: #6724

@Jaykul

This comment has been minimized.

Copy link
Author

commented Jul 29, 2018

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

This comment has been minimized.

Copy link
Contributor

commented 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-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

This comment has been minimized.

Copy link
Author

commented Feb 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2019

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

@SteveL-MSFT SteveL-MSFT modified the milestones: Future, 6.3-Consider Feb 19, 2019

@SteveL-MSFT SteveL-MSFT modified the milestones: 7.0-Consider, Future Jul 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.