On 2022/03/02 22:22, aisha wrote:
>
> On 2/27/2022 8:55 AM, Jeremie Courreges-Anglas wrote:
> > 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.
OK, then in that case a separate port probably does make more sense.
net/knot should get a comment reminding to keep py-libknot in sync.
> 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.
Patch away the version number and just use "libknot.so".
> > > 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
Agreed on both these.
> > > 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
>
