FFI module architecture decision was 'Python support policy'

[Richard Laager]

On 9/7/20 11:03 AM, James Browning via devel wrote:
> I (re)developed a Python wrapper around a C FFI stub[1]. It is largely
> based around my merge request !1010 [2].
I'll repeat from here, in case people want to respond to those points:
https://gitlab.com/NTPsec/ntpsec/-/merge_requests/1010#note_282670775

----
Is converting the existing "manual" extension to use ctypes desirable? I
think the usual progression is the other way: you get a quick FFI hooked
up using ctypes and then you eventually convert it to be a full "custom"
module.

This MR is a wash on code size.

The ctypes module is likely slower, but that is almost certainly
meaningless, since this is not performance sensitive code. Is one easier
to maintain than the other? (I don't know.)
----

> The FFI stub would allow for simplified development of non-Python
> libraries.

That would be an advantage. Do we realistically expect any consumers
other than the in-tree tools, thought?

This eliminates the compiled "ntp" module, right? That significantly
improves the Python shebang situation. To repeat that here, simplified:
With a compiled Python module, the scripts MUST run under the same
Python X.Y that the module was compiled against, because compiled-module
ABI compatibility is only guaranteed within a minor version, not across
minor or major versions; see PEP 3149. But if the "ntp" module itself is
only Python, then that relaxes the constraint to Python source
compatibility.

Can you re-open !1010 or open a new MR with this?

I've updated !1166 (Subst installed Python shebangs) to assume this FFI
change is merged before or will be merged soon after.

-- 
Richard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20200907/f4bcf678/attachment.bin>