PyTorch and Torchvision version update

[tanwarsh]

Update PyTorch to version 2.4.1 and Torchvision to version 0.19.1.
setuptools is pinned to 59.6.0 as with latest version we are facing issue pytorch/pytorch#143288.

Fix for #1075.

[tanwarsh]

Pipelines are facing Issue pytorch/pytorch#140914.

[kta-intel]

Pipelines are facing Issue pytorch/pytorch#140914.

Thanks for raising the issue. Can you look into the possibility of adding the monkey patch to openfl.interface.cli?
I didn't do any extensive testing on the e2e functionality, but it got past the TypeError

pytorch/pytorch#140914 (comment)

If it works, we can maybe implement it while we wait for a more robust upstream solution, or we can investigate where/how pip._vendor.typing_extensions is being forcibly called for a more robust solution in our code base

[tanwarsh]

Pipelines are facing Issue pytorch/pytorch#140914.

Thanks for raising the issue. Can you look into the possibility of adding the monkey patch to openfl.interface.cli? I didn't do any extensive testing on the e2e functionality, but it got past the TypeError

pytorch/pytorch#140914 (comment)

If it works, we can maybe implement it while we wait for a more robust upstream solution, or we can investigate where/how pip._vendor.typing_extensions is being forcibly called for a more robust solution in our code base

Thank you @kta-intel. Workaround patch worked.

[MasterSkepticista]

Why are we insisting on pinning torch and torchvision, that too to latest versions? Is there anything we lose by using stable, yet recent torch versions?

I am not in favor of instrumenting and applying hotfixes that become a future maintenance burden, especially if torch~=2.3.0 works without any bugs mentioned in this PR.

WDYT? @psfoley @kta-intel @teoparvanov @theakshaypant

[tanwarsh]

Why are we insisting on pinning torch and torchvision, that too to latest versions? Is there anything we lose by using stable, yet recent torch versions?

I am not in favor of instrumenting and applying hotfixes that become a future maintenance burden, especially if torch~=2.3.0 works without any bugs mentioned in this PR.

WDYT? @psfoley @kta-intel @teoparvanov @theakshaypant

with torch~=2.3.0 we are facing issue in windows. Please refer this Issue #1075

[MasterSkepticista]

Why are we insisting on pinning torch and torchvision, that too to latest versions? Is there anything we lose by using stable, yet recent torch versions?
I am not in favor of instrumenting and applying hotfixes that become a future maintenance burden, especially if torch~=2.3.0 works without any bugs mentioned in this PR.
WDYT? @psfoley @kta-intel @teoparvanov @theakshaypant

with torch~=2.3.0 we are facing issue in windows. Please refer this Issue #1075

Did we try 2.4.x?

[kta-intel]

Why are we insisting on pinning torch and torchvision, that too to latest versions? Is there anything we lose by using stable, yet recent torch versions?
I am not in favor of instrumenting and applying hotfixes that become a future maintenance burden, especially if torch~=2.3.0 works without any bugs mentioned in this PR.
WDYT? @psfoley @kta-intel @teoparvanov @theakshaypant

with torch~=2.3.0 we are facing issue in windows. Please refer this Issue #1075

Did we try 2.4.x?

I believe 2.4.x was initially triggering the AssertionError: /python3.11/distutils/core.py, but it seems that @tanwarsh managed to get past that error. Can you apply your resolution for the distutil issue and then check if this type error is also present out of the box? If not, I think we can safely stick to 2.4.x for now.

Though I think it is a practical solution, @MasterSkepticista brings up a good point that using sys.module to force consistent modules may be not a good long-term solution. It seems like the issue is directly related torch (under torch==2.3.1, pip.__vendor.typing_extensions does not get imported when checking ParamSpec, but it does in torch===2.5.1), so we may want to revive that thread and help the investigation since there doesn't seem to be a ton of action in it

[tanwarsh]

Why are we insisting on pinning torch and torchvision, that too to latest versions? Is there anything we lose by using stable, yet recent torch versions?
I am not in favor of instrumenting and applying hotfixes that become a future maintenance burden, especially if torch~=2.3.0 works without any bugs mentioned in this PR.
WDYT? @psfoley @kta-intel @teoparvanov @theakshaypant

with torch~=2.3.0 we are facing issue in windows. Please refer this Issue #1075

Did we try 2.4.x?

I believe 2.4.x was initially triggering the AssertionError: /python3.11/distutils/core.py, but it seems that @tanwarsh managed to get past that error. Can you apply your resolution for the distutil issue and then check if this type error is also present out of the box? If not, I think we can safely stick to 2.4.x for now.

Though I think it is a practical solution, @MasterSkepticista brings up a good point that using sys.module to force consistent modules may be not a good long-term solution. It seems like the issue is directly related torch (under torch==2.3.1, pip.__vendor.typing_extensions does not get imported when checking ParamSpec, but it does in torch===2.5.1), so we may want to revive that thread and help the investigation since there doesn't seem to be a ton of action in it

Thank you @kta-intel and @MasterSkepticista for your inputs. I will downgrade the version to 2.4.x and check both issues. If neither issue or the type error is not encountered, I will proceed with 2.4.x.

[tanwarsh]

@MasterSkepticista @kta-intel, We are using version 2.4.1 now without patch. Please review again.

[kta-intel]

Seems like pinning to 59.6.0 will trigger Snyk vulnerability concerns. Will this cause us issues down the line?

[kta-intel]

@MasterSkepticista @kta-intel, We are using version 2.4.1 now without patch. Please review again.

Thanks for checking into that @tanwarsh. Glad 2.4.1 is not raising the TypeError issue. My open now is if downgrading setuptools is the path we want to go. Even if we're able to justify it for a release, if we're stuck at 59.6.0 going forward with torch workloads, that could be unsustainable long term