use_only_tar_bz2 boolean a bit by accident. It allows for example to use conda 4.7 with Artifactory (that doesn't support the new .conda package file format). I noticed it wasn't documented in the user-guide. Would a PR to mention it in the Advanced configuration be accepted?
See https://github.com/scipy/scipy/issues/10637#issuecomment-520219277 for two example environments (one created with defaults and one with conda-forge) where the one can install scipy and the other not (and the rest of the issue for some context, but that might be noise )
conda contactivate my_env it launches a new chroot like container using systemd-nspawn that doesn't give access to the entire home directory, for example, and could be even more restricted
systemd-nspawn is actually quite fun. I also find it interesting to isolate build environments further
conda activate in elisp, I am on windows though. It is difficult to determine what the exe actually does. I know the preferred way is to use Scripts\activate.bat and go from there, which is where I am starting, but activate.bat calls conda.bat, which eventually calls conda.exe activate. Would it be possible to get a run-down of this? I have found some scattered information on various github issue pages, but nothing concrete (I am also not sure which issue page is outdated w.r.t the current approach), so I am a bit confused. Thanks.
@wolfv: Relative shebangs won't work. IIRC, on Linux, those will be relative to the CWD instead of the script's path. Generally, I would refrain from trying anything fancy/uncommon with those -- they are non-standardized and have divergent limitations on different platforms. https://www.in-ulm.de/~mascheck/various/shebang/ is a great resource I recommend!
That said, changing the shebangs alone won't get you that far since the environment's path can be written to other packaged files, too. grepping for /opt/anaconda1anaconda2/anaconda3 (prefix placeholder) in the package cache should give you some idea. All in all: In the general case, you can't use a Conda environment under a different path than the one it has been created under; meaning you'd have to preserve the path when mounting it.
I'm not totally sure what you want to do, but here are some bits and pieces that might be of interest to you:
- https://github.com/containers/fuse-overlayfs/
- containers/buildah#1560
target_prefix_overridecondaconfig parameter, e.g.,CONDA_TARGET_PREFIX_OVERRIDE=/usr/local conda create --prefix=./host/dir/just/used/to/create/but/not/run/the/environment
beware that, AFAIR, this one is not necessarily officially documented/battle-tested and fails in certain cases (e.g.,post-installscripts)- Bioconda creates containers at https://quay.io/organization/biocontainers . Instead of using
target_prefix_override, here the environments are created inside a separate container at their destination path/usr/localand as such can be copied to (or mounted on) the destination container at the same/usr/localpath. <-- Prefer this method instead oftarget_prefix_override!
grepping for/opt/anaconda1anaconda2/anaconda3(prefix placeholder) in the package cache should give you some idea.
|> docker run --rm -t continuumio/miniconda3:4.6.14 sh -lc 'find /opt/conda/pkgs/ -mindepth 1 -type f \! -path "*/info/*" -exec grep -l /opt/anaconda1anaconda2anaconda3 {} \;' | wc -l
67Relative shebangs won't work. IIRC, on Linux, those will be relative to the CWD instead of the script's path.
yup:
> mkdir -p x/{a,b}/{bin,opt}
> printf '#!/bin/sh\necho yay\n' > x/a/bin/yay
> printf '#!/bin/sh\necho nay\n' > x/b/bin/yay
> printf '#!../bin/yay\n' > x/a/opt/agree
> chmod +x x/{a,b}/bin/yay x/a/opt/agree
> cd x/b/opt
> ../../a/opt/agree
nay
conda create -n test-cv python=3.6 opencv=4.1.0
@wolfv
hey @mbargull yes, we talked! We haven't made any concrete plans on anything though. I'll join the dev channel
Cool! I hope I'll be able to help and we can get something going with the Anaconda folks ;)
I used to follow Flatpak development quite a bit and they have the OSTree
hehe, yeah that's one of the things on my ever-increasing list of things to look into.
https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/
Thanks for sharing this. I only skimmed over this; looks interesting, but without digging more into it, it's hard to say what problems this will encounter (e.g., are same shared libs with different versions potentially loaded simultaneously? -> conflicting symbols at runtime?)
Plus, IIRC Snap uses SquashFS too and I'm not sure but think this imposed some limitations -- but I can't recall what it was; my memory is quite cloudy on that..
@marcelotrevisani
@mbargull if you need any help regarding it, please let me know. I would like to help
:)
:D Yes, of course I didn't forget about my namesake! Happy you're still interested and already joined the dev Gitter ^^
Any ideas about the following conda-build failure in azure CI (locally, the same conda-build works fine, conda versions are all the same):
ln: target `/home/conda/feedstock_root/build_artifacts/omniscidb-cuda_1566642674553/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeh/bin/zstdmt' is not a directoryFor a complete log, see https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=65336&view=logs