search

conda-forge / requests-feedstock

A conda-smithy repository for requests.
BSD 3-Clause "New" or "Revised" License
2 stars 21 forks source link

run_constrained: chardet #54

Closed ngam closed 2 years ago

ngam commented 2 years ago

fixes #53

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

Checklist

conda-forge-linter commented 2 years ago

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 commented 2 years ago

@conda-forge-admin, please rerender

teake commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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

teake commented 2 years ago

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: https://github.com/psf/requests/pull/6179.

ngam commented 2 years ago

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 commented 2 years ago

See for a thorough update: https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/287

including reverting marking the previous build as broken