Fix micromamba invocation

[jonashaag]

Micromamba does not support env create, only create.

Where do I add a test for this?

[asottile]

CC @xhochy

though if micromamba doesn't support the same interface as conda I'd rather just not support it

[jonashaag]

It's the same interface just without env

[asottile]

It's the same interface just without env

if it needs special code it's not the same interface -- it's not a drop in replacement

[jonashaag]

OK, we can also fix it in micromamba.

[wolfv]

Hi @asottile, while I understand your reasoning, I would like to point out that this behavior of conda is a "historical artifact" and something that the Anaconda team is actively working to fix (by removing the entire conda env subcommand). Here is the associated issue: https://github.com/conda/conda/issues/11633#issue-1308105702

I think soon the conda env create command will be marked as deprecated, and hopefully removed as well.

For micromamba, we didn't tie ourselves to the historical evolution of the conda CLI and rather chose to do some minor things differently (including this conda create vs conda env create issue).

I think it would be really cool if you could merge this PR so that we're not forced to add this confusing sub-command to micromamba.

[asottile]

does conda create work for all three?

[wolfv]

Unfortunately conda create does not work with environment.yml files (it does, however, work with plain text files or explicit lock files). On the other hand, conda env create only works with the environment.yml files. That's part of what makes the design of conda confusing.

[asottile]

then for now I think the best course of action is to remove micromamba since it does not follow the interface

[wolfv]

I would love to understand better what bothers you about such a small change? It would be a great help!

As I explained, I would like to move away from the broken conda env create & conda create interface to something cleaner (a single create command) -- the same way the conda developers also want to do.

I have not implemented it for now to prevent users of micromamba from painful breakage down the line (when the env subcommand will inevitably be removed). We could add an alias now, but it will only lead to more people using it (which is the opposite of what the mamba & conda projects want).

Would it help convince you if e.g. @jezdez or @kenodegard from Anaconda chime in?

[asottile]

I totally agree with the want to move away from conda env create -- but until then it's a confusing and complicated to implement, document, and then have users understand -- not to mention that it's untested. Additionally, I'd much rather wait until the dust has settled rather than use something which is explicitly marked as "not for production use" anyway.

[wolfv]

I am happy to remove the "not for production" use thing. I am using micromamba daily and it's a much improved experience. And we nowadays use it in all of our CI pipelines. So it's definitely fairly well tested.

[jonashaag]

@asottile there doesn't seem to be any progress on removing conda env and micromamba had a 1.0 release since we last discussed this. Would you reconsider your decision not to accept special support for Micromamba? It is literally a matter of calling ["env", "create", ...] or ["create", ...].

[asottile]

yeah if it's not drop in we shouldn't pretend it is

[jonashaag]

yeah if it's not drop in we shouldn't pretend it is

Does that mean you’ll only accept drop in replacements with a 100% compatible Conda interface, or would you be fine with a special case for Micromamba that’s not a 100% drop in replacement?

[asottile]

I already spend way too much time supporting conda and it's quirks and flakiness. if I have to spend any more time maintaining little snowflake permutations of conda I'm more likely to remove the whole thing