Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

repoquery whoneeds no longer lists package version dependency #3717

Open
3 tasks done
DManowitz opened this issue Dec 31, 2024 · 5 comments · May be fixed by #3743
Open
3 tasks done

repoquery whoneeds no longer lists package version dependency #3717

DManowitz opened this issue Dec 31, 2024 · 5 comments · May be fixed by #3743
Assignees
Labels
type::bug Something isn't working

Comments

@DManowitz
Copy link

Troubleshooting docs

  • My problem is not solved in the Troubleshooting docs

Anaconda default channels

  • I do NOT use the Anaconda default channels (pkgs/* etc.)

How did you install Mamba?

Other (please describe)

Search tried in issue tracker

repoquery whoneeds

Latest version of Mamba

  • My problem is not solved with the latest version

Tried in Conda?

Not applicable

Describe your issue

When using the repoquery whoneeds function, mamba used to return the required version(s) of the specified package. There is still a column labeled "Depends" in the output. However, nothing appears in this column. It also appears that the outputs for the next 2 columns ("Channel" and "Subdir") are shifted left by 1 column, as they appear under the "Depends" and "Channel" column headings.

mamba info / micromamba info

libmamba version : 2.0.5
          mamba version : 2.0.5
           curl version : libcurl/8.11.1 Schannel zlib/1.3.1 libssh2/1.11.1
     libarchive version : libarchive 3.7.7 zlib/1.3.1 liblzma/5.2.6 bz2lib/1.0.8 liblz4/1.9.3 libzstd/1.5.6
       envs directories : C:\Users\manow\miniconda3\envs
                          C:\Users\manow\.conda\envs
                          C:\Users\manow\AppData\Local\conda\conda\envs
                          C:\Users\manow\miniconda3\Library\envs
          package cache : C:\Users\manow\miniconda3\pkgs
                          C:\Users\manow\.conda\pkgs
                          C:\Users\manow\AppData\Local\conda\conda\pkgs
                          C:\Users\manow\miniconda3\Library\pkgs
                          C:\Users\manow\.mamba\pkgs
                          C:\Users\manow\AppData\Roaming\.mamba\pkgs
            environment : C:\Users\manow\miniconda3 (active)
           env location : C:\Users\manow\miniconda3
      user config files : C:\Users\manow\.mambarc
 populated config files : C:\Users\manow\.mambarc
                          C:\Users\manow\.condarc
       virtual packages : __win=10.0.19045=0
                          __archspec=1=x86_64
                          __cuda=12.7=0
               channels : https://conda.anaconda.org/pytorch/noarch
                          https://conda.anaconda.org/pytorch/win-64
                          https://conda.anaconda.org/pyg/noarch
                          https://conda.anaconda.org/pyg/win-64
                          https://conda.anaconda.org/nvidia/label/cuda-11.3.1/noarch
                          https://conda.anaconda.org/nvidia/label/cuda-11.3.1/win-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/conda-forge/win-64
                          https://software.repos.intel.com/python/conda/noarch
                          https://software.repos.intel.com/python/conda/win-64
       base environment : C:\Users\manow\miniconda3\Library
               platform : win-64

Logs

No response

environment.yml

No response

~/.condarc

No response

@DManowitz
Copy link
Author

In case my description is not clear enough, here is the start of the output of the command mamba repoquery whoneeds -c conda-forge mpi4py when using mamba 2.0.5:

 Name                     Version      Build             Depends     Channel     Subdir
----------------------------------------------------------------------------------------
 adios4dolfinx            0.8.1        pyhd8ed1ab_0      conda-forge conda-forge
 adios4dolfinx            0.8.2        pyhd8ed1ab_0      conda-forge conda-forge
 adios4dolfinx            0.9.0        pyhd8ed1ab_0      conda-forge conda-forge
 adios4dolfinx            0.9.1        pyh458ca06_0      conda-forge conda-forge

and here is the start of the same output when using mamba 1.4.7:

 Name                     Version      Build           Depends                Channel
------------------------------------------------------------------------------------------
 cosmic_profiles          1.2.6        py37hf2a7229_0  mpi4py                 conda-forge
 cosmic_profiles          1.2.6        py38h885f38d_0  mpi4py                 conda-forge
 cosmic_profiles          1.2.6        py39h415ef7b_0  mpi4py                 conda-forge
 cosmic_profiles          1.2.7        py310h00ffb61_0 mpi4py                 conda-forge
 cosmic_profiles          1.2.7        py37h7f67f24_0  mpi4py                 conda-forge
 cosmic_profiles          1.2.7        py38hd3f51b4_0  mpi4py                 conda-forge
 cosmic_profiles          1.2.7        py39h99910a6_0  mpi4py                 conda-forge

The same sort of difference is observable regardless of whether the query is against a local environment or a repo. I appreciate the alphabetical sorting of the results, but also want to see what version(s) are required by the listed packages.

However, I also noticed that the latest version of conda with the latest conda-libmamba-solver also lists a repoquery command, and when I run that command, I see the same sort of output as when using mamba 2.0.5, but there is no "Depends" column heading in the table. I don't know why this information wouldn't be useful in this case, too.

@jjerphan
Copy link
Member

jjerphan commented Jan 2, 2025

I cannot reproduce the issue with 2.0.5, here is the head of the output I get:

 Name                     Version      Build                                  Depends                Channel     Subdir     
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 adaptive-scheduler       0.9.2        py37hc8dfbb8_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py37h89c1867_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py37h89c1867_1                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py37h9c2f6ca_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py37h9c2f6ca_1                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py38h578d9bd_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py38h578d9bd_1                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py39hf3d152e_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py39hf3d152e_1                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.17       py310hff52083_1                        mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.2        py38h32f6830_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.3        py37hc8dfbb8_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.3        py38h32f6830_0                         mpi4py                 conda-forge conda-forge
 adaptive-scheduler       0.9.4        py37hc8dfbb8_0                         mpi4py                 conda-forge conda-forge

Can you provide more information about your setup (e.g. your configuration)?

@jjerphan jjerphan added the status::cannot-reproduce The bug could not be reproduced label Jan 2, 2025
@DManowitz
Copy link
Author

DManowitz commented Jan 2, 2025

@jjerphan The only thing I can think of that might be useful beyond the mamba info output is that I have been using mamba for a while, so I installed v2.0.5 over v1.4.7, and both versions were installed from conda-forge into the base env of a miniconda install. Also, I noticed that mamba v2 changed the default location for the environments and package cache, so I edited the envs_dirs and pkgs_dirs settings in my .condarc and .mamabarc files to ensure that I could use my previously created environments and package cache using either mamba or conda.

@Hind-M Hind-M self-assigned this Jan 6, 2025
@Hind-M Hind-M linked a pull request Jan 15, 2025 that will close this issue
2 tasks
@Hind-M Hind-M added type::bug Something isn't working and removed status::cannot-reproduce The bug could not be reproduced labels Jan 15, 2025
@Hind-M
Copy link
Member

Hind-M commented Jan 17, 2025

I appreciate the alphabetical sorting of the results, but also want to see what version(s) are required by the listed packages.

I believe that when relevant, the constraints/versions are supposed to be displayed, as in:


triqs                    3.3.1        py313h4e221bd_6                        mpi4py >=4.0.1,<5.0a0  conda-forge linux-64
unidist-mpi              0.7.0        py311h38be061_0                        mpi4py >=3.0.3         conda-forge linux-64
unidist-mpi              0.7.0        py310hff52083_0                        mpi4py >=3.0.3         conda-forge linux-64

@DManowitz
Copy link
Author

I appreciate the alphabetical sorting of the results, but also want to see what version(s) are required by the listed packages.

I believe that when relevant, the constraints/versions are supposed to be displayed, as in:


triqs                    3.3.1        py313h4e221bd_6                        mpi4py >=4.0.1,<5.0a0  conda-forge linux-64
unidist-mpi              0.7.0        py311h38be061_0                        mpi4py >=3.0.3         conda-forge linux-64
unidist-mpi              0.7.0        py310hff52083_0                        mpi4py >=3.0.3         conda-forge linux-64

Exactly! This is precisely what I'm looking for. I know this is beyond the scope of the original behavior of this command, but whoneeds previously only checked the dependency information, but not the runtime constraint information. Would it be possible to also check the runtime constraint information for this command or add a parallel whoconstrains command that checks this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants