Repository: pytorch
Issue: ABI backwards compatibility
Labels: module: abi,triaged

## 🚀 Feature
Add backwards compatibility to the ABI for LibTorch.

## Motivation

At present LibTorch doesn't seem to have a backwards compatible ABI. For those of us writing LibTorch-dependent libraries, it would be beneficial if the binaries we distribute don't break when end users update their version of PyTorch.

In particular tools such as `pip` are essentially ignorant of such concerns, and there aren't good ways to encode such concerns in a way that `pip` can understand. As such, resolving these issues largely falls into the lap of the end user. (Who will often only be familiar with Python, and will not have the expertise to resolve such issues themselves.)

## Pitch

It would be great to develop an ecosystem around PyTorch similar to the ecosystem that has developed around NumPy! Adding backwards compatibility to the ABI would go a long way towards making this possible.

## Alternatives

Alternatives at the moment require that LibTorch-dependent libraries provide versions compatible with all of the versions of PyTorch they wish to support. However, as the tooling is not set up around such expectations, this still leads to multiple thorny issues.

- The first and simplest way to handle this issue is to simply provide source distributions of the dependent library (which will remain compatible provided the LibTorch API remains compatible). This of course requires the end user to have a compiler available, which is often not true on Windows.
There exists a subtler issue, however. Once the source of the dependent library has been compiled, then `pip` will cache this compiled version - implicitly adding a dependence on the version of PyTorch that the dependent library was compiled against. Subsequent installs via `pip` will throw `ImportError`s about undefined symbols when used with new versions of PyTorch.
The end user has to know to recognise this issue, and run `pip install dependent_library --no-cache-dir` to not use the cached version and thus force a recompilation.

- The second possibility is to provide precompiled binaries of the dependent library for all versions of PyTorch that the dependent library wishes to support. This has obvious issues: the amount of work required increases as new versions of PyTorch are supported, and asks a lot of the library author to continue to provide these many versions into the future.
However once again, there exists an issue with `pip` around this option.  Namely, that there isn't a good way to specify this dependency on the version of PyTorch in a way that `pip` will understand. It is possible to adjust the version of the dependent library, e.g. from `1.1.4` to `1.1.4-compiled-with-pytorch-1.3.0` (either programmatically inside `setup.py` or by using its `egg_info` option). But now a simple `pip install dependent_library` command will likely download the wrong version. There's a few ways that this issue might be hacked around with `pip` (which I'll avoid discussing now to avoid writing an essay - I can express those in more detail later on if necessary), but they're all essentially unsatisfactory.

In the end, the best current workaround seems to be the second option, and to tell end users to install specifically via `pip install dependent_library==<dependent_library_version>-compiled-with-pytorch-<version_of_pytorch_they_have_installed>`.

## Additional context

I'm guessing that maintaining a backwards compatible ABI is likely to be hard work! I admit to ignorance as to how this is actually accomplished in practice, except to note that to the best of my knowledge, both Python and NumPy have accomplished this.

Furthermore I admit to not being familiar with providing packages through `conda`, and whether they provide ways of handling the packaging issues discussed above.