setup.py dynamically changes the pytorch version dependency.

[anguelos]

🐛 Bug

setup.py sets the pytorch dependency version to whatever was available when the package was built.
This changes the behavior (requirements) of the torchvision package depending on the system on which it is being packaged (setup.py runs).
I believe a dictionary with the table in https://pypi.org/project/torchvision/
I am not sure if I am missing something on why this should be dynamic.
But as far as I understand, having a version that forces upgrading to 1.6.0 while it is documented requiring <=1.0.1 seems like a bug.

I believe the solution would be to the table in https://pypi.org/project/torchvision/ explicitly coded as a dictionary in setup.py

version = '0.6.0'

#####

torchvion_pytorch_dependencies = {'0.6.0': '1.5.0', '0.5.0': '1.4.0'} # etc

#####

pytorch_dep = 'torch>=' + torchvion_pytorch_dependencies[version]

Also I think >= is more flexible than == but I am not sure what might be the downside.

In conclusion, I am not sure this is a bug but while I can see the drawbacks of such a design, I fail to see the benefits.

To Reproduce

Steps to reproduce the behavior:

In a vanilla environment:

#1) install a reasonable pytorch version eg: 1.5.0
pip3 install torch==1.5.0  -f https://download.pytorch.org/whl/torch_stable.html --user
python3 -c "import torch;print(torch.__version__)"
# prints 1.5.0+cu92

#install a very old torchvision version
pip3 install torchvision==0.2.2 --user
python3 -c "import torch;print(torch.__version__)"
#prints 1.6.0

Expected behavior

I would expect that torchvision 0.2.2 is either satisfied with pytorch 1.5.0 or, that it enforced a dependency on pytorch<=1.0.1 as documented when it was written (https://pypi.org/project/torchvision/)

Environment

This was run after install torchvision 0.2.2

Collecting environment information...
PyTorch version: 1.6.0
Is debug build: No
CUDA used to build PyTorch: 10.2

OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: Could not collect

Python version: 3.6
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration:
GPU 0: TITAN V
GPU 1: GeForce GTX 980 Ti

Nvidia driver version: 450.51.06
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5

Versions of relevant libraries:
[pip3] numpy==1.19.1
[pip3] torch==1.6.0
[pip3] torchvision==0.2.2
[conda] Could not collect

 - PyTorch / torchvision Version (e.g., 1.0 / 0.4.0):
 - OS (e.g., Linux):
 - How you installed PyTorch / torchvision (`conda`, `pip`, source):
 - Build command you used (if compiling from source):
 - Python version:
 - CUDA/cuDNN version:
 - GPU models and configuration:
 - Any other relevant information:

## Additional context

[pmeier]

This might be related to #2359.

[anguelos]

I could make a pull request with what I believe is the proper behavior.
But I am not sure how to test it.

[pmeier]

I believe the solution would be to the table in https://pypi.org/project/torchvision/ explicitly coded as a dictionary in setup.py

If I understand you right, a dictionary isn't going to help much. If we patch setup.py the change will only effect torchvision>0.7.0. Thus, it is enough to pin torch to the current or upcoming version. Right now we could pin it to torch>=1.7 and change that to torch==1.7 for the next release.

I am not sure if I am missing something on why this should be dynamic.

I've wondered this myself. @fmassa any insights?

[anguelos]

I have proposed an equivalent PR in kornia as it uses the same design pattern for setup.py .
https://github.com/kornia/kornia/pull/597/files

I suggest the proper strategy is to set a minimum version either based on evidence (eg passed testcases) or what what was used for development. And set the maximum by default open, and change that once there is evidence something breaks.

The question is should the maximum version apply to all previous torchvision cases as well?
If we know torchvion 0.5.0 breaks with pytorch 1.6.0, should we put automatically 1.6.0 as an upper bound 0.4.0, 0.3.0 etc.

[fmassa]

Hi @anguelos

Unfortunately what you propose is not possible since torchvision 0.3.0, as we introduced compiled elements to torchvision that depend on a specific version of PyTorch, as there are ABI incompatibilities between pretty much every PyTorch version.

We have been having multiple user issues in the past due to incompatible PyTorch / torchvision versions, see #2148 and #1916 for an example.

With #2467 we will be raising a more meaningful error message (but which will still be an error message).

As such, I believe the current behavior is correct for torchvision, but please let us know if you disagree.