 connor (burnt/out) (UTC-8) | Okay what should nix-community/cuda-legacy look or be structured like? As an example: supporting CUDA 11. NCCL has already cut its last release supporting CUDA 11, so we need a package expression for that in the repo. Then there’s PyTorch: if that’s already cut its last release supporting CUDA 11, we need an expression for that as well. In the case of packages with many dependencies, like PyTorch, I’m not sure how long we’d be able to use upstream to provide dependencies, even if we vendor the package expression in tree, because eventually they’ll get bumped to something too new for the version of the package we’re locked to.
Is it viable for cuda-legacy to just re-expose a copy of Nixpkgs fixed to some point in time? I would think not (at least naively) without a way to deduplicate the number of Nixpkgs instantiated (e.g., providing cuda-legacy as an overlay and having it draw relevant packages from a fixed version of Nixpkgs while somehow using the most of the underlying instance of Nixpkgs). | 19:54:54 |
SomeoneSerge (back on matrix)
ysndr joined the room.
oak 🏳️🌈♥️ changed their profile picture.
@emma:rory.gay joined the room.