PyTorch packages collected into single easyconfig, e.g. torchvision as extension?

[VRehnberg]

In an old Conference call it was said that

should things like torchdata and torchvision be installed as extensions in the PyTorch

• probably yes, anything under the pytorch organisation makes sense to add as extension to PyTorch
• is Pillow (dep of PyTorch) vs Pillow-SIMD (dep of torchvision) a problem?
  • not really, can just use the Pillow dep of PyTorch
• Pillow-SIMD should never be a direct dep for anything?
• especially since it doesn't work on aarch64?

I haven't followed the discussion since so I'm not sure if this has been decided differently. However, if it still holds how should the transition be?

I have one rejected PR (#16580) from which I gather that this would only be done for PyTorch easyconfigs before easyconfigs for torchvisision, torchtext, torchdata, torchaudio, ... with the PyTorch in question as dependency have been made?

What to do if some of the torchpackages exists as separate easyconfigs but not all, should additional packages be added as separate easyconfigs as well or as extension to PyTorch?

Should all new PyTorch easyconfigs include these extensions or can they be added in subsequent PRs (that can be rebuilt with eb easyconfig.eb --skip --rebuild)?

[boegel]

The general rule is that if we have separate easyconfigs already is that we add updated versions of those rather than include them as extensions in other easyconfigs.

In this case, I think it may make sense to "promote" torchdata and torchvisions to extensions of PyTorch though, since then they'll be available "by default". If there's a need for an older/newer version of either on top of that same PyTorch, we can still add separate easyconfigs for those.

So perhaps using separate easyconfigs by default was a historical, and we can transition to no longer do that.

That said, there are other torch* packages which require pulling in additional dependencies (that are not required for PyTorch itself), like torchtext (https://github.com/pytorch/text). In that case, it's probably better to keep them separate?

CC @lexming and @Flamefire to hear their view on this...

[lexming]

A fat easyconfig for PyTorch will be too cumbersome to maintain. Upgrading PyTorch to new versions is difficult enough as it is to be adding more moving parts into the mix. Moreover, let's say there is some issue with one of these extensions, do we want to delay a new release of PyTorch because of the extensions?

I suggest to make a bundle with PyTorch and these extensions, call it something like PyTorch-bundle or PyTorch-suite and then we will effectively get the same result without the aforementioned problems.

[lexming]

As discussed in the call today. One option with bundles would be to tie the version of bundle to the version of PyTorch used by it, this avoids any need for complicated version suffixes.

For instance, taking what we have now in the repo for 2022a, we could do

• PyTorch-bundle-1.12.0-foss-2022a would depend on:
  • PyTorch-1.12.0-foss-2022a.eb
  • torchsampler-0.1.2-foss-2022a.eb
  • torchvision-0.13.1-foss-2022a.eb
• PyTorch-bundle-1.12.0-foss-2022a-CUDA-11.7.0.eb would depend on:
  • PyTorch-1.12.0-foss-2022a-CUDA-11.7.0.eb
  • torchsampler-0.1.2-foss-2022a-CUDA-11.7.0.eb
  • torchvision-0.13.1-foss-2022a-CUDA-11.7.0.eb
• PyTorch-bundle-1.12.1-foss-2022a would depend on:
  • PyTorch-1.12.1-foss-2022a.eb
• PyTorch-bundle-1.12.1-foss-2022a-CUDA-11.7.0 would depend on:
  • PyTorch-1.12.1-foss-2022a-CUDA-11.7.0.eb

Any other extensions to PyTorch can be added as usual to the bundle by adding their respective easyconfig in the correspoding toolchain.

[boegel]

Or we could have PyTorch-extensions-1.12.0-foss-2022a.eb that is a bundle of extensions torchdata, torchvision, etc. (anything being developed under the pytorch GitHub org)?

[Micket]

Discussed on todays meeting we were in general agreement that a bundle on top of python would be preferable, with all compatible libraries for that particular release.

(we will need to make exceptions fo the suffix requirements though, since the bundle would just be named based on the pytorch release, which should be unique enough).

I made an example PR here: #17540 for the latest pytorch we have.

I named it bundle since we use that for scipy and friends