Remove mamba

[AntoinePrv]

Mamba python code is no longer needed:

• conda-libmamba-solver uses libmambapy;
• boa now uses libmambapy.

Are we missing anything? All projects are strongly encouraged to move to full libmambapy.

👀 @isuruf @jonashaag @jaimergp @jezdez @Hind-M @Klaim @JohanMabille @wolfv

[jaimergp]

I think there's some conda-forge infra that uses mamba, but maybe it also imports libmambapy directly. Let me check!

[AntoinePrv]

More context:

• existing mamba package will continue to exists;
• there is a 1.x branch for bug fixes;
• but we consider that this is too much legacy to take to 2.0.

[jaimergp]

Yeah, the check-solvables component in conda-forge uses utils.load_channels(): https://github.com/regro/conda-forge-feedstock-check-solvable/blob/fa9b0500c09e39e9e3c228fd4f82a1a769079200/conda_forge_feedstock_check_solvable/mamba_solver.py#L39

This github search reveals some other users, like some asv plugin or bioconda infra.

I think those are workable, but maybe some folks would like to have some utilities in the libmambapy namespace, like libmambapy.utils or something?

[AntoinePrv]

In an ideal world we'd gave both a high and low level API. The low does nothing smart, purely, functional, and could be written to make another type of package manager (à la pixi). The high-level is a do conda things (such as load_channels) sort of API, that would be the building steps of micromamba.

@jaimergp for Conda-Forge's load_channels, I would advice copying that function into the code where it is used for now. This is what I did for boa.

[AntoinePrv]

@jaimergp can you confirm that we can merge this and that porting the remaining code to other project is a good option for you.
For everyone else, I take the lack of answer as a lack of objection.

[jaimergp]

Yep, no probs at all! Go ahead!

[JohanMabille]

Farewell little python code, you did a great job but now your time has passed

[SylvainCorlay]

I love how we just merged a PR named "remove mamba" into mamba.