Nightlies are currently incompatible with upstream nightlies

[seemethere]

Originally reported by @pbelevich but I've observed that torchvision nightlies are currently incompatible with torch nightlies due to a tight version constraint.

See:

pip install --pre torch torchvision -f https://download.pytorch.org/whl/nightly/cpu/torch_nightly.html

Looking in indexes: https://pypi.org/simple, http://100.97.64.150
Looking in links: https://download.pytorch.org/whl/nightly/cpu/torch_nightly.html
Collecting torch
  Downloading https://download.pytorch.org/whl/nightly/cpu/torch-1.6.0.dev20200622%2Bcpu-cp37-cp37m-linux_x86_64.whl (155.0 MB)
     |████████████████████████████████| 155.0 MB 64.1 MB/s
Collecting torchvision
  Downloading https://download.pytorch.org/whl/nightly/cpu/torchvision-0.7.0.dev20200622%2Bcpu-cp37-cp37m-linux_x86_64.whl (5.0 MB)
     |████████████████████████████████| 5.0 MB 3.3 MB/s
Processing /private/home/eliuriegas/.cache/pip/wheels/56/b0/fe/4410d17b32f1f0c3cf54cdfb2bc04d7b4b8f4ae377e2229ba0/future-0.18.2-py3-none-any.whl
Collecting numpy
  Downloading numpy-1.19.0-cp37-cp37m-manylinux2010_x86_64.whl (14.6 MB)
     |████████████████████████████████| 14.6 MB 14.3 MB/s
Collecting pillow>=4.1.1
  Downloading Pillow-7.1.2-cp37-cp37m-manylinux1_x86_64.whl (2.1 MB)
     |████████████████████████████████| 2.1 MB 16.2 MB/s
ERROR: torchvision 0.7.0.dev20200622+cpu has requirement torch==1.6.0.dev20200610+cpu, but you'll have torch 1.6.0.dev20200622+cpu which is incompatible.
Installing collected packages: future, numpy, torch, pillow, torchvision
Successfully installed future-0.18.2 numpy-1.19.0 pillow-7.1.2 torch-1.6.0.dev20200622+cpu torchvision-0.7.0.dev20200622+cpu

I think this is related to pytorch/pytorch#40352 and subsequently pytorch/pytorch#39669

Will close this after I see the issue resolve itself.

[seemethere]

Also perhaps it'd be a good idea to not lock the nightlies down so tightly, moving the requirement from:

• torch==1.6.0.dev20200610+cpu -> torch==1.6.0

WDYT @fmassa, @ezyang, @malfet?

[fmassa]

@seemethere I'm not sure that we can do much better about the locking of the nightlies -- see #2148 for more discussion, otherwise it will be very confusing I think.

[ezyang]

The big problem is that pip doesn't actually do dependency solving; it just greedily picks the latest versions and it turns out that sometimes they're just not compatible.

[seemethere]

I don't think we should make any guarantees about compat between nightly versions which should make this problem a non-issue.

[seemethere]

Just checked and this issue should be resolved now, although it did require a manual kick of the html update job.

We should probably update that job to be a lambda that runs on s3 updates, but we can do that at a later point.

[fmassa]

I don't think we should make any guarantees about compat between nightly versions which should make this problem a non-issue.

I'm not sure I follow. If we don't make guarantees that the nightlies match each other, then the purpose of the nightlies for the domain libraries is close to void, as it will be close to impossible for people to be able to use them?

[ezyang]

I'm not sure what @seemethere is referring to, but he might be saying that there should not be any requirement that torch from Jun 3 works with torchvision from Jun 1, which makes sense to me. However, for any given set of nightlies built on the same date (e.g., Jun 3), I feel we should guarantee that they are compatible with each other.

What actually happens right now is that if torch nightlies fail to build for some reason, torchvision nightly will be built on the last working version of the nightly. If torch then retroactively publishes a new nightly you gonna have a bad time.

[fmassa]

@ezyang

there should not be any requirement that torch from Jun 3 works with torchvision from Jun 1, which makes sense to me

Agree

However, for any given set of nightlies built on the same date (e.g., Jun 3), I feel we should guarantee that they are compatible with each other

Agree

What actually happens right now is that if torch nightlies fail to build for some reason, torchvision nightly will be built on the last working version of the nightly. If torch then retroactively publishes a new nightly you gonna have a bad time.

Oh I see. Yes, this makes sense and we probably want to avoid building / uploading a new torchvision nightly if the corresponding nightly for pytorch for that day failed building.

[ezyang]

That would certainly be one way to solve the problem, although you can also end up in the reverse situation, where torch for Jun 3 exists, but torchvision for Jun 3 doesn't exist. Because pip is le dumbe, that will also break all nightly installs.

What this suggests to me is we need two indexes: one index for pytorch that is updated whenever pytorch successfully builds a nightly, and a second index for vision which is only updated when BOTH pytorch and vision have successfully built.