Defining the Rust 2024 edition

Posted Jan 31, 2024 6:20 UTC (Wed) by zdzichu (subscriber, #17118)
In reply to: Defining the Rust 2024 edition by Cyberax
Parent article: Defining the Rust 2024 edition

dnf5 install pytorch

Defining the Rust 2024 edition

Posted Jan 31, 2024 6:23 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

It's in progress: https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus

And it doesn't include everything needed. Which will force you to install PyTorch manually.

See comments like: "this requires CUDA and is likely not package-able for Fedora. we'll have to figure out how to build pytorch without it."

Defining the Rust 2024 edition

Posted Jan 31, 2024 7:13 UTC (Wed) by aragilar (subscriber, #122569) [Link] (1 responses)

*CUDA* is the issue (as icc/MKL would be for any libraries depending on it), not PyTorch. Assuming you sorted out licensing so that your RPM(s) were fine to distribute (which I suspect would be non-trivial, given CUDA likely has a runtime that you'd need to share with users as well), then having a repository of reproducibly-builtable-by-anyone-with-CUDA PyTorch RPMs would not be a great challenge.

I suspect though because many of the machine learning libraries produce different results with different versions, users will want to freeze exact versions of everything, and only move when they tested with their particular code/dataset pair a new set of versions (which likely means freezing the versions forever because of a lack of time/funds), which isn't exactly amenable to using a distro-provided package.

Defining the Rust 2024 edition

Posted Jan 31, 2024 10:11 UTC (Wed) by farnz (subscriber, #17727) [Link]

The ROCm variation of PyTorch is also unpackaged, even though it's fully open-source down to the kernel modules, and thus licensing is not an issue.