Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 01:21
    ZaidaEMtzMo opened #9137
  • Aug 23 22:10
    jjhelmus commented #9133
  • Aug 23 21:55
    jjhelmus labeled #9136
  • Aug 23 21:55
    jjhelmus labeled #9136
  • Aug 23 21:54
    tlvu closed #9134
  • Aug 23 21:53
    tlvu opened #9136
  • Aug 23 21:42
    jjhelmus commented #9134
  • Aug 23 21:41
    jjhelmus review_requested #9135
  • Aug 23 21:41
    jjhelmus opened #9135
  • Aug 23 21:40
    tlvu commented #9134
  • Aug 23 21:38
    jjhelmus commented #9134
  • Aug 23 21:35
    jjhelmus commented #9128
  • Aug 23 21:34
    tlvu commented #9134
  • Aug 23 21:28
    tlvu commented #9134
  • Aug 23 21:21
    jjhelmus commented #9134
  • Aug 23 21:11
    jjhelmus commented #9130
  • Aug 23 21:09
    tlvu commented #9134
  • Aug 23 21:07
    dotslash commented #9128
  • Aug 23 21:01
    jjhelmus commented #9134
  • Aug 23 20:59
    tlvu opened #9134
Benjamin Bertrand
@beenje
I found the 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?
Mike Sarahan
@msarahan
conda 4.7 shouldn't be broken with artifactory. It prefers .conda files where they are available, but it's happy to use .tar.bz2 if that's all there is.
A PR would certainly be welcome, regardless
Benjamin Bertrand
@beenje
I think the issue with remote conda repositories in Artifactory is that the .conda package is found in the repodata.json but it can't be downloaded because artifactory only caches locally .tar.bz2 packages. It results in 404. See RTFACT-19267. Will submit a PR. Thanks.
Nehal J Wani
@nehaljwani
@beenje Are you using the generic type for remote repo or conda type for remote repo
Benjamin Bertrand
@beenje
I'm using the conda type
geekonloose
@geekonloose
Hello..! I am facing one error since last month, when i update all conda packages with conda update --all i am getting this message: TypeError("__init__() missing 1 required positional argument: 'message'")
Joris Van den Bossche
@jorisvandenbossche
Hi, I am experiencing a problem with pip from the default channel and on Python 3.7 not being able to install scipy using a wheel (for some reason it tries to get the tar.gz sources from pypi). This does not happen on Python 3.6, or also does not happen in Python 3.7 using conda-forge.
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 )
Any idea what would be going on? Or where I should report this? (it doesn't seem to be a scipy or pip issue, as it works fine with them when installed with conda-forge)
Joris Van den Bossche
@jorisvandenbossche
This seems reported here: conda/conda#9084
And it is due to Python 3.7.4 update
Jonathan J. Helmus
@jjhelmus
@jorisvandenbossche There are some issues with our Python 3.7.4 build, we will get it fixed with new packages out shortly. ContinuumIO/anaconda-issues#11195 is the issue where this is being tracked
Mike McCarty
@mmccarty
@jjhelmus do you have an eta on the fix? We are weighing waiting with baking in some workarounds.
Wolf Vollprecht
@wolfv
hey, I was wondering if it would be possible to use relative links for Python shebangs
I am working on a way to easily "container-activate" a conda environment
so when one does 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
Wolf Vollprecht
@wolfv
right now one hiccup was that i need to mount /home/user/miniconda/envs at /home/user/miniconda/envs in the container because otherwise the shebangs don't match up
one other thing that could be cool to explore is the use of overlayfs ... in principle one could overlay the conda (env) root over the container root, replacing the system libraries/bin folder etc.
but not sure if that would ever work well... however, playing around with systemd-nspawn is actually quite fun. I also find it interesting to isolate build environments further
Mike Sarahan
@msarahan
relative links for the shebang? Like the shebang points at a symlink?
Wolf Vollprecht
@wolfv
no rather the shebang being something like #!../bin/python
probably there is a good reason for it to not look like that
Mike Sarahan
@msarahan
ah, I see. I've never seen anything like that. I don't know of any particular reason why, though.
Jonathan J. Helmus
@jjhelmus
@mmccarty I expect we will have new builds up later today
Mike McCarty
@mmccarty
Perfect, thank you! @jjhelmus
Jonathan J. Helmus
@jjhelmus
Python 3.7.4 build 1 packages are now available in defaults
zeneofa
@zeneofa
I am trying to recode the capability of 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.
I would like to make this system agnostic eventually, but starting with windows...which I wish I didn't have to use :(
Marcel Bargull
@mbargull

@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_override conda config 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-install scripts)
  • 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/local and as such can be copied to (or mounted on) the destination container at the same /usr/local path. <-- Prefer this method instead of target_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
67

Relative 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
Marcel Bargull
@mbargull
BTW, @wolfv, @msarahan: Did you get a change to meet up at SciPy? If you want, we can chat about solver stuff over at https://gitter.im/conda/conda-developers . I would like to (/hope to) continue/partially finish work on this some time in the next months. Can't give any ETA at all though. But until then, I'd gladly offer to discuss/advice on the developers Gitter conversation.
Wolf Vollprecht
@wolfv
hey @mbargull yes, we talked! We haven't made any concrete plans on anything though. I'll join the dev channel
Also, thanks again for explaining the PREFIX story, that's actually really interesting ... I used to follow Flatpak development quite a bit and they have the OSTree which de-dupes all packages and overlays them in a container. Now thanks to the configurable prefix, a similar thing might be possible with conda ... that could be quite cool :)
Wolf Vollprecht
@wolfv
the other interesting thing I wanted to share is this post: https://michael.stapelberg.ch/posts/2019-08-17-introducing-distri/
Marcelo Duarte Trevisani
@marcelotrevisani
@mbargull if you need any help regarding it, please let me know. I would like to help
:)
BartosMosch
@BartosMosch
Hi all, I have following problem. I have an alpine python 3.6 docker image with a conda env preinstalled and a private hosted conda repo. I'm trying to install opencv but facing and issue regarding jasper. Conda shows an UnsatisfiableError for Jasper -> libgcc-ng=7.2.0 which is strange because the same Jasper version on conda-forge states that Jasper needs libgcc-ng >= 7.2.0.
Marcelo Duarte Trevisani
@marcelotrevisani
@BartosMosch are you using conda-forge to install it? or just the main packages?
which version of opencv are you trying to install?
BartosMosch
@BartosMosch
@marcelotrevisani Hi, I'm trying to install opencv==4.1.0 from the conda-forge branch.
Marcelo Duarte Trevisani
@marcelotrevisani
So, that might be related to the OpenCV's recipe
Could you please open an issue there
it would be useful to know which channels are you using, conda version and conda build as well
I just tried to install opencv for python 3.6 and it worked fine on Linux
conda create -n test-cv python=3.6 opencv=4.1.0
@BartosMosch
BartosMosch
@BartosMosch
@marcelotrevisani Here is the thing. I'm using a private hosted Repo and alpine linux. Installing form the public repo works fine but when I export the environment.yml and add those exact pinned package versions to our private repo and try to install opencv from there it fails because of the dependency issues I mentioned before. Which is weird
Marcelo Duarte Trevisani
@marcelotrevisani
that might be something related to the priority of your channels
if you are mixing a lot of channels that might be a problem
Marius van Niekerk
@mariusvniekerk
Conda forge doesn't build for musl libc so I'd avoid any Linux distro using that. Use a slimmed down debian/centos base instead
Marcel Bargull
@mbargull

@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 ^^

Pearu Peterson
@pearu

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 directory

For a complete log, see https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=65336&view=logs