* Jordan Metzmeier: " Re: suds (was: favouring Python3 in the Debian policy)" (Thu, 8 May 2014 10:22:47 -0500):
Hi all, > On Thu, May 8, 2014 at 4:11 AM, Mathias Behrle <mathi...@m9s.biz> wrote: > > * Jordan Metzmeier: " Re: favouring Python3 in the Debian policy" (Wed, 7 > > May 2014 21:55:20 -0500): > > > > Hello Jordan, > > > >> The jurko fork was the one I was working with when attempting the port > >> to suds. I never made it to testing under python3. > > > > [...] > > > >> I consider debbugs to be broken, not suds. > > > > Thanks for your detailed explanations. > > > > Could you share, if you have any experiences with orginal suds compared to > > suds-furko (or any of the other forks mentionned by Barry)? > > > > I don't expect http://svn.fedorahosted.org/svn/suds/trunk to be revived [1] > > and of course it would be preferable to have an actively maintained version > > of suds in Debian. suds-furko seems to be the most appropriate candidate > > [2]. If no one raises his hands or objects, I will try to do some tests and > > file the ITP. > > > > My experience was no different than working with the original suds > library. It might be better to replace our existing suds library with > a fork rather than introduce the fork as a new package. The first tests on suds-jurko are looking very promising. I built the package succesfully as a drop-in replacement for the current python-suds package. It builds correctly for python2 and python3 with all tests. I tested part of the functionality for python2, all was working well. The maintainer of suds-jurko is very active and responsive. Now I would like to package suds-jurko as a replacemnt for suds and I want to ask, what is considered the best way (please indicate, if I should rather go to d-mentors, I am trying first here, because it is python and the thread started here.) According to the maintainer suds-jurko is almost fully API-compatible with original suds, where almost means the removal of two apparently obviusly unused methods (for the full message see below [1]). In case this should be a substantial obstacle, the maintainer offers to re-include those methods. So the first question, I couldn't solve from the docs I found: 1) Can I drop in the suds-jurko fork into the current suds package as proposed by Jordan? The license is unchanged, API compatibility seems to be guaranted. $ apt-cache rdepends python-suds python-suds Reverse Depends: python-ironic python-cinder vistrails python-vatnumber python-stdnum python-oslo.vmware python-psphere python-profitbricks-client python-trove python-nova python-nova python-ironic gtg congruity python-cinder 2) If not 1) what would be the best alternative? In this case I would plan - a new python-suds-jurko package, conflicting with python-suds - filing bugs to rdepends to use the new package - removing the old package as soon as possible Thanks for your input, Mathias [1] * Jurko Gospodnetić: " Re: Preparing for packaging suds-jurko for Debian" (Mon, 30 Jun 2014 21:44:43 +0200): > > After doing some successful tests, I want to replace the current suds > > package in Debian with your fork. > > > > To be well prepared I have two questions: > > > > 1) Is the current code base of suds-jurko completely API compatible with the > > code base from redhat? Can suds-jurko still be a drop-in replacement for > > suds? > > I really tried to keep it that way. :-) > > I know currently of only one place where this compatibility got > broken 'accidentally' - the suds.client.Client last_sent() and > last_received() methods have been removed (see issue #39 on BitBucket - > https://bitbucket.org/jurko/suds/issue/39). > > They were never really cleanly implemented and the data they received > could have been processed by some but not all registered plugins. > Currently a relatively easy workaround is to register a custom plugin (a > few lines of code) which will get all the same data at a precisely > determined level of abstraction (e.g. raw XML bytes or XML document > model constructed after suds parses the raw XML bytes, and such). > > In retrospect, perhaps they should not have been removed so abruptly, > but at the time I found no mention of them anywhere in the source code, > there were no tests related to them, no one on any of the mailing lists > I contacted reported using them and they were getting in the way of some > planned code cleanup. > > Anyway, I'm hoping to reimplement them back soon, but if you really > need them 'at once', I guess their original implementation could be > easily restored from the single commit that removed them. One reason why > I'm still delaying with restoring them is that I'd like to find the time > to prepare some tests for them first. > > > There are other places where the public API got extended, e.g. extra > options or the suds.store.DocumentStore class which can now be used to > easily supply suds with locally stored resources so it does not need to > fetch them over the network. > > And there are, of course, bug that have been fixed which means the > behaviour may differ in certain places, e.g. several bugs have been > fixed that were causing the original suds project to generate SOAP > requests with XML tags qualified with an incorrect namespace. > > > All in all, except for the last_sent() & last_received() methods - I > know of no other breakage. -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
