Python binding for OpenSRF and Evergreen

Bug #1827055 reported by Jason Stephenson
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Medium
Unassigned
OpenSRF
Fix Committed
Medium
Unassigned
3.2
Fix Released
Medium
Unassigned

Bug Description

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.

Revision history for this message
Galen Charlton (gmc) wrote :

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

Revision history for this message
Dan Wells (dbw2) wrote :

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.

Revision history for this message
Bill Erickson (berick) wrote :

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

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

Revision history for this message
Bill Erickson (berick) wrote :
Changed in evergreen:
assignee: nobody → Jason Stephenson (jstephenson)
Changed in opensrf:
assignee: nobody → Jason Stephenson (jstephenson)
Changed in evergreen:
milestone: none → 3.next
status: New → Confirmed
status: Confirmed → New
Revision history for this message
Jason Stephenson (jstephenson) wrote :

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

Changed in evergreen:
assignee: Jason Stephenson (jstephenson) → nobody
Changed in opensrf:
assignee: Jason Stephenson (jstephenson) → nobody
tags: added: pullrequest signedoff
Changed in evergreen:
status: New → Confirmed
Changed in opensrf:
status: New → Confirmed
Changed in evergreen:
importance: Undecided → Medium
Changed in opensrf:
importance: Undecided → Medium
Changed in evergreen:
milestone: 3.next → 3.7-beta
Changed in evergreen:
assignee: nobody → Chris Sharp (chrissharp123)
Changed in opensrf:
assignee: nobody → Chris Sharp (chrissharp123)
Revision history for this message
Chris Sharp (chrissharp123) wrote :

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

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in opensrf:
status: Confirmed → Fix Committed
Changed in evergreen:
assignee: Chris Sharp (chrissharp123) → nobody
Changed in opensrf:
assignee: Chris Sharp (chrissharp123) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
Revision history for this message
Jeff Godin (jgodin) wrote :

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.

Changed in opensrf:
milestone: none → 3.3-beta
Revision history for this message
Jason Stephenson (jstephenson) wrote :

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

Revision history for this message
Jason Stephenson (jstephenson) wrote :

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.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

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.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

I have pushed the changes to OpenSRF rel_3_2.

Revision history for this message
Jason Stephenson (jstephenson) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.