(Comments only) Add more context about cryptography pins in pyopenssl

[maresb]

Implements #913 (comment)

I cherry-picked @IzerOnadimQC's comments and then adapted my comment to explain the rationale for maintaining monotonicity. CC @ocefpaf

I only modify comments, I don't change anything consequential.

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

[IzerOnadimQC]

Thanks!

[ocefpaf]

Thanks @IzerOnadimQC for the detailed explanation of the problem!

[ReimarBauer]

That is strange now I get

• cryptography 44.0.0 py311hafd3f86_0 conda-forge
• pyopenssl 21.0.0 pyhd8ed1ab_0 conda-forge

and it fails again https://github.com/Open-MSS/MSS/actions/runs/12122317805/job/33854056820

[maresb]

@ReimarBauer, it's loading the environment from cache. Do you have permissions to delete the cache files? (If not, there are some dirty tricks to bust the cache from the workflow YAML.)

[ReimarBauer]

@ReimarBauer, it's loading the environment from cache. Do you have permissions to delete the cache files? (If not, there are some dirty tricks to bust the cache from the workflow YAML.)

good catch. But it gives the next question. How can I recognize that I need to delete the cache?

[ReimarBauer]

result is and it works again

• cryptography 43.0.3 py311h544b224_0 conda-forge
• pyopenssl 24.2.1 pyhd8ed1ab_2 conda-forge

[maresb]

How can I recognize that I need to delete the cache?

Generally you shouldn't have to worry about this, and there are sane defaults for the cache key. The issue in this particular case is that adjusting the repodata is a fairly extreme (although unfortunately not unheard-of) intervention, and there's currently no cache busting mechanism for it. I think that implementing something would be pretty difficult.