Python binding for OpenSRF and Evergreen

[Jason Stephenson]

This bug report is to see what OpenSRF/Evergreen community members want to do about the Python libraries in OpenSRF and Evergreen. They are not up to date with the latest OpenSRF features (i.e. chunking and bundling) though they are not as far behind as the Java libraries. There is some chance of salvaging them if someone is willing to make the effort.

Here is an enumeration of the problems with our Python libraries, as I understand them:

1. The OpenSRF and Evergreen Python libraries are compatible only with Python 2.7.

2. Python 2.7 is end of life as of January 1, 2020:
https://legacy.python.org/dev/peps/pep-0373/
https://mail.python.org/pipermail/python-dev/2018-March/152348.html

3. srfsh.py works on Ubuntu 18.04 and Debian 9, but not on Ubutnu 16.04 nor Debian 8. This is because of a bug in a Python XMPP library on Ubuntu 16.04 and Debian 8.

4. Syrup is the only recognized consumer of the Python libraries. Syrup is abandonware. The last commit was made in 2014.

5. Syrup cannot be installed on any currently supported release of Debian or Ubuntu without major changes. The last releases upon which it can be installed as-is appear to be Debian 7 and Ubuntu 12.04. Both are long out of support from their respective communities.

If anyone wants to maintain Syrup and/or the OpenSRF and Evergreen Python bindings, please step forward.

[Galen Charlton (gmc)]

Noting per today's dev meeting that Dan Wells is evaluating whether to assume maintainership of the Python binding and Syrup.

[Dan Wells (dbw2)]

Quick update, just to keep this bug alive. We have a branch of Syrup functional on Python 3. It is currently entangled with all of our local customizations, and I can't provide at this point a solid ETA on getting that untangled, but mid-May would be a reasonable guess. (Many of those customizations probably deserve consideration for inclusion in mainline Syrup as well.) It should be noted that Syrup does not actually run Python OSRF services, so this does not mean that the full OpenSRF Python libraries (I don't like to call them bindings) are ready for Python 3. In fact, I do not recall OTTOMH whether getting Syrup to work required any changes to the Evergreen Python code at all. It certainly was not the majority of it.

It will probably make sense to split off the Syrup pieces to a new bug (if there isn't already one). I'll do that when the branch is ready to post. We might end up with a middle ground of saying we support Python as a consumer of OSRF messages, but not a producer.

[Bill Erickson (berick)]

My proposal for moving the Python bits to a separate repo:

http://list.evergreen-ils.org/pipermail/evergreen-dev/2020-October/000049.html

[Bill Erickson (berick)]

Extraction branches in progress:

https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/berick/lp1827055-extract-python

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1827055-extract-python

[Jason Stephenson (jstephenson)]

Bill, the branches work for me, I have rebased the branches to remove Java and the Ubuntu 20.04 support branches on top of these so that they should apply smoothly.

https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/dyrcona/lp1827055-extract-python-signoff

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1827055-extract-python-signoff

[Chris Sharp (chrissharp123)]

I have pushed this to Evergreen and OpenSRF master. Thanks, Bill and Jason!

[Jeff Godin (jgodin)]

Noting that this bug (and its sibling bug 1827051 for removing Java support) has not yet made it into an OpenSRF release. Added target for OpenSRF 3.3-beta, though including it in the next 3.2 release might make sense also.

[Jason Stephenson (jstephenson)]

I have targeted this bug at OpenSRF release 3.2.3 also, followiing up on Jeff's previous comment as well as a couple of instances of people trying to install OpenSRF on Ubuntu 20.04 and Debian 11 and it failing:

http://irc.evergreen-ils.org/evergreen/2022-05-26#i_507382

I have provided a backport branch at user/dyrcona/lp1827055-backport_rel_3_2

https://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/user/dyrcona/lp1827055-backport_rel_3_2

[Jason Stephenson (jstephenson)]

I have tested the 3.2 back port branch on an Ubuntu 20.04 virtual machine. All tests pass and OpenSRF works. Since it is Friday before a Monday holiday, I'll leave this until Tuesday before deciding to push it myself or not. If anyone else wants to push it beforehand, be my guest.

I think I'll test this on Debian 11, too, though it should work there as well, since master has the same patch and still works.

[Jason Stephenson (jstephenson)]

Just another FYI: I tested the 3.2 branch on a fresh install on Debian 11. Everything still works, so I will push this on Tuesday unless someone objects.

[Jason Stephenson (jstephenson)]

I have pushed the changes to OpenSRF rel_3_2.

[Jason Stephenson (jstephenson)]

See also bug 1951850. We should prioritize a 3.2.3 release of OpenSRF to repair that bug.