Support installation via pip

[vadimkantorov]

Currently there is only a package dotnetcore2 which curiously installs dotnetcore 3.1 :) https://pypi.org/project/dotnetcore2/

It would be great to support installing via pip of more recent .net core 7/8 in addition to other systemwide package managers

[richlander]

We're in favor of this and it has come up multiple times. The Python team at Microsoft made a request to us to do just this within the last year. We haven't been able to make this happen, as the team (who would do this) has been quite busy on some other more immediately .NET-centric projects. I'm hoping we can eventually make this happen.

For context, when we do projects like this, we invest up-front in industrial-strength automation so that we have confidence in regular delivery and to ensure low operational costs. That cost is the real issue. We support publishing to many systems, and this model is what enables us to scale.

For further context, we've had good success working with distro maintainers on getting .NET into Linux (and hombrew). https://github.com/dotnet/core/blob/main/linux.md

[vadimkantorov]

One controversial thought: if you manage to distribute dotnetcore via PyPi, it might be an interesting idea to also ship PythonNet package with it because it might be actually useful for people using pip in the first place (maybe just as a dependency to keep it maintained separately): pythonnet/pythonnet#2196

[zooba]

That's only a "controversial idea" if you suggest we should take someone else's package and ship it as our own ;-)

We don't have anything to do with pythonnet development (apart from occasionally helping with more obscure debugging), but we'd certainly hope that the pythonnet team would consider relying on our .NET package if/when we start updating it more reliably.

[vadimkantorov]

Yeah, one way or the other :) I guess pythonnet is currently targeted on using any existing dotnet installation and auto-installing dotnet would add another dotnet executable in PATH potentially shadowing an existing one. Or maybe it could somehow not install the executable or make it visible on PATH...

On the other hand, dotnet could take a dependency on it. But the controversial point may be that taking it as a hard dependency might on a relatively non-core package is not good from release management standpoint (as some hard bugs or python version support might hinder planned dotnet releases)

Also, as a feedback for educational/interactive/scripting purposes, it would be great to have simple user-facing Roslyn interface for compiling the code into a byte array and Assembly.Load-ing it into memory: pythonnet/pythonnet#2196 (comment)

Also dotnet run my_file_with_program_main.cs another_cs_file.cs in a scripting regime without a runtimeconfig / project file / any saved artifacts would be good (which would simply add all reference assemblies from the current SDK) - maybe can take inspiration from go/rust here (or from python itself)

It's a pain to figure out the path to csc.dll and to all reference assemblies

[zooba]

@vadimkantorov I think you're thinking about this the wrong way around. This package would be most useful for Python packages that include some .NET module and want to be able to run it, but from the user's POV, they're only using Python.

The artifacts-keyring package is an example of this, as is pymsbuild. Both are very much for Python users, but part of their implementation uses .NET, and so right now users need to install both. This package would allow those Python packages to automatically include a .NET runtime.

Similarly, pythonnet could choose to depend on the .NET package and bring its own copy, rather than requiring users to install it. But there's no sense in having a low-level dependency like .NET also depend on a higher-level interface like any of the packages I mention above. This one is for them to depend upon, if they so choose.

[JoeZhongTR]

Please kindly consider releasing a Arm64 version for Apple Silicone, where azureml-dataprep depends on it. Thanks!