Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:31
    sampellino commented #9221
  • 13:00
    travishathaway synchronize #11852
  • 12:09
    travishathaway synchronize #11852
  • 12:01
    travishathaway synchronize #11852
  • 11:58
    travishathaway labeled #11743
  • 11:58
    travishathaway unlabeled #11743
  • 11:58
    travishathaway assigned #11743
  • 11:56
    travishathaway commented #11743
  • 11:54
    travishathaway synchronize #11852
  • 11:43
    travishathaway synchronize #11852
  • 08:26

    dbast on main

    Enable one single test for linu… (compare)

  • 08:26
    dbast closed #11911
  • 08:05
    travishathaway synchronize #11852
  • 07:39
    travishathaway synchronize #11852
  • 07:18
    travishathaway unpinned #11308
  • 07:18
    travishathaway unpinned #11316
  • 07:17
    travishathaway unpinned #11321
  • 07:10
    travishathaway commented #7328
  • 05:50
    FFY00 synchronize #11788
  • 05:50

    FFY00 on repo-plugin

    [WIP] repo: repodata interface … (compare)

Cheng H. Lee
@chenghlee
@isuruf: we'll look into turning off the comments for now, or at least until the bot gets done with closing & locking the really old issues.
Isuru Fernando
@isuruf
Thanks
Jannis Leidel
@jezdez
@isuruf Were those more notifications for PRs or issues that were annoying to you?
Unfortunately GitHub doesn't provide the ability to bypass notifications for status messages like this :(
Isuru Fernando
@isuruf
Both I guess. I mostly meant closed PRs/issues. Closing open issues with a message is totally fine
Eric Prestat
@ericpre
@jezdez, @chenghlee, any chance to have these two PRs reviewed: conda/menuinst#85 and conda/constructor#455
3 replies
Pat Gunn
@pgunn
If I found a typo on the conda docs site, who's the right person to poke about that?
Pat Gunn
@pgunn
nvm, figured it out- did a PR to the conda-docs repo
Actually, I think there was a previous strange commit that broke how miniconda.rst is supposed to work; might be smarter to revert that
Pat Gunn
@pgunn
Pat Gunn
@pgunn
Is there a way in environment.yml to specify a preference-but-not-a-requirement for a dependency that its build be of a certain family? I want my package to prefer gpu builds of tensorflow, knowing that they're never available on osx so the mkl or whatever other builds are fine there
Pat Gunn
@pgunn
I guess for now we'll just add to our instructions a note telling people with a GPU how to manually switch builds of that package.
Bas Nijholt
@basnijholt

Does anyone know how the following two cases are different

conda activate old_env
conda env export > env.yml
conda create -n new_env -f env.yml

vs

conda create -n new_env --clone /path/to/old_env
Bas Nijholt
@basnijholt
Pat Gunn
@pgunn
Bas: I have a guess, but it's just a guess and I'm "just some guy" on the internet.
Bas: I'd guess that the --clone will never reach out to the internet to reconsider the best way to resolve that environment, being a completely local operation, while the former route might, in theory, think about dependencies and reach out to the internet to consider other builds of things. Maybe for security fixes, maybe for other things.
@basnijholt Still, just a guess.
Daniel Mahler
@mhlr
Is there a way to see which dependencies are preventing packages from updating to the latest available version?
Jaime Rodríguez-Guerra
@jaimergp
Which kind of behaviour are you expecting?
Wolf Vollprecht
@wolfv
With mamba you can try mamba repoquery whoneeds somepkg to see what packages in your environment depend on somepkg and what the constrains are
Daniel Mahler
@mhlr
Thanks @wolfv & @jaimergp . I have a very large data exploration env. There is a lot of dependencies. I would like to know which dependincies are blocking an available update, ie I would like a list saying of cases something like if you removed package A you could update package B to version X.Y
Jaime Rodríguez-Guerra
@jaimergp
I would start by explicitly adding the constrains you want satisfied and see if mamba complains with a clear message of the conflict.
Seems like you are interested in B reaching version X.Y, then add - B X.Y.* to the env file
Daniel Mahler
@mhlr
Thanks @jaimergp I do not have specific constraints in mind. I want to discover them. I want something to tell me if there is some package I may not even remember installing that is holding back a number of packages so I can consider removing it.
Jaime Rodríguez-Guerra
@jaimergp
I am afraid I am not aware of any such tool :/
if anything try setting CONDA_VERBOSITY=3 and explore the logs, but that's going to be time consuming
Philippe Blain
@phil-blain
Hi everyone. Not sure if the right channel but I thought I’d ask. I noticed that the Intel Distribution for Python includes conda, and is configured to use both the intel and defaults channels. Does intel have a special agreement with Anaconda or is the use of the defaults channel still subject to Anaconda repository Terms of Service ? (i.e no commercial of gvt use)
9 replies
Pat Gunn
@pgunn
Is there a good way of getting some attention to conda/conda-docs#742 ?
psortos
@psortos
Can I get some assistance on an issue I'm having with a pytorch recipe? I'm these errors ImportError: libGL.so.1: cannot open shared object file: No such file or directory and AttributeError: module 'torch.jit' has no attribute 'unused' this is the current repo conda-forge/staged-recipes#16916
Nora Loose
@NoraLoose
Hi everyone! I merged a conda-forge/gcm_filters-feedstock#2 to update the meta.yaml to show a new license and description for our package. However, on conda-forge, the license and description of our package are still in their outdated version, even though this meta.yaml file on the feedstock contains the proper information. Does anyone know what is going on? Thanks in advance for your help!
2 replies
Pat Gunn
@pgunn
I'm having trouble figuring out what's going on in some package version parsing; I'm getting an env that's not building because of glibc version issues, but as far as I can tell this isn't actually a mismatch; wondering what I'm missing.
The following specifications were found to be incompatible with your system:

  - feature:/linux-64::__glibc==2.17=0
  - feature:|@/linux-64::__glibc==2.17=0
  - coverage -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - cython -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - h5py -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - mypy -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - numpy -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - opencv -> libgcc-ng[version='>=7.3.0'] -> __glibc[version='>=2.17']
  - psutil -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - python=3.10 -> libgcc-ng[version='>=7.5.0'] -> __glibc[version='>=2.17']
  - scikit-image -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - scikit-learn -> libgcc-ng[version='>=9.3.0'] -> __glibc[version='>=2.17']
  - scipy -> libgfortran-ng -> __glibc[version='>=2.17']
  - tensorflow -> __glibc[version='>=2.17']
  - tensorflow -> cudatoolkit[version='>=11.2,<12'] -> __glibc[version='>=2.17,<3.0.a0']
  - tifffile -> libgcc-ng[version='>=7.3.0'] -> __glibc[version='>=2.17']
  - tk -> libgcc-ng[version='>=7.5.0'] -> __glibc[version='>=2.17']

Your installed version is: 2.17


scclin009(1):~/src/caiman_dev-clean$ rpm -qa glibc
glibc-2.17-324.el7_9.i686
glibc-2.17-324.el7_9.x86_64
19 replies
Tim 'mithro' Ansell
@mithro
Pat Gunn
@pgunn
Do entries like this describe what packages are available in the defaults channel?
aceenprsu
@aceenprsu
I have conda installed by rpm on Centos 7.
I created a conda environment and installed conda on the environment.
The conda provided by the rpm masks the conda in the environment.
How should I configure the conda environment so that the conda inside the environment is used instead?
Pat Gunn
@pgunn
Is there a reason you didn't update the base environment instead?
@aceenprsu Anyhow, you should be able to edit the rpm-based conda init stuff out of your environment and put a replacement with different paths in your dotfiles
All the rpm does, presumably, is edit the /etc/profile.d/ and similar standard dotfiles; have your account dotfiles undo those changes and init with your conda env.
(the term "environment" might be a bit confusing here as it could either mean a conda virtualenv-based environment, or an install of the conda codebase with its individual environment store and so on)
Pat Gunn
@pgunn

I'm running into an issue where I cannot create a new environment with conda create ... with an existing conda install (with a lot of other environments), but I can make the same environment with a completely fresh install of conda. Any idea what might cause this?

(I'm actually trying to help out a user with this problem; there may be some turnaround in poking around)

Jaime Rodríguez-Guerra
@jaimergp
what's the error? it might be due to conda versions, space limitations, permissions... plenty of possible causes
Pat Gunn
@pgunn
Version conflicts between packages.
Jaime Rodríguez-Guerra
@jaimergp
have you added extra configuration keys to your .condarc? e.g. create_default_packages, pinned_packages, aggresive_updates?
or maybe the default channels are different?
Pat Gunn
@pgunn
I asked this prematurely; I need to get access to this person's laptop to see what's going on. Probably really inefficient to try to manage those timescales and gitter. Thanks for the ideas though.
Jaime Rodríguez-Guerra
@jaimergp
No problem! Ping me if needed!
Faustin Carter
@FaustinCarter
When running conda-build on Windows, I'm getting a bunch of new output related to LIEF. Is there a way to skip these ( other than downgrading to an earlier version of conda-buidl?)
Christian Roth
@croth1

Can anybody help me understand how to read this solving config error?

Package cudnn conflicts for:
pytorch-lightning=1.4.5 -> pytorch[version='>=1.6'] -> cudnn[version='>=7.6,<8.0a0|>=7.6.5.32,<8.0a0|>=8.2.1.32,<9.0a0|>=8.1.0.77,<9.0a0']
pytorch::torchvision=0.10.0 -> pytorch==1.9.0 -> cudnn[version='>=7.6.5.32,<8.0a0|>=8.2.1.32,<9.0a0']The following specifications were found to be incompatible with your system:

  - feature:/linux-64::__glibc==2.27=0
  - nvidia::cudatoolkit=11.1.1 -> __glibc[version='>=2.17,<3.0.a0']
  - pytorch-lightning=1.4.5 -> pytorch[version='>=1.6'] -> __glibc[version='>=2.17|>=2.17,<3.0.a0']
  - pytorch::pytorch=1.9.0 -> cudatoolkit[version='>=11.1,<11.2'] -> __glibc[version='>=2.17,<3.0.a0']
  - pytorch::torchvision=0.10.0 -> cudatoolkit[version='>=11.1,<11.2'] -> __glibc[version='>=2.17|>=2.17,<3.0.a0']

Your installed version is: 2.27

Why would __glibc==2.27 conflict with __glibc[version='>=2.17|>=2.17,<3.0.a0']? What am I overlooking here?

Jaime Rodríguez-Guerra
@jaimergp
Might be a red herring. If pytorch is involved (which requires 2.17 as you see), there's a chance a package for 2.12 is involved somehow in the dependency tree. Try solving with mamba and see if their error is a bit clearer.
1 reply
Marcelo Duarte Trevisani
@marcelotrevisani
Could someone please review this PR?
conda/conda#11123