[tryton-debian] Preparing for packaging suds-jurko for Debian

Mathias Behrle mathiasb at m9s.biz
Tue Jul 1 10:26:47 UTC 2014


* Jurko Gospodnetić: " Re: Preparing for packaging suds-jurko for Debian" (Mon,
  30 Jun 2014 21:44:43 +0200):

Hi Jurko,

thanks a lot for your answer.

I will now discuss, how to handle the package in Debian wrt. to the original
suds package. I will keep you updated, if we should need something.

For the docs: your work on this of course is very much appreciated, but this is
not a show stopper to get the package into Debian. We can make a doc package,
if adequate, any time later.

Cheers,
Mathias

> On 30.6.2014. 20:25, Mathias Behrle wrote:
> > I am very pleased, that you picked up suds and to see the efforts you are
> > making in improving the package. Kudos!
> 
>    Thanks. I'm glad people find it useful. :-)
> 
> 
> > 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.
> 
> 
> > 2) Since in version 0.6 the test directory still goes to dist-packages,
> > which is solved in VCS, I will use 0.7 to enter in Debian. When will the
> > release of 0.7 be scheduled?
> 
>    No real plan here since I'm working on it in my free time at the 
> moment. If you need it, I can package it any time. I try to keep the 
> project's release notes up to date.
> 
> 
>    What I still see as a bottle-neck for making my fork a full suds 
> successor is taking control over suds docs. That is one topic that I 
> constantly have my eye on but never seem to get enough time to tackle. 
> If you really want to integrate it into something as used as Debian - I 
> guess I need to get on that sooner than expected.
> 
> 
> > Thanks a lot for your work,
> 
>    You're welcome. :-)
> 
>    Best regards,
>      Jurko Gospodnetić
> 



-- 

    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/30bd8dee/attachment.sig>


More information about the tryton-debian mailing list