[tryton-debian] Packaging of suds-jurko (was: suds)
Mathias Behrle
mathiasb at m9s.biz
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>
More information about the tryton-debian
mailing list