VLC installation using Provider Name ChocolateyGet

[kundankumar-tudip]

I am facing an issue while installing VLC using the following command:

Install-Module -Name ChocolateyGet -AllowClobber
Install-Package -Name vlc -ProviderName ChocolateyGet -Source chocolatey

Output: "WARNING: Cannot bind argument to parameter 'source' because it is an empty string.

Please guide me so that I can install the VLC media player using chocolatey.

[kundankumar-tudip]

I am facing an issue while installing VLC using the following command:

Install-Module -Name ChocolateyGet -AllowClobber
Install-Package -Name vlc -ProviderName ChocolateyGet -Source chocolatey

Output: "WARNING: Cannot bind argument to parameter 'source' because it is an empty string.

Please guide me so that I can install the VLC media player using chocolatey.

• Although I have installed the VLC media player on 03/25/2021 using the same method but this time I am facing an issue.

[ethanbergstrom]

Hey @kundankumar-tudip

What version of PowerShell are you using? 5.1 and below, or 7.0.1 and above?

[nwannerjc]

I have the same issue using Install-Package or Find-Package:
`
PS C:\Windows\system32> Find-Package -ProviderName ChocolateyGet -Name 7zip
WARNING: Cannot bind argument to parameter 'source' because it is an empty string.
Find-Package : No match was found for the specified search criteria and package name '7zip'. Try Get-PackageSource to
see all available registered package sources.
At line:1 char:1

• Find-Package -ProviderName ChocolateyGet -Name 7zip

•   + CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exceptio
   n
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage
  
  

PS C:\Windows\system32> $psversiontable

Name Value

---

PSVersion 5.1.19041.610
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.610
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

PS C:\Windows\system32> Get-PackageProvider

Name Version DynamicOptions

---

ChocolateyGet 3.0.0.0 AdditionalArguments, AcceptLicense
msi 3.0.0.0 AdditionalArguments
msu 3.0.0.0
NuGet 3.0.0.1 Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag...
PowerShellGet 1.0.0.1 PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, ...
Programs 3.0.0.0 IncludeWindowsInstaller, IncludeSystemComponent

PS C:\Windows\system32> Get-PackageSource

Name ProviderName IsTrusted Location

---

PSGallery PowerShellGet False https://www.powershellgallery.com/api/v2
chocolatey ChocolateyGet True https://chocolatey.org/api/v2/
`

[kundankumar-tudip]

Hey @kundankumar-tudip

What version of PowerShell are you using? 5.1 and below, or 7.0.1 and above?

Hi @ethanbergstrom

I am getting this issue on PS version 5.1 but on PS 7.0.2 works fine.

[nwannerjc]

@ethanbergstrom
I see that is works on 7.1 but not on 5.1 also.
Do you have a solution for 5.1 or know why it is not working on 5.1?

[dmaplesjc]

I am seeing the same problem with v2.1.0 on Powershell 5.1.18362.1171 on Windows 10 Pro.

PS C:\WINDOWS\system32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.18362.1171
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.18362.1171
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1


PS C:\WINDOWS\system32> Get-PackageProvider

Name                     Version          DynamicOptions
----                     -------          --------------
ChocolateyGet            2.1.0.0          AdditionalArguments, AcceptLicense
msi                      3.0.0.0          AdditionalArguments
msu                      3.0.0.0
NuGet                    3.0.0.1          Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag, Contains, AllowPrereleaseVersions, ConfigFile, SkipValidate
PowerShellGet            1.0.0.1          PackageManagementProvider, Type, Scope, AllowClobber, SkipPublisherCheck, InstallUpdate, NoPathUpdate, Filter, Tag, Includes, DscResource, RoleCapability, Co...
Programs                 3.0.0.0          IncludeWindowsInstaller, IncludeSystemComponent


PS C:\WINDOWS\system32> Find-Package -ProviderName ChocolateyGet -Name 7zip
WARNING: Cannot bind argument to parameter 'source' because it is an empty string.
Find-Package : No match was found for the specified search criteria and package name '7zip'. Try Get-PackageSource to see all available registered package sources.
At line:1 char:1
+ Find-Package -ProviderName ChocolateyGet -Name 7zip
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft.Power...ets.FindPackage:FindPackage) [Find-Package], Exception
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.FindPackage

PS C:\WINDOWS\system32>

[ethanbergstrom]

I haven't had a chance to look into it yet, but it's odd you're suddenly seeing it even with previous versions of the module. It almost makes me wonder if something changed on the Chocolatey.org side, but I don't want to speculate too much until I've dug into it.

[ethanbergstrom]

Closed by mistake

[ethanbergstrom]

It looks like there's something changed in the behavior between the Chocolatey API and Chocolatey.org after their maintenance the other night. FYI @ferventcoder.

When I invoke ChocolateyGet v2.1.0 under PowerShell 5.1 using the native API using https://chocolatey.org/api/v2/ as the source, it fails, but against a private Artifactory NuGet repo, it works like it always has. If I switch to using the choco.exe command line method ($env:CHOCO_CLI = $true in a fresh session before invoking the provider), both repositories work.

I'm going to release an emergency cut of v3 module that switches the default behavior under PowerShell 5.1 to use the command line method instead of the native API.

If for some reason you're not able to take that update, you'll need to preface your scripts with $env:CHOCO_CLI = $true (or set 'CHOCO_CLI' = 'true' in Windows environment variables) to tell the module to use the command line method.

[kundankumar-tudip]

It looks like there's something changed in the behavior between the Chocolatey API and Chocolatey.org after their maintenance the other night.

When I invoke ChocolateyGet v2.1.0 under PowerShell 5.1 using the native API using https://chocolatey.org/api/v2/ as the source, it fails, but against a private Artifactory NuGet repo, it works like it always has. If I switch to using the choco.exe command line method ($env:CHOCO_CLI = $true in a fresh session before invoking the provider), both repositories work.

I'm going to release an emergency cut of v3 module that switches the default behavior under PowerShell 5.1 to use the command line method instead of the native API.

If for some reason you're not able to take that update, you'll need to preface your scripts with $env:CHOCO_CLI = $true (or set 'CHOCO_CLI' = 'true' in Windows environment variables) to tell the module to use the command line method.

Hi @ethanbergstrom

Thanks for the update. Now, it works.

[ethanbergstrom]

Thanks for your patience, folks.

ChocolateyGet v3.1.1 is now up on PSGallery and in my Windows Sandbox tests once again works correctly against Chocolatey.org's package repository under both PowerShell 5.1 and 7.x.

This new version no longer includes a copy of the Chocolatey .NET library, so it's BYOC (Bring Your Own Chocolatey). The provider will ask to install Chocolatey for you if it's not already installed, which you can bypass by passing -Force and install Chocolatey 0.10.13 automatically (PowerShell DSC will force automatic install for you). I recommend 0.10.13 instead of the latest version 0.10.15 due to #20.

If for some reason you're not able to take that update (ex: using a version of PowerShell older than 5.1), you'll need to preface your scripts with $env:CHOCO_CLI = $true to tell the older version of the module to use the command line method.

[ethanbergstrom]

Looking into this a little more, I figured out what the issue was. It appears that Chocolatey.org is no longer returning source information from package requests:

I'd been keying off of that field to return correct source information. I'm going to try to cut a release on the 2.1 line for folks who have a hard dependency on the module shipping the embedded Chocolatey .NET library or an older version of PowerShell.

[ethanbergstrom]

Version 2.1.1 is now out on PowerShell Gallery to correct this issue for anyone who's not able to upgrade to version 3.x. It fills in a generic 'Chocolatey' source name if one's not provided by the repository - 6168877