Include Declarations.yaml into libtorch-binary

[junjihashimoto]

Declarations.yaml is a artifact of building pytorch. (Now the libtorch-binary does not include it.) The spec includes the type-definitions of API. It is useful to make FFI-bindings of other languages. The definition may be changed by the building environment(CPU-only or CUDA). Could you include the spec into libtorch-binary?

[apaszke]

I guess we could include that, but we should probably include a note that we provide no guarantees w.r.t. the format of this file. While I agree it's very useful the ongoing refactor might make it difficult to keep backward compatibility.

Also cc @gchanan @ezyang

[ezyang]

The primary issue is stability of this interface. There are a few things going on:

1. There is ongoing schema work across JIT and ATen (@cpuhrsch @gchanan) and we aren't planning to stabilize the schema until next release.
2. We have a bunch of "small" https://github.com/pytorch/pytorch/issues/12562 specifies the BC-breaking changes we still want to make to Declarations.yaml

If it makes your life substantively better to have nightlies with unstable Declarations.yaml, we can add it in; otherwise, I'd prefer if we sit on this patch until things stabilize and then add them in.

[gchanan]

Even more than stability, Declarations.yaml is trying to solve a fundamentally different problem, which is to generate VariableType (i.e.: add autograd support). It's not sensible to guarantee stability on an internal interface like this.

So, I'd say feel free to use this, but don't expect stability.

[lostmsu]

@ezyang how's the schema going? What is the best thing to consume to generate an object-oriented API for a new language?

[ezyang]

Still not in a "clean" state, unfortunately. We're working on some changes in this area but it's gotten pretty crufty and it is taking us time to unwind it.