Closed kzu closed 3 years ago
I believe when All was selected to aggregate all NuGet sources the VS NuGet UI would index the packages using lucene locally and make it searchable. At some point this seems to have broken in VS.
When selecting a single feed it has always been an unfiltered list in VS.
There are a couple options for fixing this
Sleet feeds could point to an external service which provides search for the static feed. Something like an azure function that reads the static files and applies basic filtering based on the search query.
Maybe sleet could have command like sleet browse <Sleet service index>
that launches a minimal NuGet service that knows how to filter. You could run this on your local machine / host it somewhere externally.
On n2 I was thinking in Azure function that does 2 things a badge for the nuget version and search ?! Can n1 be implemented now ? seems this is what we should do if we don't support search
Maybe sleet could have command like sleet browse
that launches a minimal NuGet service that knows how to filter.
Running a local search is an interesting idea. I think it would have to proxy the entire feed and the client would have to point to that since index.json contains the url of the search service. Otherwise the online feed would have to point to a localhost url.
Could part of BaGet be used in an azure function to index a sleet feed?
On n2 I was thinking in Azure function that does 2 things a badge for the nuget version and search ?!
I haven't looked into badge support before, is a function needed for this or would a static file work? Ex: id.latest.png
Can n1 be implemented now ? seems this is what we should do if we don't support search
It would require a change to NuGet client. But I'm open to adding a property to sleet's static search results to indicate it.
It would require a change to NuGet client. But I'm open to adding a property to sleet's static search results to indicate it.
I would create a new NuGet protocol resource to do this. A "here's a full view of the world" resource, similar to brew's formula.json
file.
Could part of BaGet be used in an azure function to index a sleet feed?
BaGet has basic mirroring off an upstream NuGet package source. This doesn't support search mirroring, but I'd be open to extending BaGet to support Sleet! This should be do-able in an Azure Function. If you like the new resource idea, I could add this same protocol to BaGet too. Do you have a OneWeek project already? 😄
A "here's a full view of the world" resource, similar to brew's formula.json file.
Sleet's search file contains all possible package results today in one file, and orders them alphabetically. Is that the same as what formula.json does, or is there more going on there?
This doesn't support search mirroring
What about when there is no upstream, how does BaGet return search results for a simple feed?
Do you have a OneWeek project already?
I'm out that week unfortunately or I'd definitely be up for it!
Sleet's search file contains all possible package results today in one file, and orders them alphabetically. Is that the same as what formula.json does, or is there more going on there?
It's the same idea, yup. Sleet's search file seems perfectly reasonable to fulfill the search protocol, but I think that a new resource in the service index would be a great way to clarify the intent for clients like BaGet.
What about when there is no upstream, how does BaGet return search results for a simple feed?
BaGet supports full-text search on your database of choice. You can also use Azure Search if you're willing to setup the resources. We would need to add some sort of in-memory search to BaGet to support this new scenario.
Do you have a OneWeek project already?
I'm out that week unfortunately or I'd definitely be up for it!
😢
Not sure if it repros in 16.1, but in my 16.2, search in a sleet feed from VS just returns all the packages in the index, no filtering performed at all :(