[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] python: Add Python bindings for libgsasl
From: |
David Michael |
Subject: |
Re: [PATCH v2] python: Add Python bindings for libgsasl |
Date: |
Sat, 3 Aug 2019 00:02:48 -0400 |
On Fri, Aug 2, 2019 at 6:56 AM Simon Josefsson <address@hidden> wrote:
> David Michael <address@hidden> writes:
>
> > This change adds a Python module that provides an interface to the
> > main libgsasl functions.
>
> Hi David, and sorry for belated response! Thanks for your work on this!
>
> I think it would be useful to publish, and I'm putting some cycles into
> GNU SASL again. However I would like help to maintain your
> contribution, are you still around for maintaining this work if I were
> to include it in the distrbution?
I'm still around, but I don't know how useful I would be as a
maintainer. It's been a few years now since I've worked where SASL is
used, so I would have to relearn everything any time issues arise.
> Perhaps something has changed with Python and how modules are usually
> distributed these days? Does it make more sense to distribute your work
> through pypi, or something else? Any other Python people on the list
> who knows what the best approach is these days? Perhaps it is best to
> put this in a separate git repository and make independent releases of
> it, rather than to include it in the core gsasl package. I used to
> include everything in one git repo and one tarball, but that tend to
> create more work in preparing releases and there is some advantage in
> having small easily releasable separate projects.
Regular Python users that don't compile libraries would probably
prefer to have it available through PyPI. The original patch was
integrated into autotools in the core project so that releasing and
testing happened along with the usual process, but since it was
revised to split away from autotools, it could just be moved to its
own repository easily enough. This requires more maintenance effort
either in keeping the module in sync with released library API
versions or in developing version compatibility handling for API
changes, which I don't think I'll be able to do reliably since I no
longer use the functionality. Ownership of the code was transferred
to the FSF, though, so anyone interested should be able to take this
work.
Thanks.
David