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

Chardet run constraint should be normal constraint #55

Closed
corneliusroemer opened this issue Jun 27, 2022 · 5 comments
Closed

Chardet run constraint should be normal constraint #55

corneliusroemer opened this issue Jun 27, 2022 · 5 comments
Labels

Comments

@corneliusroemer
Copy link
Member

corneliusroemer commented Jun 27, 2022

Issue

I've installed the latest requests build from conda-froge.

I now always get the following warning:

/usr/local/Caskroom/mambaforge/base/envs/nextstrain/lib/python3.8/site-packages/requests/__init__.py:109: RequestsDependencyWarning: urllib3 (1.26.9) or chardet (5.0.0)/charset_normalizer (2.0.12) doesn't match a supported version!
  warnings.warn(

The root cause seems to be this commit from two days ago:
4d7cfb9

I don't understand why this is set as a run-constraint and not as a normal constraint. If it was a normal constraint, then conda would install an appropriate chardet. But now this is not the case.

@corneliusroemer
Copy link
Member Author

Ok, the new build requests==2.28.0=pyhd8ed1ab_1 actually works.

However, it's not trivial to downgrade an existing repo.

I had to do the following:

mamba install -c conda-forge requests=2.28.0=pyhd8ed1ab_1

If you don't provide the exact build number, the solver will not downgrade chardet from 5.0.0 to 4.0.0, so you won't actually get the fixed build.

@ngam
Copy link
Contributor

ngam commented Jun 27, 2022

I don't understand why this is set as a run-constraint and not as a normal constraint. If it was a normal constraint, then conda would install an appropriate chardet. But now this is not the case.

run-constrained is the correct solution in general here because chardet is not an actual dep, it is an optional dep. If we list it under run or deps, then it would be installed always which is not needed.

The problem with the solver is a separate issue, but I think they have listed the build as broken here conda-forge/admin-requests#452 (we could have done another retroactive run-constrained actually, but oh well)

@ngam
Copy link
Contributor

ngam commented Jun 27, 2022

mamba create -n test -c conda-forge requests chardet yields:


  + brotlipy                0.7.0  py310hf8d0d8f_1004  conda-forge/osx-arm64     Cached
  + bzip2                   1.0.8  h3422bc3_4          conda-forge/osx-arm64     Cached
  + ca-certificates     2022.6.15  h4653dfc_0          conda-forge/osx-arm64     Cached
  + certifi             2022.6.15  py310hbe9552e_0     conda-forge/osx-arm64     Cached
  + cffi                   1.15.0  py310hf10583b_0     conda-forge/osx-arm64     Cached
  + chardet                 4.0.0  py310hbe9552e_3     conda-forge/osx-arm64     Cached
  + charset-normalizer     2.0.12  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + cryptography           37.0.2  py310h94bb23d_0     conda-forge/osx-arm64     Cached
  + idna                      3.3  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + libffi                  3.4.2  h3422bc3_5          conda-forge/osx-arm64     Cached
  + libzlib                1.2.12  ha287fd2_1          conda-forge/osx-arm64     Cached
  + ncurses                   6.3  h07bb92c_1          conda-forge/osx-arm64     Cached
  + openssl                1.1.1p  ha287fd2_0          conda-forge/osx-arm64     Cached
  + pip                    22.1.2  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + pycparser                2.21  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + pyopenssl              22.0.0  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + pysocks                 1.7.1  py310hbe9552e_5     conda-forge/osx-arm64     Cached
  + python                 3.10.5  h71ab1a4_0_cpython  conda-forge/osx-arm64     Cached
  + python_abi               3.10  2_cp310             conda-forge/osx-arm64        4kB
  + readline                8.1.2  h46ed386_0          conda-forge/osx-arm64     Cached
  + requests               2.28.0  pyhd8ed1ab_1        conda-forge/noarch        Cached
  + setuptools             62.6.0  py310hbe9552e_0     conda-forge/osx-arm64        1MB
  + sqlite                 3.39.0  h40dfcc0_0          conda-forge/osx-arm64     Cached
  + tk                     8.6.12  he1e0b03_0          conda-forge/osx-arm64     Cached
  + tzdata                  2022a  h191b570_0          conda-forge/noarch        Cached
  + urllib3                1.26.9  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + wheel                  0.37.1  pyhd8ed1ab_0        conda-forge/noarch        Cached
  + xz                      5.2.5  h642e427_1          conda-forge/osx-arm64     Cached
  + zlib                   1.2.12  ha287fd2_1          conda-forge/osx-arm64     Cached

which is correct.

@corneliusroemer
Copy link
Member Author

Yes, it is correct, but as I maybe didn't explain sufficiently, the solver, at least mamba, seems to not notice that the build 0 is marked as broken. Hence it is kept, and not updated to build 1 - maybe because upgrading to build 1 would mean chardet would have to be downgraded.

One could check with conda, but I don't use conda anymore.

My problem was with an existing environment, that already had build 0 installed and failed to upgrade to build 1.

@ngam
Copy link
Contributor

ngam commented Jun 27, 2022

Ah! Makes sense, sorry...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants