Skip to content

Build single Python.Runtime.dll for all platforms #1365

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

Merged
merged 21 commits into from
Jan 28, 2021

Conversation

lostmsu
Copy link
Member

@lostmsu lostmsu commented Jan 22, 2021

What does this implement/fix? Explain your changes.

This allows building the same Python.Runtime.dll on all platforms and supported Python versions.

To invoke Python code from .NET, one needs to set Python.Runtime.Runtime.PythonDLL or manually preload DLL before invoking any Python.NET functions or other properties.

Implementation details

PInvoke signatures have been replaced with unmanaged functions pointers, that are loaded using ILibraryLoader on the first attempt to call any Python C API functions.

Marshaling attributes have been replaced with explicit marshaling calls.

PythonDLL gets its default value in the following order from:

  1. PYTHONNET_PYDLL environment variable
  2. Is set to null when launched from Python (so that DLL is already loaded in the process).
  3. Set to a platform-dependent value, based on PYTHONNET_PYVER environment variable (e.g. '3.6' -> 'libpython3.6.so')

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Add yourself to AUTHORS
  • Updated the CHANGELOG

@lostmsu
Copy link
Member Author

lostmsu commented Jan 22, 2021

A few issues still in the works:

  1. Presence of 'm' suffix in the python C API DLL name. Used to be determined by setup.py and embedded into Python.Runtime.dll. We need some reliable way to get it from CI environment.
  2. On Mac build fails due to some internal .NET SDK/Roslyn issue.

@lostmsu
Copy link
Member Author

lostmsu commented Jan 22, 2021

Ideally, we should vend Python.Runtime.dll separately from the Python embedding module, and build it separately too.

@filmor
Copy link
Member

filmor commented Jan 22, 2021

Presence of 'm' suffix in the python C API DLL name. Used to be determined by setup.py and embedded into Python.Runtime.dll. We need some reliable way to get it from CI environment.

On Linux, pkg-config is the way to go. I also think that we should be able to pass the libpython directly, not just as version + abiflags.

Ideally, we should vend Python.Runtime.dll separately from the Python embedding module, and build it separately too.

That is the plan, with clr-loader we just put Python.Runtime.dll somewhere and load it via pure Python. I have this working against the P/Invoke implementation.

@lostmsu lostmsu force-pushed the features/VersionIndependent branch 4 times, most recently from 2cbce6a to f557fb5 Compare January 22, 2021 19:01
@lostmsu
Copy link
Member Author

lostmsu commented Jan 23, 2021

Mac build appears to be blocked on dotnet/roslyn#46772

@lostmsu lostmsu force-pushed the features/VersionIndependent branch from e0c14cf to 478023d Compare January 23, 2021 05:29
@lostmsu lostmsu force-pushed the features/VersionIndependent branch from abaa42f to c0a751b Compare January 23, 2021 05:46
@lostmsu lostmsu requested a review from filmor January 23, 2021 07:25
@lostmsu
Copy link
Member Author

lostmsu commented Jan 23, 2021

One check is failing still, that's the same one everywhere else.

namespace Python.Runtime.Native
{
[StructLayout(LayoutKind.Sequential)]
struct StrPtr : IDisposable
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe NativeString would be more appropriate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Naming things :-D

Not sure about NativeString. It has connotations to native string type supported on the platform, but this is not it.

It might make sense to have a StrPtr type per encoding for clarity. Then signatures could enforce it. But maybe that would be overengineering.

Copy link
Member

@filmor filmor Jan 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we use any encoding apart from UTF8? I thought all FromString functions nowadays used that.

Indeed, I find exactly one usage with Encoding.ASCII, everything else is UTF8. And the one case that uses ASCII is PyBuffer_SizeFromFormat, which doesn't specify ASCII encoding either, I highly doubt it will break if it's passed UTF8 instead as it will probably just compare bytes directly and bail out on anything that it doesn't understand.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main thing I find "problematic" is that this object is not a pure pointer, it has ownership over the buffer it points to.

@@ -22,6 +22,7 @@ public PyDict(IntPtr ptr) : base(ptr)
{
}

internal PyDict(BorrowedReference reference) : base(reference) { }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should rename PyDict to something like PyDictFacade to make it clear that it doesn't take ownership.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This overload actually does incref internally (which makes sense, since to create a potentially long-lived PyDict object pointing to something we borrowed, we need to IncRef).

internal static extern IntPtr PyObject_GetAttr(IntPtr pointer, IntPtr name);
internal static int PyObject_SetAttrString(IntPtr pointer, string name, IntPtr value)
{
using var namePtr = new StrPtr(name, Encoding.UTF8);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this pattern is used in a lot of places, we should have a function for this (GetUtf8String or something like that). That could open up potential optimisation paths with caching or preallocated buffers per thread.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At this point it would be a premature optimization. Also, I don't see how we could cache disposable struct instances easily.

@@ -2185,6 +2276,539 @@ internal static IntPtr GetBuiltins()
{
return PyImport_Import(PyIdentifier.builtins);
}

private static class Delegates
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make Runtime a partial class and move this into a separate file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can do this just before pushing. Otherwise it would require me to update the roslyn package, that does automatic conversion of [DllImport] into the pattern with Delegates.

{
// only in 3.9+
}
PyBuffer_IsContiguous = (delegate* unmanaged[Cdecl]<ref Py_buffer, char, int>)GetFunctionByName(nameof(PyBuffer_IsContiguous), GetUnmanagedDll(_PythonDll));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you generate this via a script? That would be a good addition (although I'd hope we wouldn't need too many changes of this class ;)).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The script converted DllImport declarations. It did not work on the Python source, headers, or docs. Essentially, signatures are identical to what we had except string parameters and a few minor exceptions where I switched to *Reference types.

@lostmsu lostmsu force-pushed the features/VersionIndependent branch from 675ec5f to a6cbe20 Compare January 28, 2021 19:20
@lostmsu lostmsu merged commit 9e5887c into pythonnet:master Jan 28, 2021
@lostmsu lostmsu deleted the features/VersionIndependent branch January 28, 2021 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants