Consider packing command-line player as a .NET tool

[glopesdev]

With standard libraries gradually retargeting the new .NET core, running command-line workflows cross-platform is now possible. Pending editor support, the current approach requires using the Bonsai.Player standalone app as an entry point to compile the workflow and subscribe to the resulting observable. However, until now there hasn't been an easy way to distribute and install the player app in a way that would integrate well with command-line use.

Enter .NET tools which are actually a NuGet-based app-distribution model for standalone console applications. If we pack the player as a .NET tool we can provide access to the player immediately from the dotnet command runner. Furthermore, .NET tools can be managed both globally and locally using manifest files so they also align well with our goal of having reproducible environments.

Some resources and discussion points to address when considering this development:

• System.CommandLine: .NET tools are command-line heavy, so they benefit from having a documented, well-structured CLI which the new System.CommandLine assembly provides.
• NuGet package cache: One direct issue with running the player as a .NET tool is that we won't have access to a mutable environment anymore where packages can be installed and uninstalled. All state will have to be managed by files declared in the workflow folder itself. Most likely the ideal way to work around this would be to store all package dependencies either in the Extensions.csproj file or in some kind of Bonsai.config file stored locally in the workflow folder itself. Ideally packages could be restored by dotnet add package or dotnet remove package itself and the player would simply configure itself to locate the correct package versions from the global cache folder and resolve all dependencies from there.

[glopesdev]

The bit on managing packages directly from the NuGet package cache would also align well with the goal of removing direct assembly paths from the Bonsai.config file even for the editor bootstrapper itself. This would make local environment metadata more reproducible for cross-platform builds with runtime-specific packages.