Fix out-of-sync requirements

[maresb]

This is causing problems downstream, e.g. conda-forge/dvc-feedstock#234

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.

[maresb]

@conda-forge-admin, please rerender

[ghost]

Hmm, the CI builds aren't happy: Unsatisfiable dependencies for platform linux-64: {"portalocker[version='>=1.0,<1.1']"}

[maresb]

Ya, there's no conda-forge build for that version...

yet...

[dhirschfeld]

Those constraints aren't correct. ~=1.6 means >=1.6,<2.0 not >=1.6,<1.7:

• https://www.python.org/dev/peps/pep-0440/#compatible-release

• https://github.com/AzureAD/microsoft-authentication-extensions-for-python/blob/a0cfe93433400b2d4ea673ebdef4bf064243c13d/setup.py#L25-L26

[dhirschfeld]

Since msal-extensions should be forward-compatible with portalocker 2 we should simply remove the upper bound. That will still fail pip check though so it's probably necessary to remove the pip check test until it's fixed upstream

[maresb]

Oh. Oops!!!!! Thanks so much for pointing this out! 🤦‍♂️

[roederja]

Ya, there's no conda-forge build for that version...

yet...

So, you think this can be merged regardless as it doesn't work on linux anyway at the moment?

[maresb]

I'm inclined to obey pip check, the reason being that this would cause pip check to fail in everything downstream, not just msal-extensions. I'll fix the current pin...

[dhirschfeld]

I'm inclined to obey pip check,

IME pip check often fails for conda packages, When it works it's great as it gives you an extra level of protection but sometimes it just doesn't

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

[maresb]

@conda-forge-admin, please rerender

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

[dhirschfeld]

I suspect that pip check may only be happy if you specify ~=1.6 for # [win] and ~=1.0 for # [not win]

[dhirschfeld]

...which will require removing noarch (and rerendering)

[maresb]

My understanding is that pip check looks at the currently installed packages and verifies that they are in a consistent state. Since anything with >=1.6,<2.0 is consistent in either case, it should be fine.

[dhirschfeld]

I'm not so familiar with pip but that makes sense.... and the CI concurs!

[dhirschfeld]

This doesn't unblock poratlocker >=2.0 but it should stop all recipes depending on this from failing