Provide a replacement for the old querier mechanism

[jchunkins]

Original Question in Slack

I started a discussion regarding a replacement for the old querier mechanism in slack which I have included below:

We have code that ties into the old querier mechanism from operator-registry where we would do the following:

1. convert declarative config to model representation using model, err := declcfg.ConvertToModel(cfg)
2. get the querier using querier, err = registry.NewQuerier(model)
3. use the querier so we can get the same results as would be provided via the GRPC interface, but without actual GRPC calls.

With the changes that went in sometime in January, this mechanism was replaced with the JSON cache. To do something similar to what I described above I’d either need public access to things that are currently private, (e.g. JSON.packageIndex) or I need a function like func FromDeclCfg(*cfg declcfg.DeclarativeConfig) *JSON that allows me to have a JSON instance built from a declarative config.

Given what I’ve described, is there some other option I’ve not considered or do we need a code change to make this happen?

Potential PRs To-date

After discussion with @joelanford, he created PR #1111 which would allow the JSON cache to be instantiated without incurring unnecessary processing for the use case described above. He would like to explore other options that don't rely on the cache mechanism to make for a cleaner API.

[jchunkins]

@joelanford I see that PR's related to this issue have been closed. We still have the problem where we're still relying on the Querier interface (we had to copy querier.go and define var umask which is needed by that code), so some form of way forward is still needed.

[jchunkins]

To be clear, we had to grab the relevant implementation from:

• https://github.com/operator-framework/operator-registry/blob/v1.26.2/pkg/registry/query.go
• https://github.com/operator-framework/operator-registry/blob/v1.26.2/pkg/registry/tar.go
• https://github.com/operator-framework/operator-registry/blob/v1.26.2/pkg/registry/syscall_unix.go
• https://github.com/operator-framework/operator-registry/blob/v1.26.2/pkg/registry/syscall_windows.go

[joelanford]

Yeah, I don't think the direction of that PR had any legs. But definitely understood that this is still an open problem. I'm thinking we need a different approach that doesn't use the cache. But that might mean a bit more refactoring of the pkgIndex to make it reusable outside of cache contexts.