Find-PSResource Name parameter must be provided

[ThomasNieto]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.

Steps to reproduce

Find-PSResource errors out without a -Name parameter passed.

Expected behavior

Returns resources

Actual behavior

Find-PSResource: Name parameter must be provided.

Error details

Exception             :
    Type        : System.Management.Automation.PSInvalidOperationException
    ErrorRecord :
        Exception             :
            Type    : System.Management.Automation.ParentContainsErrorRecordException
            Message : Name parameter must be provided.
            HResult : -2146233087
        CategoryInfo          : InvalidOperation: (:) [], ParentContainsErrorRecordException
        FullyQualifiedErrorId : InvalidOperation
    TargetSite  :
        Name          : ThrowTerminatingError
        DeclaringType : System.Management.Automation.MshCommandRuntime, System.Management.Automation, Version=7.2.3.500, Culture=neutral, PublicKeyToken=31bf3856ad364e35
        MemberType    : Method
        Module        : System.Management.Automation.dll
    Message     : Name parameter must be provided.
    Source      : System.Management.Automation
    HResult     : -2146233079
    StackTrace  :
   at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)
TargetObject          : Microsoft.PowerShell.PowerShellGet.Cmdlets.FindPSResource
CategoryInfo          : InvalidOperation: (Microsoft.PowerShel…lets.FindPSResource:FindPSResource) [Find-PSResource], PSInvalidOperationException
FullyQualifiedErrorId : NameParameterNotProvided,Microsoft.PowerShell.PowerShellGet.Cmdlets.FindPSResource
InvocationInfo        :
    MyCommand        : Find-PSResource
    ScriptLineNumber : 1
    OffsetInLine     : 1
    HistoryId        : 1
    Line             : Find-PSResource
    PositionMessage  : At line:1 char:1
                       + Find-PSResource
                       + ~~~~~~~~~~~~~~~
    InvocationName   : Find-PSResource
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1

Environment data

ModuleType Version    PreRelease Name                                ExportedCommands
---------- -------    ---------- ----                                ----------------
Binary     3.0.12     beta       PowerShellGet                       {Find-PSResource, Get-PSResource, Get-PSResourceRepository, Install-PSResource…}

Name                           Value
----                           -----
PSVersion                      7.2.3
PSEdition                      Core
GitCommitId                    7.2.3
OS                             Microsoft Windows 10.0.19043
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[SydneyhSmith]

Thanks @ThomasNieto will Find-PSResource -Name * work for your scenario? We are investigating this

[ThomasNieto]

Yes, that is a workaround but does not match the help or v2 behavior.

[SydneyhSmith]

Thanks we should definitely update the help and document this better! In terms of behavior change this is by design-- to reduce accidental load on the gallery and make sure folks are intentionally calling a find on an entire repo(s)

[ThomasNieto]

@SydneyhSmith the error message does not indicate that behavior and resolution at all, and will need to be updated. Also, what happened to having a local cache of the resource available on the gallery to reduce time and load on the gallery?

[mattcargile]

Find-PSResource * also works. Or either shorter with fimo *.

It is a tough call. Find-Module , choco search , and winget search all don't require an additional asterisk. On the other hand apt search requires a search argument. apt has been around much longer so maybe that convention has more weight though winget is a MS product. Hmmm..

[ThomasNieto]

If they're going to mimic behavior they should do the same thing that PowerShellGet v2 does. It doesn't require a mandatory parameter to return all items in the repository. In addition to that what about users that don't use the gallery but use an internal one where returning the entire repo doesn't cause issues. They would have to update their scripts compared to v2.

[mattcargile]

Folks would have to update because the function name changes too so they are going to have to touch the code at least once anyhow. Personally, I would expect to have to add an argument before calling it anyhow.

Is your use case caching modules from PSGallery for later use? Or are you using an on-premise/local repo and doing something like Find-Module | Install-Module to install everything? Or you just want to interactively pull all the modules ad-hoc?

[ThomasNieto]

They don't necessarily have to update scripts because the PowerShel team created the PowerShellCompat module which creates a compatability layer with the existing cmdlet names.

[mattcargile]

Yeah I did find that module. I guess I was counting that as a bit of a "touch" of the "code" or at least to all the systems. Much easier of a push I suppose.

Might have more luck working with that repo too and getting the empty parameter getting pushed down in that code base. If anything as I'm sure you know, you can always fork it and deploy that module.

[ThomasNieto]

Furthermore NuGet which PowerShellGet leverages for its package management capabilities, does not require any search filtering when querying the public repository. Why make this requirement on PowerShellGet when NuGet can do this just fine on their public repository?

nuget.exe list