Consolidate PyPi package naming

[macfreek]

This is admittedly more of administrative request than anything else, please bear with me, while I try to make my point.

It seems that are multiple sources providing Python bindings to RRDtool, with often different naming schemes in the packages for different distributions. I'm familiar with the following sources:

Name	Pip package	Version	Year	Project URL	Repository URL	Author
py-rrdtool		0.2.1	2003	http://www.nongnu.org/py-rrdtool/	_rrdtoolmodule.c	Hye-Shik Chang
py-rrdtool	py-rrdtool	1.0b1	2006	http://py-rrdtool.sourceforge.net/	_rrdtoolmodule.c	Hye-Shik Chang, Mihai Ibanescu
	python-rrdtool	1.4.7	2012	https://github.com/pbanaszkiewicz/python-rrdtool	rrd_tool.c	Piotr Banaszkiewicz
rrdtool (previously: rrdtoolmodule)		1.5.5	2015	http://oss.oetiker.ch/rrdtool/prog/rrdpython.en.html	rrdtoolmodule.c	Hye-Shik Chang, Alan Milligan
rrdtool	rrdtool	0.1.2	2015	https://github.com/commx/python-rrdtool	rrdtoolmodule.c	Hye-Shik Chang, Christian Jurk

So e.g. pip install rrdtool would install Christian Jurk's version, pip install python-rrdtool would install bindings from a different code-base. The Debian package python-rrdtool would install this version: the source package is simply rrdtools. To be honest, I was confused to see that it nevertheless installs a file py_rrdtool-0.2.2.egg-info, whose version seem to refer to the original Hye-Shik Chang codebase.

If I look at the two actively maintained packages (this one and Christian Jurk's version), they're very similar (they both seem forks of Hye-Shik Chang's original implementation). However, there are minor differences. E.g. rrdtool.fetch(file, 'MAX','-r 300', '-s -1y') works on this version, but not the other (rrdtool.fetch(file, 'MAX','-r', '300', '-s', '-1y') works on both). The other version has Python3 support, I'm not sure about this one (there is no python3-rrdtools package on Debian, and I haven't installed it manually yet to test.). Only this one has rrdtool.error(), rrdtool.graph() and rrdtool.xport(). Only the other has rrdtool.lib_version() and rrdtool.lastupdate().

These small differences can lead to unexpected errors in code.

It would be great if a common API could be established, one way or the other.

Perhaps the easiest way forward is to determine you want to maintain a PyPi package yourself, or if you like to ask someone else to maintain that. In the later case, kindly encoureage them to sync the two codebases as closely as possible, for example by pushing changes to the other version (both downstream and upstream).

See also https://github.com/commx/python-rrdtool/issues/1

[oetiker]

the language bindings shipped with rrdtool track changes in rrdtool. I have no idea how this is handled by the other bindings ... also I am open to getting patches from others, so why it is necessary to create additional binding is beyond me ...

[macfreek]

As a user, I can only observe that there is no python3-rrdtools package, and there is no python package (at PyPI) with the bindings in this source.

So I'm grateful to both you, @oeitker, for creating and mainting rrdtools, and also thankful to @commx to creating a package with Python3 support, and maintaining a reasonably up-to-date package on PyPI.

Now I could go out and ask the Debian rrdtool maintainers to create a python3-rrdtools package, and/or create a PyPI package myself, but it seemed reasonable to ask those who already did so much for the community for their opinion first. Thank you for your quick reply. I hope @commx can weigh in as well about what he think is the best way forward.

[oetiker]

The problem that most languages have their own extension repos these days doesn't make it easy for a package like rrdtool coming with multiple language bindings included ...

[commx]

The python-rrdtool binding is basically a fork of the binding shipped with the official rrdtool distribution. I changed a few things in the original code, adding support for newer rrdtool functions and Python 3.x support. These bindings work just fine with Python 2.x and 3.x, but they're incompatible in some parts with the official bindings.

The graph, xport etc. functions are only available when the HAVE_RRD_GRAPH macro is defined in the build environment, as rrdtool can also be used without all these graphics stuff.

In general I'm willing to get the bindings merged into upstream, but I think that having the bindings as separate repositories/packages would be better, as it simplifies the release management (especially for PyPI).

[oetiker]

@commx I'll be glad to take your patches ... especially if they are done in a way that existing code does not get broken ...