Create combo packages

[dsyme]

Part of the problem underlying stuff like #347 is the need for this "loading logic" in TorchSharp at all, it's a mess especially the cases for F# Interactive.

On talking it through with @gbaydin, one suggestion was that we should add "runtime ready" combo packages that combine TorchSharp with the appropriate runtime, and also have these ensure that on package restore the native binaries are put together in a place loadable by F# Interactive and .NET Interactive, without any hassle or initialization code.

These would be the three combo packages:

• TorchSharp-cpu

  • references matching TorchSharp package
  • references matching libtorch-cpu package
  • on restore, ensures that native binaries are all available in one known directory

• TorchSharp-cuda-11.1-linux-x64

  • references matching TorchSharp package
  • references matching matching libtorch-cuda-11.1-linux-x64 package
  • on restore, ensures that native binaries are all available in one known directory

• TorchSharp-cuda-11.1-windows-x64

  • references matching TorchSharp package
  • references matching libtorch-cuda-11.1-windows package
  • on restore, ensures that native binaries are all available in one known directory

The above are in addition to the existing packages:

• TorchSharp

  • contains managed component
  • contains one native component

• libtorch-cpu

• libtorch-cuda-11.1-linux-x64

  • plus various "fragment" packages for delivery
  • on restore, restitches fragments

• libtorch-cuda-11.1-windows-x64

  • plus various "fragment" packages for delivery
  • on restore, restitches fragments

It's important to still have the plain "TorchSharp" package because this is what things like DiffSharp.Backend.Torch reference - it's the programming model with (most) of its implementation, but short of the selected libtorch native binaries.

[dsyme]

Note we use combo packages in DiffSharp to give a single package to reference - the above would also simplify DiffSharp and correctly put the sanity checking for an overall valid set of references in TorchSharp

[gbaydin]

Sounds great!

[NiklasGustafsson]

What about MacOS? No need for a combo?

[gbaydin]

I think libtorch-cpu covers all of linux, macos, windows and there is no libtorch-cuda because libtorch doesn't support cuda on macos. See below from https://pytorch.org/get-started/locally/

[dsyme]

This is done, but we need to check pacakges are building in main and then republish

[dsyme]

Note that what's been done so far doesn't adjust the package restore behaviour, so we should leave this open and consider doing that separately

and also have these ensure that on package restore the native binaries are put together in a place loadable by F# Interactive and .NET Interactive, without any hassle or initialization code.