Re: New Python bindings (was: Crash with Python bindings)

[Brian May]

David Bremner  writes:

> That's not an itch I personally have, but as I said in the next
> paragraph, if someone want's to take on the project of maintaining a
> wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS
> package maintainers.  We're happy to look at (reasonable) things we can
> do to make downstream projects life easier.

Fair enough. No problem.

I am going to assume that the notmuch library is reasonable stable, and
backward incompatable changes are kept to a minimum with proper updating
of the shared library SONAME. If this is not the case, ignore the rest
of this email.

Ideally the python bindings should be in a git repository that is
separate from the C library. This means you don't have to release new
python bindings for every new source code release of notmuch. You only
need to make a new release if supporting new features or a new release
that breaks backword compatability. It also will make it easier to build
the python libraries standalone using the installed versions of the C
library, which I suspect might make pypi support a lot easier.

I might be able to get time to look at this sometime myself, if nobody
beats me to it.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[David Bremner]

Brian May  writes:

> David Bremner  writes:
>
>> We tried this before, and it didn't work out very well. Bindings tend to
>> depend on a strict matching of versions with the underlying library, so
>> distributing them seperately doesn't really make sense to me. You need
>> the underlying libraries, so why not get the matching bindings from the
>> same place?  We found that the situation was exacerbated by the fact
>> that no-one cared about updating the bindings on pypi.
>
[...]
> Unfortunately, I think many people will not even consider using a python
> library unless it has up-to-date bindings available on pypi.

That's not an itch I personally have, but as I said in the next
paragraph, if someone want's to take on the project of maintaining a
wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS
package maintainers.  We're happy to look at (reasonable) things we can
do to make downstream projects life easier.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[Brian May]

David Bremner  writes:

> We tried this before, and it didn't work out very well. Bindings tend to
> depend on a strict matching of versions with the underlying library, so
> distributing them seperately doesn't really make sense to me. You need
> the underlying libraries, so why not get the matching bindings from the
> same place?  We found that the situation was exacerbated by the fact
> that no-one cared about updating the bindings on pypi.

I believe that is the purpose of Python Wheels.

https://pythonwheels.com/

pypi is the defecto standard for distributing Python code for use in
Python applications. It means packages that use notmuch just need to
list it as a dependancy in 'requirements.txt' and a 'pip install -r
requirements.txt' will install everything required (if inside a
virtualenv no root access required even).

There are also various solutions to get automatic deploys to pypi, for
example through travis:

https://docs.travis-ci.com/user/deployment/pypi/

Unfortunately, I think many people will not even consider using a python
library unless it has up-to-date bindings available on pypi.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[Floris Bruynooghe]

On Wed, Mar 28 2018, David Bremner wrote:

> Brian May  writes:
>
>> I can into this thread late. However, my priorities for python bindings
>> would be:
>
> [...]
>> * Packages should be available from pypi.python.org
>>
>
> We tried this before, and it didn't work out very well. Bindings tend to
> depend on a strict matching of versions with the underlying library, so
> distributing them seperately doesn't really make sense to me. You need
> the underlying libraries, so why not get the matching bindings from the
> same place?  We found that the situation was exacerbated by the fact
> that no-one cared about updating the bindings on pypi.

I did build a

#if LIBNOTMUCH_MAJOR_VERSION < 5
#error libnotmuch version not supported by notdb
#endif

into my current bindings which kind of allows you to do this to some,
hopefully reasonable, level.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[Floris Bruynooghe]

On Wed, Mar 28 2018, Brian May wrote:

> Justus Winter  writes:
>
>>> This is exactly what I have fixed in my alternative bindings which I
>>> created around the end of last year [0].  So we do have an idea of how
>>> to fix this, at the time I said I do believe that it's possible to also
>>> do this for the existing bindings even though it is a lot of work.
>>> After some talking between dkg and me we got to a way forward which
>>> proposed this, but I must admit that after messing a little with getting
>>> a pytest run integrated into the notmuch test-suite instead of using tox
>>> I lost momentum on the project and didn't advance any further.
>>
>> I'm sorry that I didn't speak up when you announced your work.  I'm
>> actually excited about a new set of bindings for Python.  I agree with
>> using cffi.  I briefly looked at the code, and I believe it is much
>> nicer than what we currently have.
>
> I can into this thread late. However, my priorities for python bindings
> would be:
>
> * I don't care about anything less then Python 3.5.
> * Reliable Python 3.6 support important.
> * Packages should be available from pypi.python.org

Well, the 1st two should already be covered on my
https://github.com/flub/notmuch/tree/cffi branch.  There's obviously
still room for improvement.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[David Bremner]

Brian May  writes:

> I can into this thread late. However, my priorities for python bindings
> would be:

[...]
> * Packages should be available from pypi.python.org
>

We tried this before, and it didn't work out very well. Bindings tend to
depend on a strict matching of versions with the underlying library, so
distributing them seperately doesn't really make sense to me. You need
the underlying libraries, so why not get the matching bindings from the
same place?  We found that the situation was exacerbated by the fact
that no-one cared about updating the bindings on pypi.

Projects like numpy seem to get around this by distributing compiled
shared libraries on pypi. That's fine if someone wants to do it, but it
looks like "just another distro" to me, and not really an upstream
problem.  I guess we'd entertain minor tweaks to the build system to
support that, but probably not a wholesale conversion.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[Brian May]

Justus Winter  writes:

>> This is exactly what I have fixed in my alternative bindings which I
>> created around the end of last year [0].  So we do have an idea of how
>> to fix this, at the time I said I do believe that it's possible to also
>> do this for the existing bindings even though it is a lot of work.
>> After some talking between dkg and me we got to a way forward which
>> proposed this, but I must admit that after messing a little with getting
>> a pytest run integrated into the notmuch test-suite instead of using tox
>> I lost momentum on the project and didn't advance any further.
>
> I'm sorry that I didn't speak up when you announced your work.  I'm
> actually excited about a new set of bindings for Python.  I agree with
> using cffi.  I briefly looked at the code, and I believe it is much
> nicer than what we currently have.

I can into this thread late. However, my priorities for python bindings
would be:

* I don't care about anything less then Python 3.5.
* Reliable Python 3.6 support important.
* Packages should be available from pypi.python.org

I have found the current official bindings unreliable with Python 3.x,
and tend to cause aborts on exiting and/or fail to save updates. As
such, for now I have downgraded to Python 2.7 for now.
-- 
Brian May 
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: New Python bindings (was: Crash with Python bindings)

[Floris Bruynooghe]

On Wed, Mar 21 2018, Justus Winter wrote:
>
> Floris Bruynooghe  writes:
>
>> This is exactly what I have fixed in my alternative bindings which I
>> created around the end of last year [0].  So we do have an idea of how
>> to fix this, at the time I said I do believe that it's possible to also
>> do this for the existing bindings even though it is a lot of work.
>> After some talking between dkg and me we got to a way forward which
>> proposed this, but I must admit that after messing a little with getting
>> a pytest run integrated into the notmuch test-suite instead of using tox
>> I lost momentum on the project and didn't advance any further.
>
> I'm sorry that I didn't speak up when you announced your work.  I'm
> actually excited about a new set of bindings for Python.  I agree with
> using cffi.  I briefly looked at the code, and I believe it is much
> nicer than what we currently have.

Nice to hear, thanks!

> I trust that it works fine with Python 3, does it?

The version I made so far *only* works on Python 3.  Mostly because it
was easier, but it also allows some API niceties.

> The testsuite cannot depend on pulling stuff from the net simply because
> build servers typically do not have access to it.  That is a hard
> requirement.

Sure I understand that.  See another part of this thread on this though.


Cheers,
Floris
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

New Python bindings (was: Crash with Python bindings)

[Justus Winter]

Hi Floris :)

Floris Bruynooghe  writes:

> This is exactly what I have fixed in my alternative bindings which I
> created around the end of last year [0].  So we do have an idea of how
> to fix this, at the time I said I do believe that it's possible to also
> do this for the existing bindings even though it is a lot of work.
> After some talking between dkg and me we got to a way forward which
> proposed this, but I must admit that after messing a little with getting
> a pytest run integrated into the notmuch test-suite instead of using tox
> I lost momentum on the project and didn't advance any further.

I'm sorry that I didn't speak up when you announced your work.  I'm
actually excited about a new set of bindings for Python.  I agree with
using cffi.  I briefly looked at the code, and I believe it is much
nicer than what we currently have.

I trust that it works fine with Python 3, does it?

The testsuite cannot depend on pulling stuff from the net simply because
build servers typically do not have access to it.  That is a hard
requirement.

I don't remember what kind of tests there are for the current bindings
(are there any...?), but shouldn't these just continue to work for the
time being?


Thanks,
Justus


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch