On Sat, Feb 26 2022, Stuart Henderson <s...@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.
> 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. ;)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
