Enable redistribution of CSnakes-based solutions via NuGet

[atifaziz]

This is a feature request to allow developers to distribute libraries built using CSnakes via nuget.org for easy consumption by application and other libraries. Such libraries will be expected to leverage CSnakes and Python modules and packages internally and provide a friendlier .NET API.

Here is an initial summary of what's needed and/or desired for this:

• A distributor of such a NuGet package should be able to ship everything that's needed. Two main things that come to mind are:
  • the sources of the Python modules
  • and requirements for installation of any necessary Python packages used by the modules.
• The .NET API of such a package should:
  • expose an extension method for IPythonEnvironment that loads its modules
  • and provide a method for DI registration of the services it offers.
• The responsibility of setting up IPythonEnvironment lies with the package consumer.
• The Python module source(s) can be embedded and loaded from the assembly so there's a single binary to distribute instead of having many loose files on disk. This shouldn't require modifications to import statements.
• The Python package requirements can be expressed programmatically and incrementally without needing a requirements.txt.
• There should be a way to express (in metadata?), the minimum required Python version. The set of package requirements should also be discoverable.
• If multiple such NuGet packages are being consumed by an application and have conflicting requirements then these should result in an error that fails the application start-up.
• Optionally, MSBuild artefacts in the package that add the Python modules to the output of the hosting project if the files need to be on disk.

[aaronpowell]

I was initially thinking that this is something that could be tackled using codegen, basically taking a list of packages and then we generate the csproj, add the Python packages, and then run a dotnet pack on them. But the idea falls down when I start thinking about the entrypoint for using a Python package.

Let's say we wanted a CSnakes.Numpy package to be shipped on NuGet, well, what would the API surface area that someone would consume from the assembly look like? Are we trying to provide a bunch of generic methods that someone can do something with? Or do we need to provide some targeted APIs for someone to consume?

The more I think about it, the more I wonder if there's really anything that can be solved in CSnakes to support shipping via NuGet. The codegen from the source generator uses DI to get the Python environment, so there shouldn't be a conflict of configuring multiple Python environments (assuming you want to use the same Python version).

Maybe we could make CSnakes support loading the .py file that the source generator built off via an embedded resource or dynamic file (so, embed the Python source in the assembly), but the reality is, you can ship arbitrary files inside a NuGet package anyway so it means you could distribute your Python and .NET assembly in a single package.