Rebuild for increased compatibility and build for python 3.12

[conda-forge-admin]

See conda-forge/pytorch-cpu-feedstock#222

Hi! This is the friendly automated conda-forge-webservice.

I've started rerendering the recipe as instructed in #88.

If I find any needed changes to the recipe, I'll push them to this PR shortly. Thank you for waiting!

Here's a checklist to do before merging.

• Bump the build number if needed.

[conda-forge-webservices]

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.

[hmaarrfk]

Why is this never easy....

[Tobias-Fischer]

This might help @hmaarrfk: pytorch/vision#8280

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed

Thus the PR was not passing and not merged.

[Tobias-Fischer]

Looks like this isn’t ready for py312 yet ..

[hmaarrfk]

I'm going to see if i can patch out a few tests.

I had solved this 3 months ago for them: pytorch/vision#8119 and they just said: "lets hope this isn't the case"

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

Commits were made to this PR after the automerge label was added. For security reasons, I have disabled automerge by removing the automerge label. Please add the automerge label again (or ask a maintainer to do so) if you'd like to enable automerge again!

[hmaarrfk]

Basically the torch kit uses the abstract syntax tree from python and it is issuing some warning about some Breaking chnages happening in python 3.14. I’ve ignored the deprecation warnings and it seems to be passing. Are we ok with this?

[h-vetinari]

Completely fine with the patches, fine with (but not excited about) turning into single output. Let's just not remove things that keep the link check clean(er)

[h-vetinari]

Please leave the rpath bit

[hmaarrfk]

Is it still important now that we have libtorch that installs things in the PREFIx/lib

[h-vetinari]

No. That's nice.

But it looks like pytorch needs a run-export on libtorch:

WARNING (torchvision,lib/python3.10/site-packages/torchvision/image.so): Needed DSO lib/libc10.so found in ['conda-forge/linux-64::libtorch==2.1.2=cuda112_hf51c5c5_301']
WARNING (torchvision,lib/python3.10/site-packages/torchvision/image.so): .. but ['conda-forge/linux-64::libtorch==2.1.2=cuda112_hf51c5c5_301'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)
WARNING (torchvision,lib/python3.10/site-packages/torchvision/image.so): Needed DSO lib/libtorch_cpu.so found in ['conda-forge/linux-64::libtorch==2.1.2=cuda112_hf51c5c5_301']
WARNING (torchvision,lib/python3.10/site-packages/torchvision/image.so): .. but ['conda-forge/linux-64::libtorch==2.1.2=cuda112_hf51c5c5_301'] not in reqs/run, (i.e. it is overlinking) (likely) or a missing dependency (less likely)

[h-vetinari]

Or rather, we need to specify the host-dep on libtorch here.

[hmaarrfk]

thanks!

[Tobias-Fischer]

Do we still need the host-dep on pytorch? Can't we get rid of it thanks to the libtorch host-dep, and instead only have a run-dep on pytorch?

[h-vetinari]

Do we still need the host-dep on pytorch? Can't we get rid of it thanks to the libtorch host-dep, and instead only have a run-dep on pytorch?

Yeah, I think we could, but it doesn't make a big difference for now, since we still need pytorch at runtime.

[h-vetinari]

LGTM, with our without the question about the pytorch host-dep. We can remove it next PR. Or now. I don't mind.

[Tobias-Fischer]

LGTM too, thanks @hmaarrfk!