run_constrained: chardet

[ngam]

fixes #53

(I am not sure this is the best solution or the desirable solution here, so reviewers should carefully assess)

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ngam]

@conda-forge-admin, please rerender

[teake]

@ocefpaf I think noarch/requests-2.28.0-pyhd8ed1ab_0.tar.bz2 needs to be marked as broken. If I do

$ conda create -n testenv requests chardet

I get

[...]
  chardet            conda-forge/osx-64::chardet-5.0.0-py310h2ec42d9_0
[...]
  requests           conda-forge/noarch::requests-2.28.0-pyhd8ed1ab_0
[...]

which are incompatible with each other. I'll submit a PR to https://github.com/conda-forge/admin-requests.

[ocefpaf]

Thanks @teake. We can also try a repo data patch but b/c we have this build number 1 here it is probably not worth it. Marking as broken is fine.

[corneliusroemer]

Upgrading to the new build is a bit tricky, one needs to explicitly provide the build number, otherwise chardet won't be downgraded (downgrading is penalized more than increasing build number).

This should work (if anyone else has this issue), see #55

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

[ngam]

Thanks everyone, but is this severe enough? I only submitted this fix as an abundance of caution going forward and I was not too worried about past builds. Upstream only emits a warning about the inconsistent deps, but not a full-blown error. Also note, chardet is completely optional so we still get the correct charset_normalizer in all cases. We could have done a repodata patch too as ocefpaf mentioned...

[ocefpaf]

@ngam a repodata patch would have avoided this but, in a way, this is a "bug" in conda. Existing envs don't know if a package was pulled and they won't update to a higher build number.

[ngam]

Ah. I now see how things got confused... Oh well...

[teake]

With 2.28.0-0 marked as broken, I now get:

$ conda create -n testenv requests chardet
[...]
  chardet            conda-forge/osx-64::chardet-5.0.0-py310h2ec42d9_0
[...]
  requests           conda-forge/noarch::requests-2.27.1-pyhd8ed1ab_0
[...]

This combination also emits the incompatibility warning. Sigh. If we want to avoid combinations that emit this warning, I guess all previous requests builds of 2.26 and 2.27 should be patched (the upstream commit was first included in 2.26.0).

If somebody wants to pick this up, that'd be great -- the instructions in https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/tree/main/recipe are not at all clear to me.

Btw, upstream has just upped the optional dependency to chardet<6: psf/requests#6179.

[ngam]

If somebody wants to pick this up, that'd be great -- the instructions in https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/tree/main/recipe are not at all clear to me.

@ocefpaf or I can do this soon. Also, opening #56 as this also appears in CI now. Let's continue the discussion there

[ngam]

See for a thorough update: conda-forge/conda-forge-repodata-patches-feedstock#287

including reverting marking the previous build as broken