[tryton-debian] Packaging of suds-jurko (was: suds)

Tue Jul 1 11:10:09 UTC 2014

* 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 <mathiasb at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/tryton-debian/attachments/20140701/b9445eb6/attachment-0001.sig>