feat: Load CLR with Python.NET

[LeeDongGeon1996]

changes

• Load CLR with Python.NET

• Implement

• Fix: Load CLR with Python.NET #420

[LeeDongGeon1996]

both failed actions look like authorization issue.

[DaveSkender]

both failed actions look like authorization issue.

• did a quick fix in ci: Fix PR title linter, add ARM64 runner #422 for Actions issue
• I’ll leave some convo notes in Load CLR with Python.NET #420 for the underlying problem
• will also review this after convo

[DaveSkender]

Check unit tests as I’ve now added an ARM64 runner for checks that are currently failing. It may be, that this more ideal Python.NET find_dotnet_root() utility isn’t actually working yet, for this situation.

[LeeDongGeon1996]

@DaveSkender Looks like the failed tests were false negatives for some reason. I re-run all tests and it all passed. Does it all passed before this PR?

yah, all green in my last couple PRs and on main push builds

[LeeDongGeon1996]

The root problem was my virtual environment on my local machine is on M1 Rosetta mode though. This proves the need that we should load clr through pythonnet. pythonnet is handling this case also.

[DaveSkender]

The root problem was my virtual environment on my local machine is on M1 Rosetta mode though. This proves the need that we should load clr through pythonnet. pythonnet is handling this case also.

I'm wondering if the root problem from #408 was actually with venv? We might need a build test for that. I removing my own local venv instance a couple weeks ago due to problems.

[DaveSkender]

Just re-request a Review when you want me to look at this again. I'm not sure if you'd intended to or are interested in checking out these two open topics:

1. Typings issue with clr .NET members, even if just dev env problem?
2. Broken venv handling, or if that's even related to our code.

[LeeDongGeon1996]

I'm wondering if the root problem from #408 was actually with venv? We might need a build test for that. I removing my own local venv instance a couple weeks ago due to problems.

@DaveSkender Sorry, I made you confused.

The reason for #408:

• This is because AddReference() does not work correctly on .NET9 over MacOS. You added DLL manually and now it works. I think finding DOTNET_ROOT manually is not a solution for here. That's why I removed that lines in this PR.

The reason for error on my virtual env:

• Because my virtual env was on M1 Rosetta mode, DotNet SDK path must be /usr/local/share/dotnet/x64, which is ended with x64. But our main branch currently is now fixed to /usr/local/share/dotnet explicitly. It caused the CLR load error on my machine.

So there was two different issues and venv is not a root cause of #408.

[LeeDongGeon1996]

I don't think we need a bulid test for venv. This should be done on pythonnet their side. and it is already covered by them.

[LeeDongGeon1996]

Typings issue with clr .NET members, even if just dev env problem?

@DaveSkender
I'm not sure but as I know that linting for .NET members are not supported since they are not python native things or even they don't provide the interface(like .pyi) that linter can recognize.

[DaveSkender]

Makes sense, intuitively. One thing I'll want to check is whether macOS with just .NET 9 still works. The GitHub runners have .NET 8 and .NET 9 installed, so we many not be getting an entirely pure test on that scenario.

In my head, I'm still confused by some of this -- if we rollback the changes I made to fix a problem; how is it that the problem is still solved? Is it the Assembly.LoadFile() was the fix, and other stuff was unneeded -- I think that's what you're saying, which makes sense. I ran into multiple issues in debugging, so I may have fixed an intermediate problem that wasn't needed after I'd fixed something else.

[DaveSkender]

I think I understand this better now, and was able to run in on a macOS with just .NET 9 installed.