Courtès: What's in a package
Courtès: What's in a package
Posted Sep 23, 2021 7:46 UTC (Thu) by t-v (guest, #112111)Parent article: Courtès: What's in a package
As someone with a lot of involvement in PyTorch, maybe some comments from my personal point of view (not speaking for PyTorch):
- One thing to keep in mind as context is that PyTorch is owned by Facebook and it provides for the lion share of the development (with NVIDIA, AMD, Microsoft, ... having people working on things particularly dear to them and also Quansight working on things on FB's behalf(?)). They do want traction and community, but in the end PyTorch's priorities are largely informed by Facebook's use-cases.
- PyTorch tries to take a "batteries included" approach that appears to be appreciated in many contexts. It is similar in complexity as NumPy/SciPy (who also bundle many numerical routines) but has the additional caveat that many of the dependencies (in particular where GPUs are involved) are not that well-supported in the usual distributions and thoroughly change between versions, or have weird bugs in specific versions.
- Some other things have originated close to PyTorch with PyTorch's use in mind but have been set up as separate projects. That's hardly a worse situation than sticking it into the PyTorch repository as an integral part.
- The autobuilders for PyTorch run with conda or bespoke docker containers. Personally, I am developing my PyTorch things on a vanilla Debian/unstable machine with the Debian-provided CUDA stack from non-free, so I've tried to keep that working (and I think with reasonable success) when glitches happened for not sticking stuff into /usr/local/cuda.
- For the limitations that PyPI already has, PyTorch prefers conda (where e.g. many of the NVidia deps are taken from the packages for that) as is. Because PyPI cannot match the matrix of packages they offer (various CUDA versions, AMD ROCm, CPU only) they already self-host many of the packages that people install via pip (in fact 3-4x as many, not counting nightly builds).
- Many of the bundled dependencies are changing very fast, releases only are for different versions of Ubuntu (e.g. NVidia seems to do 18.04 at the moment, others are on 20.04), so it would be a hassle for users to track them manually. I have seen them try with external dependencies and move those to bundled. This will be a major headache for packagers, but really, it's as much PyTorch's doing as it is that of the dependencies. Also, it means that PyTorch devs are generally not all that keen to have it packaged in the distributions (I think the Debian dev lumin has gotten less than enthusiastic comments).
- Some things will be very hard to support out of the box, e.g. NVidia's embedded hardware has a totally different hardware / driver setup to the desktop/server GPUs, so you cannot currently run them with Debian-provided CUDA because it is on an older version.
