Open dsyme opened 3 years ago
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
Sounds great!
What about MacOS? No need for a combo?
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/
This is done, but we need to check pacakges are building in main and then republish
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.
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
TorchSharp-cuda-11.1-linux-x64
TorchSharp-cuda-11.1-windows-x64
The above are in addition to the existing packages:
TorchSharp
libtorch-cpu
libtorch-cuda-11.1-linux-x64
libtorch-cuda-11.1-windows-x64
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.