FFI module architecture decision was 'Python support policy'

[James Browning]

On Mon, Sep 7, 2020, at 5:24 PM Richard Laager via devel
<devel at ntpsec.org> wrote:
>
> 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.

I think if thas its advantages.

> 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?

Probably not. I haven't pushed the Ruby wrapper for gpsd either.

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

Yes.

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

I could but I should probably wait until after the pending release.
The code is in the ntpc branch of the main repository. pushing it
there revealed a now fixed segfault when using a clang built library.