Can't list any NuGet/Cache Packages

[cpyfferoen]

I must be doing something fundamentally wrong.
Everything with the private feed seems to be working great! When I try accessing the cache, i get a lot of 404 errors, or using nuget list - it tells me no packages found. I left everything default in the container.

My IPAddress replaced with "liget" -
nuget list Prism -Source http://liget:9011/api/cache/v3/index.json
this works fine when pointing to nuget.org but i do get a warning when I run it against liget
WARNING: This version of nuget.exe does not support listing packages from package source

working query
https://api-v2v3search-0.nuget.org/query?q=NuGet.Versioning&prerelease=false
non-working, i tried every variation of api/cache/v3/index.json
http://liget:9011/api/cache/v3/index.json/query?q=NuGet.Versioning&prerelease=false

I have confirmed internet access by both the VM and Container where this is running.. so.... now i'm stuck.

[tomzo]

Hi @cpyfferoen
Thanks for feedback.

It looks like a bug - there is no search endpoint in liget for cached packages.

The /api/cache/v3/index.json returns search service address with something like

"@id":"http://liget/api/cache/v3/search","@type":"SearchQueryService"

But there is no carter module which handles that endpoint.
This can be fixed in 2 ways:

• fix index.json to simply return search service of nuget.org, so that clients talk directly to nuget.org
• add the endpoint so that liget will proxy all requests to nuget.org

We are not indexing public packages so those are the only 2 options.

[cpyfferoen]

Well, I'm a solid WPF developer, but I don't know what the heck i'm doing in anything Web.

Your instructions seem to indicate the problem can be solved quickly, and I'm certain it can by someone who knows what they are doing. I tried and failed to debug this in Windows, and then brought it all up in ubuntu as well (got it running, then the localhost:1234 thing, then it was redirecting to nuget.org). And basically I needed it to debug for my guess and check style of coding web things.

Basically I'm out of my allotted time to solve this. Might keep digging in on my own time.

[tomzo]

Your instructions seem to indicate the problem can be solved quickly, and I'm certain it can by someone who knows what they are doing

Don't know why you think that.. I'd say it would take me an hour to fix it, if I identified the cause correctly above. Still it needs to have test cases added at every level because its a new use case.
I can fix it soon^TM, but currently I have other work, so this has to wait.

[tomzo]

After digging into this, I found that search service returns quite a complex object
which includes registration endpoint. So every response from nuget would have to be rewritten with updated registration url.
So far I removed the search service from http://liget/api/cache/v3/index.json and added readme that this is not supported.
@cpyfferoen I wonder why you need to use nuget list in the first place? It is a very broad query, so what workflow requires this?

[cpyfferoen]

Well I was trying to point Visual Studio at the cache as a pass thru to nuget.org (for machines w/o access to the internet, but can see the Liget machine). nuget list was just a test I was running as a sanity "does this work" check.

[tomzo]

Thanks. Now I get your use case.
I'll see what I can do. No promises though...

[loic-sharma]

FYI @tomzo, BaGet provides a BaGet.Protocol package that should make this easier to implement than using NuGet client's libraries:

1. You'll want to use ServiceIndexService.GetSearchUrlAsync to find the upstream NuGet server's search endpoint
2. Using the endpoint from step 1, build a search URL using this documentation
3. Pass the URL you built into SearchClient.GetSearchResultsAsync to get POCOs.

It's pretty low-level at this point, but I'll build up more abstractions in the future. Let me know if you're interested, I can help if needed.

[loic-sharma]

Oh and you can use the protocol library for your responses too. For example, here is how BaGet builds its search responses.

[tomzo]

Hi @loic-sharma

I am definitely not a fan of the nuget client libraries. No idea why they are crafted this way....
While I certainly want to use them in integration tests, but not necessarily for server implementation.
Will look into baget.protocol, thanks.

[loic-sharma]

I am definitely not a fan of the nuget client libraries. No idea why they are crafted this way....

Yeah, we're aware of this. The NuGet client has to support many different tools (nuget.exe, dotnet.exe, Visual Studio) and protocols (v2 and v3). The coupling between all of these is tight enough that it's difficult to improve quickly.

The server team has started an effort to provide better libraries, but we're doing this incrementally as the need arises (see this documentation). I'm hoping to jump start this effort with BaGet.

[tomzo]

@cpyfferoen I have created a PR #11 which implements the search endpoint for cached packages. Although your original nuget list command still does not work. I have an integration test which uses the same nuget client as visual studio and this is now working.
If this is of any interest to you, please try it with visual studio in your setup.

[viceice]

I'm interested in this feature, because i'm using renovate to update my nuget deps and i would like to use liget as proxy. renovate depends on SearchQueryService to find packages.