Skip to content

Install-Package support #487

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

Open
ili101 opened this issue Sep 19, 2021 · 7 comments
Open

Install-Package support #487

ili101 opened this issue Sep 19, 2021 · 7 comments

Comments

@ili101
Copy link

ili101 commented Sep 19, 2021

Summary of the new feature / enhancement

From what I understated this module suppose to eventually replace PackageManagement and PowerShellGetv2
In https://github.com/OneGet/oneget it states that This module is currently not in development. The PowerShell/PowerShellGet repository is actively in development as the new PowerShell package manager.

So what are the replacements for *-Package Cmdlets? I tried the following:

Register-PSResourceRepository -Name 'nuget.org' -URL 'http://www.nuget.org/api/v2'

Find-PSResource -Name MailKit -Repository nuget.org
# Returns package info like MailKit 2.15.0.0 etc.

Install-PSResource -Name Microsoft.NETCore.Platforms -Repository nuget.org -Verbose
# [Error] Install-PSResource: Module manifest file: ...\Microsoft.NETCore.Platforms.psd1 does not exist. This is not a valid PowerShell module.

So repository installed and searched successfully but installing is blocked.

The other problem is the "dependency loop"
As reported here OneGet/oneget#475 Install-Package cannot actually work on most of the packages without -SkipDependencies as it resolves dependencies incorrectly and will return loop error without it. The last statement in this issue is:

@GehanPanapitiya hopefully it will be addressed in new PowerShellGet v3

But Install-PSResource doesn't have -SkipDependencies and the loop bug here is worst as it's not even detected:

Install-Package -Name MailKit -Verbose
# [Error] Install-Package: Dependency loop detected for package 'MailKit'.

# This works
Install-Package -Name MailKit -SkipDependencies -Verbose

# This will hang forever (probably spamming the repo with request in a loop?)
Install-PSResource -Name MailKit -Repository nuget.org -Verbose
# Loops silently forever?

So what is the plan/roadmap on this? Will packages be supported on Install-PSResource or some new commend? As PackageManagement is not developed it will probably will never be fixed there.

Proposed technical implementation details (optional)

No response

@StevenBucher98
Copy link
Collaborator

Thanks @ili101! Right now we are focused on supporting specifically PowerShell packages but plan to incorporate .nupkg packages in the future. We are currently working on finishing cmdlet parameters and then work on supporting .nupkg scenarios. We will create a new issue in our repo referencing the OneGet issue you link, it can be seen here #491

@rdbartram
Copy link

I'm experiencing this too and would like to see this working. thanks!

@SphenicPaul
Copy link

I've also hit this issue with Install-Package and Save-Package (in PackageManagement module v1.4.7)- They hit a Dependency loop detected for package error/warning and fail to save/install the package(s).

As there doesn't seem to be a -SkipDependencies switch I could use, I've ended up having to use the NuGet CLI, install option...
https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-nuget-cli#install-a-package ... which, actually seems to resolve and install the dependencies correctly, which allowed me to work around this for now.

@o-l-a-v
Copy link
Contributor

o-l-a-v commented Mar 29, 2024

Why allow to even install nuget.org resources when they're not handled properly? Take NuGet.Versioning for instance, it installs to $env:PSModulePath, but can't be imported as a module.

Steps to reproduce:

# Register NuGet as a resource repository
Register-PSResourceRepository -Name 'NuGet' -Priority 60 -Uri 'https://api.nuget.org/v3/index.json'

# Find latest version of NuGet.Versioning from nuget.org
Find-PSResource -Repository 'NuGet' -Name 'NuGet.Versioning' | Format-List

# Install it
Install-PSResource -Scope 'CurrentUser' -Repository 'NuGet' -TrustRepository -Name 'NuGet.Versioning'

# Find it locally
Get-InstalledPSResource -Name 'NuGet.Versioning' | Format-List

# Try to import it - Does not work
Import-Module -Name 'NuGet.Versioning'

# One can add it as type though
## Find info for latest installed version
$NuGetVersioning = Get-InstalledPSResource -Name 'NuGet.Versioning' | Sort-Object -Property 'Version' -Descending | Select-Object -First 1
## Add type
Add-Type -Path ([System.IO.Path]::Combine($NuGetVersioning.'InstalledLocation','NuGet.Versioning',$NuGetVersioning.Version.ToString(),'lib','netstandard2.0','NuGet.Versioning.dll'))
## Test it
[NuGet.Versioning.NuGetVersion]'1.2.3'

@ThomasNieto
Copy link
Contributor

@o-l-a-v I don't think NuGet.org packages are supported. It is supposed to be on their roadmap from one of the community calls but not sure there is an issue for the enhancement.

@o-l-a-v
Copy link
Contributor

o-l-a-v commented Mar 30, 2024

@ThomasNieto This was more of a bug report. I assume there should be some metadata present that tells PSResourceGet whether a nuget artifact is a PowerShell resouce. And when this is not present, PSResourceGet should not attempt anything.

Edit: I should stop assuming things. Does not seem there's metadata available to tell whether a nuget v3 package / artifact is for PowerShell.

Maybe one could check when the package is unpackaged to temp before moving it to PSModulePath.

  • If <package_name> decompressed root contains <package_name>.psm1 (module) or <package_name>.ps1> (script) = Supported.

@ThomasNieto
Copy link
Contributor

Yeah I agree it's a bug. PSRG should be checking the package tags for the tag indicating it's a module or script and error if either aren't found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants