"Non-conda folder exists at prefix" after aborted env creation with `--platform`

[jonashaag]

With Micromamba 1.4.9, on osx-arm64:

$ micromamba create -p /tmp/env --platform osx-64 zlib
Confirm changes: [Y/n] n  <=== abort this
$ micromamba create -p /tmp/env --platform osx-64 zlib
error    libmamba Non-conda folder exists at prefix

[Hind-M]

Can you specify the context of the environment creation failure? (logs of failure for example)

[jonashaag]

Updated the instructions, key seems to be to select another platform

[jonashaag]

This issue just re-appeared in a recent 1.x version:

$ micromamba -p /tmp/env create -f environment.yml --platform win64
...
error    libmamba Platform is ill-formed, expected <os>-<arch> in: 'win64'
error    libmamba Could not solve for environment specs
...
$ micromamba -p /tmp/env create -f environment.yml --platform win-64
error    libmamba Non-conda folder exists at prefix
critical libmamba Aborting.

That's exactly why I always advocate for adding regression tests for bug fixes.

[sufyazi]

hi, I am having this issue. I tried creating an env with the --platform flag, but it failed at first because of a nonexistent package. After removing the offending package and rerunning the same command, I got this non-conda folder exists at prefix. What should I do?

EDIT: Never mind, I just realized that despite the output of micromamba env list, there really was a (n incompletely set up?) env folder with the name I supplied with -n created prior to command abortion I encountered. I just rm the env directory and the command can be rerun again.

[corneliusroemer]

Please please fix this, it's super annoying to have to track down the exact prefix and manually delete it when micromamba create errors. It should clean up after itself when erroring with an expectable install problem rather than just crashing.

Example:

$ micromamba create -n ingest -f environment.yml --rc-file .mambarc --platform osx-64
Found conda-prefix at '/Users/corneliusromer/micromamba/envs/ingest'. Overwrite?: [y/N] y
bioconda/osx-64 (check zst)                        Checked  0.1s
bioconda/noarch (check zst)                         Checked  0.2s
bioconda/noarch                                      5.3MB @   3.7MB/s  1.4s
bioconda/osx-64                                      4.6MB @   2.7MB/s  1.7s
conda-forge/noarch                                  15.4MB @   4.0MB/s  3.9s
conda-forge/osx-64                                  31.7MB @   6.2MB/s  5.1s
error    libmamba Could not solve for environment specs
    The following package could not be installed
    └─ orjsonl does not exist (perhaps a typo or a missing channel).
critical libmamba Could not solve for environment specs

$ micromamba create -n ingest -f environment.yml --rc-file .mambarc --platform osx-64
error    libmamba Non-conda folder exists at prefix
critical libmamba Aborting.

$ rm -rf /Users/corneliusromer/micromamba/envs/loculus-ingest

$ micromamba --version
1.5.8

[rjlopez2]

I am also facing some issues here. not sure how to fix it yet.

this works for me on windows device:

$ micromamba create -p D:\test\loc_venv -f .\requirements.yml

But this does not, even thought the folder does exists:

$ micromamba create -p 'D:\User_R\OneDrive - Universitaet Bern\place\of\working\space\loc_venv' -f .\requirements.yml
error    libmamba Non-conda folder exists at prefix
critical libmamba Aborting.

That's all information I received. I do noted that the path has spaces in the strings. Changing to double quote, does not help.

or trying from the actual working directory:

$ micromamba create -p .\loc_venv\ -f .\requirements.yml
error    libmamba Non-conda folder exists at prefix
critical libmamba Aborting.

My micromamba version = 1.5.8

Please some help would be appreciated. thanks

[sufyazi]

Not the dev, but have you tried manually looking into the folder structure and manually deleting loc_venv dir before rerunning micromamba create? That's the workaround that worked for me (as I posted above).

[corneliusroemer]

@rjlopez2 you simply have to delete the folder manually, i.e. with rm -rf foldername

It's annoying that this is necessary but it should work as a workaround.

[rjlopez2]

My bad, I read this way too fast. thanks a lot @corneliusroemer and @sufyazi. removing the existing folder works. 👍

[corneliusroemer]

Thanks for reminding everyone about the pervasiveness and the annoyance of this issue though. It's a really big bug that should have been fixed long ago.

@Hind-M I know you're close to releasing V2 - is it fixed there at least?