fix azure build failure

[efiop]

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]

@efiop it's not your fault. See https://conda-forge.org/status/, in particular conda-forge/status#117

[maresb]

Even better, see https://dev.azure.com/conda-forge/feedstock-builds/_build?definitionId=7270

[maresb]

Ah, sorry if I misunderstood, I see now that the build is indeed failing. So you were probably already aware of the CI issue, and are already debugging the recipe. 😄

[efiop]

@maresb Thanks for pointing that out! 🙏

Yeah, I've noticed that there are no checks triggered, but accidentally merged some PRs anyway. The azure issue has been around for a few days already, so just creating this WIP to not forget about it when CI comes back to life.

[maresb]

By using the last link I wrote, I think that you could still debug the issue, right? (It seems that the CI is still running, just not linked with these "checks" here on GitHub.) Or is there some complication?

[efiop]

Hm, looks like we now have an unrelated conflict on windows. A little confused by what is exactly conflicting, the logs are overloaded with conflicts. https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/367651/logs/60

[maresb]

@efiop, since Mamba often gives more sensible error messages, I just tried building locally on LInux with conda mambabuild . and got

msal-extensions 0.3.0 has requirement portalocker~=1.0; platform_system != "Windows", but you have portalocker 2.3.0.

I'm not sure at the moment where those dependencies are coming from.

[efiop]

@maresb That one is the same as what was reported by pip check. There is something else going on specifically on windows with python 3.9 Investigating...

[efiop]

@maresb Thank you for getting to the bottom of it! 🙏

[maresb]

The importlib-metadata package is indeed preferable. The importlib_metadata is just a pointer to importlib-metadata. But if you require importlib_metadata then conda will install both, which I think is confusing. But it shouldn't make any difference with the dependency resolution.

Do you have a Windows machine? If so, maybe you could try building locally with conda mambabuild . to see if you can reproduce the failure, and maybe mamba provides better info.

[efiop]

@maresb Thanks! Looks like pip check is still reporting the same problem 🙁

msal-extensions 0.3.0 has requirement portalocker~=1.0; platform_system != "Windows", but you have portalocker 2.3.1

[maresb]

This is disappointing. Conda is ignoring the build I created with the pin. It seems illogical to me, so I asked on Gitter. Hopefully someone has an idea on how to fix it.

[maresb]

@efiop, I hope you don't mind that I pushed to your fork; in case you're working locally, please don't forget to pull to avoid annoying conflicts.

I took the advice of isuruf on Gitter and added the portalocker <2.0 pin in the test requirements, even though this pin belongs in (and has already been implemented in) the latest build of conda-forge/msal_extensions-feedstock#11.

Hopefully the next release of msal_extensions will remove the portalocker<2 pin and then there will no longer be an issue.

[efiop]

@maresb I don't mind that at all, I'm really grateful actually ❤️

Btw, are you on our discord by any chance (I'm ruslan there)?

[efiop]

ok, disabled win + 3.9 for now, just to unblock releases. Will continue in a separate PR.

[efiop]

@conda-forge-admin, please rerender