Add dotnet package search

[Nigusu-Allehu]

Bug

Fixes: NuGet/Home#6060

Regression? Last working version:

Description

ℹ️ Note : This PR is merged into dev-feature-migrate-systemcommandline, as there is some migration work to be done.

• add a new command dotnet package search

• Here is the dotnet sdk side : Add dotnet package search dotnet/sdk#36289

• Here is what a dotnet package search nuget would look like

PR Checklist

• PR has a meaningful title

• PR has a linked issue.

• Described changes

• Tests

  • Automated tests added
  • OR
  • Test exception
  • OR
  • N/A

• Documentation

  • Documentation PR or issue filled :
    • Design spec Spec for dotnet package search : implements a search functionality. Home#12886
    • Documentation: Add dotnet package search documentation dotnet/docs#37747
  • OR
  • N/A

[donnie-msft]

Very meticulous work here, good job!
I'm not completely done reviewing, but needed to submit what I have so far.

[nkolev92]

Looks great!

Most of my feedback is minor.
I think we have some classes for which we can add some more unit tests.

[nkolev92]

Excellent job!

I do have 1 question, but addressing that feedback in a future PR is fine with me.

Given that this is a very large PR, I'd try to get approval from more than just 1 person.

[nkolev92]

Say we have 2 sources, only 1 responds, but 1 times out. Do we want the exit to be 0?
It's a genuine question. Have you checked how nuget.exe list or nuget.exe handle that?

[danmoseley]

I hope we would still wait for and display results from other feeds in this case. For internal projects we often have many feeds and who knows whether one will have a problem for some reason..

[nkolev92]

Yep, I agree, and it seems like the implementation is doing that as well (displaying partial results).

Just curious what should the exit code would be when we have these partial results.

[Nigusu-Allehu]

Currently the way I have it implemented is so that if a search times out for one source, we print an error, skip the source, and we continue to the next source. The only situation where we exit with 1 is if the command is badly formatted or an invalid source is specified. If the command can be parsed and the source identified, it will always exit with 0. However, if anything goes wrong for a specific source search, the appropriate error is printed out and the search continues to the next source.

From my understanding, nuget.exe list on the other hand does not catch such exceptions, it just lets them be thrown. The nuget.exe program is designed so that if any command throws an exception, it exits with 1 and prints the error. Therefore a nuget.exe list command in the situation a source times out, will exit 1 and print the exception.

I could also have dotnet package search exit with 1 rather than continuing to search. I think I should make it part of the discussion in the "additional options" spec review.

[nkolev92]

I think it's ok if we complete the operations for all sources and end up with an exit code for 1.
A single source failing would change the result for other sources, unlike say restore for example, where a single source being inaccessible could actually change what gets resolved.

[donnie-msft]

Looks good! I left some nits and opinions which you can address now, later, or probably just ignore.