Pin pyparsing

[krassowski]

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.

Follow up after #20

Hey, the only change in v21.2 was in this version pin.

[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.

[krassowski]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.
I tried to rerender for you, but it looks like there was nothing to do.

[jakirkham]

Oops. Thanks for the fix!

[jakirkham]

We will need a repodata hotfix as well

https://github.com/conda-forge/conda-forge-repodata-patches-feedstock

[krassowski]

FYI there is some discussion about this pin: pypa/packaging#471 (comment) and some suggestions to yank this patch release.

[jakirkham]

Interesting, thanks for sharing that

[beckermr]

In the meantime can we mark both versions as broken? We can unbreak them later.

[jakirkham]

Submitted a hot-fix in PR ( conda-forge/conda-forge-repodata-patches-feedstock#176 )

[jakirkham]

Sure I don't have strong feelings

[beckermr]

oh nvm. a package pin fix is great!

[jakirkham]

Ok 🙂

If we change our minds, we can always do something different 😉

[maresb]

Hi all, I'm trying to understand how repodata-patches works. I was wondering what is the purpose of bumping the build number in this case? I think it should be unnecessary since

1. the dependencies were modified in the repodata
2. changing the tests shouldn't modify the build

Did bumping the version number accomplish anything in this case? Just trying to understand, thanks!

[chrisburr]

Did bumping the version number accomplish anything in this case? Just trying to understand, thanks!

@maresb Your understanding is correct.

The main reason it's nice to update the recipe to make debugging easier and without it it's easy to check the feedstock, find the dependency is correct and the build number is 0 and then not realise build 0 was deployed from a different commit. (The truth can always be determined from the info directory but that's less convenient than GitHub)

[tpdownes]

Is there any way to yank the packaging=21.0 packages?

$ conda update --name default --all --yes
Collecting package metadata (current_repodata.json): done
Solving environment: -
Warning: 2 possible package resolutions (only showing differing packages):
  - conda-forge/noarch::packaging-21.0-pyhd8ed1ab_0, conda-forge/noarch::pyparsing-3.0.6-pyhd8ed1ab_0
  - conda-forge/noarch::packaging-21.2-pyhd8ed1ab_1, conda-forge/noarch::pyparsing-2.4.7-pyhd8ed1abdone

while it makes the right choice in my case, it still leaves a known invalid combination in the wild. Plus this annoying warning, possibly forever?

UPDATE: I take it back. I have to manually force a downgrade of pyparsing with

$ conda install packaging=21.2

and then the warning goes away. I'm not sure what the right action, if any, is for the conda-forge repo itself.