Upgrade Requirements action broken on snowflake-connector-python

[robrap]

The edx-platform Upgrade Requirements github action is currently broken, because it tries to build pyarrow from wheel and fails. See example failure here: https://github.com/openedx/edx-platform/actions/runs/18169581369/job/51720673959. The error is:

Building wheel for pyarrow (pyproject.toml) did not run successfully.

This issue is happening against master, but this last failure was against an attempt to directly reference pyarrow in an attempt to bypass the failure. This did not work.

• fix: add pyarrow to kernel requirements #37415

Other notes:

• @dianakhuang found [Python] ERROR: Failed building wheel for pyarrow on Linux apache/arrow#36965, that may explain some.
• I also tried upgrading just django, and a different error. Possibly the upgrade on dependency job is also broken and requires a different ticket.

pip._vendor.packaging._tokenizer.ParserSyntaxError: Expected end or semicolon (after name and no valid version specifier)

django-oauth-toolkit==

[feanil]

So the issue was actually this: snowflakedb/snowflake-connector-python#2541

Because the snowflake-connector-python library pins some transitive dependencies, it was being forced to downgrade to a version that depended on the old version of pyarrow. They have a new release planned which should fix this so we could constrain cryptography until they do that or wait a few more days for this to resolve itself. I confirmed that constraining cryptography<46.0.0 does mitigate the issue. But the real fix is snowflake-connector-python correcting its dependencies which has merged but not yet release as version 4.0.0

[UsamaSadiq]

The Django 5.2 upgrade PR in edx-platform is currently blocked on this issue because the requirements need to be updated but make upgrade action is failing both on GitHub Actions CI and locally.

@feanil should we use your suggested fix to unblock the django upgrade PR for now or wait for a few days to have the latest release of snowflake-connector-python which shall resolve this issue altogether?

CC: @awais786

[robrap]

Is there any downside to adding a constraint that fixes now and is commented to detail when and how the constraint can be removed, including a link to this issue?

[UsamaSadiq]

Is there any downside to adding a constraint that fixes now and is commented to detail when and how the constraint can be removed, including a link to this issue?

There shouldn't be any issue. It's the standard practice we use where we pin the versions to unblock and document an issue to unblock the constraint once the fix is available.

[feanil]

@UsamaSadiq Please proceed with constraining cryptography and moving forward with the django upgrade. I didn't realize it was blocking that upgrade since that PR has been up for a while.

FYI, I've filed openedx/edx-enterprise#2467 because this isn't the first time this dependency has caused issues and it turns out it's usage is fairly specific.

[UsamaSadiq]

@UsamaSadiq Please proceed with constraining cryptography and moving forward with the django upgrade. I didn't realize it was blocking that upgrade since that PR has been up for a while.

FYI, I've filed openedx/edx-enterprise#2467 because this isn't the first time this dependency has caused issues and it turns out it's usage is fairly specific.

Django 5.2 Upgrade PR needs to be fixed too because its requirements validation check started failing after edx-enterprise new version was merged in master. I'll go ahead and pin the cryptography version to make the PR green for now.

[UsamaSadiq]

Upgrade job fixed with pinning the package versions. Follow up issue created to unpin the constraints later on so this issue can be closed now.