Use shards subset code from conda

[dholth]

Description

Now that conda is getting a port of the conda-libmamba-solver shards fetcher, use the one that originates from conda.

I'd like to pass this in to the solver as a parameter, instead of having conda-libmamba-solver choose exactly which shards function it calls.

Fix #908

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[dholth]

implies requirement for conda >=26.5 although, since it's only in typing block it doesn't cause errors for older conda

[travishathaway]

Hi @dholth,

I have one question about the implementation. Did you consider pulling what I call, "the ol' switcheroo"? By that I mean simply just swapping all of the modules verbatim to conda and then adding stubs to conda-libmamba-solver so that the imports continue to work for backwards compatibility purposes.

I was expecting to see a lot more removals in this pull request than there currently are. If we're not going to remove the sharded repodata implementation in this pull request, I'd like to see us at least come up with a plan for removing it in the future.

I'm not against the dependency injection strategy. I just wonder if we can't make this even simpler.

Also, I think this is being blocked by this pull request, right? I wouldn't want to merge this while CONDA_REF is point at a feature branch.

[dholth]

Hi @dholth,

I have one question about the implementation. Did you consider pulling what I call, "the ol' switcheroo"? By that I mean simply just swapping all of the modules verbatim to conda and then adding stubs to conda-libmamba-solver so that the imports continue to work for backwards compatibility purposes.

I was expecting to see a lot more removals in this pull request than there currently are. If we're not going to remove the sharded repodata implementation in this pull request, I'd like to see us at least come up with a plan for removing it in the future.

I'm not against the dependency injection strategy. I just wonder if we can't make this even simpler.

Also, I think this is being blocked by this pull request, right? I wouldn't want to merge this while CONDA_REF is point at a feature branch.

Since this implementation does not import new symbols from conda at runtime (only in the type checking block), we have simplified the release sequencing problem. We could release this today or after the necessary conda release without breaking anything and without requiring conda > 26.5.

(We do run conda-libmamba-solver's tests against the related CONDA_REF so that it will call us passing its own shards implementation, so that we know that both pieces work together.)

This isn't the main reason I've pursued this strategy but it is a side effect. I want to let conda choose which repodata subset function it passes to the solver.

We would certainly plan on removing conda-libmamba-solver's shards implementation no later than the next release after this one.

[travishathaway]

@dholth,

That all makes sense. I think this is a fine approach then.

Are we waiting for main to be updated in conda/conda before we can merge this?