Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support installation via pip #18634

Open
vadimkantorov opened this issue Jul 19, 2023 · 10 comments
Open

Support installation via pip #18634

vadimkantorov opened this issue Jul 19, 2023 · 10 comments
Assignees
Labels
Area-Setup Acquisition and deployment team

Comments

@vadimkantorov
Copy link

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
Copy link
Member

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
Copy link
Author

vadimkantorov commented Jul 20, 2023

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
Copy link

zooba commented Jul 21, 2023

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
Copy link
Author

vadimkantorov commented Jul 21, 2023

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
Copy link

zooba commented Aug 8, 2023

@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.

@tarekgh tarekgh added the Area-Setup Acquisition and deployment team label Aug 17, 2023
@JoeZhongTR
Copy link

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

@richlander richlander transferred this issue from dotnet/core Feb 13, 2024
@msbair
Copy link

msbair commented Aug 19, 2024

I'm wondering how this effort is going. Is there an update? This would be an extremely useful capability for me.

@vadimkantorov
Copy link
Author

vadimkantorov commented Aug 29, 2024

@richlander Is this repo the up-to-date place for issues? in README is advised to continue in https://github.com/dotnet/sdk... If this sdk repo is more appropriate, could you please transfer this issue over there?

@vadimkantorov
Copy link
Author

vadimkantorov commented Aug 29, 2024

Also, for pip-driven installation, might make sense to have the .NET major version to be versioned by PIP itself, so upgrades would be driven by PIP too and packages can take depend on a specific major .NET version (if they need to).

@marcpopMSFT
Copy link
Member

Old issue triage: @claudiaregio I believe you're working on or aware of an anaconda effort in this space. Any updates or links to that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Setup Acquisition and deployment team
Projects
None yet
Development

No branches or pull requests

8 participants