vision: Improve error message when incompatible torchvision / PyTorch are used

@pmeier

Are you sure about that? This blog post suggests that torch==1.2.0 was released together with torchvision==0.4.0. If you are right this would break the rule that "the latest stable release of torchvision is only compatible with the latest stable release of torch.

My bad, this is how I think the compatibility matrix should look like

torch	torchvision	python
master / nightly	master / nightly	>=3.6
1.5.0	0.6.0	>=3.5
1.4.0	0.5.0	==2.7, >=3.5, <=3.8
1.3.1	0.4.2	==2.7, >=3.5, <=3.7
1.3.0	0.4.1	==2.7, >=3.5, <=3.7
1.2.0	0.4.0	==2.7, >=3.5, <=3.7
1.1.0	0.3.0	==2.7, >=3.5, <=3.7
<=1.0.1	0.2.2	==2.7, >=3.5, <=3.7

Were users here having issues with nighltlies or master? Or when using conda/pip to install torchvision? Again, I see nightlies and master as “at your own risk” with minimal guarantees. torchvision should simply be compatible with the latest master at all time.

Speaking for myself, I’m only really concerned with the release versions available via conda/pip. I don’t foresee a situation in which I’d personally need to figure out the PyTorch version compatibilities for old Torchvision nightly builds.

A correction for the table: the torchvision 0.5.0 package on PyPI requires torch==1.4.0, and it looks like torch 1.4.1 and 1.4.2 don’t exist.

are you planning to extend the support of torchvision outside the official statement? AFAIK torchaudio and torchtext are not planning this.

No, we will only enforce to be compatible with latest release, if it ends up working with older releases (if compiled from source) that’s a bonus, not a requirement.

Incompatible versions can lead to failures in many unexpected ways, and detecting all of them can be tricky. Once we detect incompatible versions, what do we do? Do we stop the import? Do we return a warning? Or maybe we selectively disabling features that are not supported?

My thinking was: import should not error. Users might not want to use C++ extensions, and the code should still hopefully work fine in most cases. But if the user calls into a C++ extension, then they should ideally get a good error message.

Catching errors and throwing other ones could also obscure legitimate issues. Thoughts?

Fair point. One of the issues we currently have is that in order to support torchhub, we need to catch an error at import and not hard-fail. But this makes error messages down the road a bit worse IMO.

What does torchtext do?

I was referring to a table like https://github.com/pytorch/text#installation

Speaking for myself, I’m only really concerned with the release versions available via conda/pip. I don’t foresee a situation in which I’d personally need to figure out the PyTorch version compatibilities for old Torchvision nightly builds.

I agree, let’s not overly complicate the problem. Having a compatibility matrix in the readme, and a better error message when running C++ ops that failed loading the .so pointing to the compatibility matrix should be enough I think

Out of curiosity: does a list of compatible versions exist somewhere?