












@Taranis In PKGBUILD provides should contain mamba. This is required so if another package depends on mamba this package fulfills it. I should also note that not -bin package provides libmamba and python-libmambapy that this one does not and is in conflict with this. It seems like a problem to me as both these packages should provide as same as the other.
@siavoshkc, I don't think this package should provide mamba, because the current AUR mamba package is something completely different from this.
Adding mamba to this package's provides section would cause some confusing conflicts.
@Taranis In PKGBUILD provides should contain mamba. This is required so if another package depends on mamba this package fulfills it. I should also note that not -bin package provides libmamba and python-libmambapy that this one does not and is in conflict with this. It seems like a problem to me as both these packages should provide as same as the other.
@siavoshkc micromamba is a drop-in replacement for mamba (or tiny-version of mamba). You could add aliases for mamba/conda.
Shouldn't the package provide mamba as well?
The check() step fails for me when trying to create the environment, with a filesystem permission denied error.
The full log is this:
Testing with /var/cache/private/pikaur/build/micromamba-bin/src/bin/micromamba
+ test -f /var/cache/private/pikaur/build/micromamba-bin/src/bin/micromamba
+ test '!' -f /var/cache/private/pikaur/build/micromamba-bin/src/etc/profile.d/mamba.sh
+ micromamba --help
[...]
++ mktemp -d
+ export MAMBA_ROOT_PREFIX=/tmp/tmp.HMWKnCC3Ge
+ MAMBA_ROOT_PREFIX=/tmp/tmp.HMWKnCC3Ge
+ micromamba create -n test --override-channels -c conda-forge --yes python=3.9
critical libmamba filesystem error: cannot set permissions: Operation not permitted [/tmp/tmp.HMWKnCC3Ge/pkgs/cache]
@carlosal1015 Just figured out the cause. I also installed the python-conda package that ships /etc/conda/condarc of the following contents:
envs_dirs:
- ~/.conda/envs
pkgs_dirs:
- ~/.conda/pkgs
This file will also be read by micromamba so that the test environment created by run_test.sh is located in ~/.conda/envs rather than MAMBA_ROOT_PREFIX. I'm not sure what's the best option to handle this corner case.
Interesting check passed in a clean chroot minutes ago.
check fails for 1.5.1, the test virtual environment is created in home rather than tmp, then run_test.sh fails to find the python executable.
++ mktemp -d
+ export MAMBA_ROOT_PREFIX=/tmp/tmp.acA48OWMEH
+ MAMBA_ROOT_PREFIX=/tmp/tmp.acA48OWMEH
+ micromamba create -n test --override-channels -c conda-forge --yes python=3.9
conda-forge/linux-64 No change
conda-forge/noarch No change
Transaction
Prefix: /home/xxx/.conda/envs/test
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。
The
check()function fails if the user has a global configuration (like customenvs_dirsorroot_prefix) defined in their~/.condarcor~/.mambarc.During the check phase,
micromamba createpicks up the user's host configuration because it lacks the--no-rcflag. This causes the test environment to be created in the user's custom directory (e.g., an external drive) instead of the isolated$MAMBA_ROOT_PREFIXunder/tmp. Consequently, the script fails with a "No such file or directory" error when looking for the python binary under/tmp.