Wednesday, March 02, 2022

Re: [new] net/py-libknot - python bindings for knot DNS

On 2/27/2022 8:55 AM, Jeremie Courreges-Anglas wrote:
> On Sat, Feb 26 2022, Stuart Henderson <stu@spacehopper.org> wrote:
>> On 2022/02/26 17:15, Kurt Mosiejczuk wrote:
>>> On Sat, Feb 26, 2022 at 11:55:46AM -0500, aisha wrote:
>>>> Hi,
>>>> I've attached a port for py-libknot which allows
>>>> a much better control for knot through scripting rather
>>>> than parsing the knotc(8) output. Plus this is
>>>> maintained by the knot team and in the same repository
>>>> as knot so it should be (and imo is) pretty stable.
>>>> Port made with `portgen py libknot`.
>>> Since it is a library, it shouldn't use MODPY_DEFAULT_VERSION_3 (which is
>>> now the default anyway) it should use FLAVORS=python3 and FLAVOR=python3.
>>>
>>> With that changed, ok kmos for import
>>>
>>> --Kurt
>>>
>> I do wonder if it might be better to build this in net/knot instead
>> (the files are in the main knot distfile too) and subpackage it.
> The main knot tarball doesn't come with the generated setuptools glue.
> So I'm not sure how to get the same resulting python package as
> a subpackage of net/knot. Certainly doable, but I can only think of
> hacks.

There's a few more problems with that, even the pregenerated setuptools
files need
patching as they don't load the correct shared library by default. The
port I had previously
attached did not load the correct shared library as there was no way to
keep track of
what version is installed by net/knot. The subpackage setup could solve
that more easily.

>> I suspect it may be a fairly tight dependency so they probably will need
>> handling together in updates.
> Implementing tight requirements can be done in a separate port too
> (something like RUN_DEPENDS = net/knot=${MODPY_EGG_VERSION} ?).
> Probably better than a forced LIB_DEPENDS / WANTLIB setup.
>
> I agree with kmos@ regarding MODPY_DEFAULT_VERSION_3
>
>> Pinging jca@ (net/knot maintainer) for any comments ..
> FWIW I would gladly leave maintainership of net/knot to someone else, as
> I don't actually use knot on a daily basis. Or I can help
> co-maintaining this. ;)

I'd be happy to co-maintain it, I use it regularly enough to invest time
in this port.

But I'm not sure how to proceed currently, any pointers on how to make a
subpackage setup?

Aisha

No comments:

Post a Comment