Python Bindings missing on PyPI

Python Bindings missing on PyPI

[Patrick Gerken]

Hi,

I noticed that the python bindings of notmuch are not available via pypi.
It seems that in the past something was registered but is not any longer.

Without the bindings, it is not possible to use python packages that
depend on notmuch within virtualenv. Virtualenv is a widely used app
to run python programs in an isolated environment.

Is there any rationale that prevents registering the python bindings
on pypi?
If this is only because of missing maintainer, would anybody
object if I put the bindings on pypi?
If nobody objects, I as the creator, would have admin permissions to
the pypi entry. I don't hoard these rights, if anybody else wants
access, please tell me your pypi username. Bus factors of 1 are
terrible.

Thanks and best regards,

        Patrick

Re: Python Bindings missing on PyPI

[David Bremner]

Patrick Gerken <notmuch@patrick-gerken.de> writes:
>
> Is there any rationale that prevents registering the python bindings
> on pypi?
> If this is only because of missing maintainer, would anybody
> object if I put the bindings on pypi?

I imagine the python bindings are pretty dependent on the version of
notmuch they ship with; I'm not sure how well shipping them
independently will work out.

That said, whatever you and Justus (who maintains the python bindings in
notmuch) agree on is probably fine with the rest of us.

d

Re: Python Bindings missing on PyPI

[Justus Winter]

Hi :)

Quoting David Bremner (2013-05-20 16:32:32)
> Patrick Gerken <notmuch@patrick-gerken.de> writes:
> > Is there any rationale that prevents registering the python bindings
> > on pypi?

I believe the python bindings were once available on pypi, though that
might have been a relict from the time the python bindings were not
distributed with notmuch (I'm just guessing here, I haven't been
around long enough). Iirc it was Sebastian who registered it. When I
took over the python bindings I simply did not care enough to take
care of the pypi entry (see below).

> > If this is only because of missing maintainer, would anybody
> > object if I put the bindings on pypi?
> 
> I imagine the python bindings are pretty dependent on the version of
> notmuch they ship with; I'm not sure how well shipping them
> independently will work out.
> 
> That said, whatever you and Justus (who maintains the python bindings in
> notmuch) agree on is probably fine with the rest of us.

I would not object to that, but David has a point here. If the version
you get from pypi is newer than your libnotmuch, you will get errors
*at runtime*.

Also I just looked at http://oswatershed.org/pkg/notmuch and
http://oswatershed.org/pkg/python-notmuch . It looks like every
distribution that is shipping libnotmuch packages also ships the
python bindings. So everyone who got libnotmuch from their
distribution can also obtain the appropriate bindings. And everyone
who compiled notmuch also has the bindings. I'm just not sure what's
to gain here.

Cheers,
Justus

Re: Python Bindings missing on PyPI

[Justus Winter]

Quoting Patrick Gerken (2013-05-22 12:08:30)
> Quoting Justus Winter (2013-05-21 14:54:02)
> > Hi :)
> > 
> > Quoting David Bremner (2013-05-20 16:32:32)
> > > Patrick Gerken <notmuch@patrick-gerken.de> writes:
> > I would not object to that, but David has a point here. If the version
> > you get from pypi is newer than your libnotmuch, you will get errors
> > *at runtime*.
> 
> That is a point I did not consider much, I admit.
> 
> > Also I just looked at http://oswatershed.org/pkg/notmuch and
> > http://oswatershed.org/pkg/python-notmuch . It looks like every
> > distribution that is shipping libnotmuch packages also ships the
> > python bindings. So everyone who got libnotmuch from their
> > distribution can also obtain the appropriate bindings. And everyone
> > who compiled notmuch also has the bindings. I'm just not sure what's
> > to gain here.
> 
> That is only partially true and this is entirely a python problem.
> 
> As a Python Developer I am forced to work in virtualenv, that isolate
> the python running in there from system installed python packages.
> That is necessary, because I cannot install two different versions
> of the same package in python. Something that is essential when
> working on multiple projects.
> 
> I tend to believe that virtualenv is a tool for developers and hosters,
> but not for end users. I'd claim that it is their responsibility
> to ensure the right version of libnotmuch.
> Actually, I i were to deploy a python project with notmuch, I'd certainly
> ensure that my deployment builds libnotmuch from source, something that
> is not uncommon in the Plone world, which sets up projects with zc.buildout.
> 
> I'd love to hack on alot and afew, but I cannot install them safely on my
> machines right now, they run in a little virtual machine just because of it :-(

Wouldn't it be better to install libnotmuch and the wrapper to this
virtualenv so you make sure they match? I haven't used virtualenv, but
searching the web turned up
http://codersbuffet.blogspot.de/2009/09/wxpython-in-virtualenv.html
. He uses a post activate hook to set the LD_LIBRARY_PATH
variable. Maybe there's an even better way to do that now, seeing that
his post is from 2009.

> Based on my claim that pypi installations aren't usually done by end users,
> does that reduce your reservations sufficiently to put the bindings on pypi?

I don't have any reservations about anyone creating and maintaining an
entry on pypi for notmuch. So if having an pypi entry helps you and
potentially others as well, go ahead :)

I'm concerned about potential API issues that won't crop up until
someone runs some code. And someone would have to update and test the
pypi entry, and that someone would have to be someone other than me
since I've never used virtualenv or any method of deploying python
software like pip or easy_install. I tend to install dependencies
manually instead, and most of the time I don't have to do anything
since most python software I use is usually packaged in Debian.

Cheers,
Justus