Hi
On 12.6.2013. 16:17, Gauthier Bastien wrote:
But what I would like to know is, what is the real current state of
the
project?
I think the story how suds-jurko got started is quite typical. We
originally started using suds as a part of an internal project we were
working on at my day job. It did not quite do what we wanted it to do
(did not work with Python 3, some operations did not seem to work, etc.)
and we could not find a better external solution so I forked the
existing suds repository locally, tweaked it to work as we expected and
then used the patched version instead.
When the project was done, I was hoping to get the changes backported
to the original suds project (I hate to have work go to waste), which
seemed 'temporarily' stalled, so we decided to make a public fork of our
work. I cleaned up the project a bit (added additional description to
the project's readme file, packaged a formal release, etc.) to make it
more likely someone would notice it and collect the changes and backport
them into the original project and published it on BitBucket.
A few months later we encountered some more web service related work
that we found we could use suds for, plus I still had a personal itch to
get the changes backported into the original project. So, we did some
more work on it, and I started working on what I saw as the biggest
hurdle preventing further changes to suds - missing test suite.
Occasionally someone contacts me and asks about joining different
project forks but there are lots of suds project forks lying around and
lots of suggested patches for different problems. Most I encountered are
just quick-fixes to specific problems which, while possibly fixing the
exact problem at hand, often do not fit nicely in the overall suds code
structure or break other suds functionality. So with time I was less and
less happy to with simply applying found external quick-fixes and
messing up the code-base that some of our internal products were now
relying on. And without a good enough test suite there is just no way to
sleep soundly after merging such external changes without at least
having encountered the exact problem they solve and understanding in
depth what the patch does.
So, to answer the original question, suds-jurko is 'just another
fork', and we hope it gets traction and 'survives'. At the moment, it's
a personal itch, and I like working on it from time to time, but
honestly, there really is no guarantee that we will not get side-tracked
and not work on it for a while (or ever). It has happened before. :-)
The fork's name has been chosen to make it clear from the start that
the fork was intended to be a temporary placeholder for stuff to be
backported into the original project. I guess it'll have to be changed
at some point if the fork survives, and we give up on backporting the
changes in it.
If anyone is interested, I'll gladly integrate other people's changes
to the fork, but I'd like to see all the changes tested. The current
test suite added to the fork is pytest based and runs its tests locally,
without requiring an external web service, which I believe is a good
thing. :-)
Underlying support for this was already in suds, and just needed to
be tweaked a bit to get it working as we expected it to. Currently there
are tests that do things like:
- create a client from a fixed hardcoded WSDL schema
- create a client from a set of fixed hardcoded WSDL schemas mutually
importing each other
- prepare requests in different scenarios without sending them to an
actual external web service implementation
- process fake injected server responses instead of having them be
returned by an actual external web service implementation
That existing test code base can be used (and is currently :-)) by
users to report problems they encounter without having to allow other
people access to their local development environment, proprietary web
services and such. And, such reproducible test cases can then more
easily be simplified and integrated into the suds-jurko test suite to
guard against regressions.
Much of the existing original suds functionality is still not tested,
and so I am still quite conservative about publishing our changes as
'formal releases' - that's where external project test suites come in
handy. :-) I like hearing that someone started using the fork and all of
their 1274 test cases now pass. :-)
Also the fork currently does not include the original project's
documentation and as work on the fork progresses, that's one thing I
think should be integrated as well. There have been, and as time goes
by, there will be new options & features added to the fork that really
need to be documented somewhere. But we'll see how that goes...
I know of many issues in suds that I'd like to work on or see worked
on eventually, but not many open issues reported by actual fork users.
Most of those get solved rather promptly at the moment.
Most people I know of that are using the fork contacted me directly
over BitBucket, e-mail or Skype, most often with some precise problem
they were having or asking about the fork after finding out that it
already solves their problem. I try to help out as much as I can. But
hey, in the end, it's an open source free-time project, so it sometimes
needs to wait for the weekend or the next (heh, nope, that one's taken,
getting married that Saturday :-D).
But anyone interested in helping out is always welcome. :-)
Hope this clears up at least some of the questions I got about the
fork...
Best regards,
Jurko Gospodnetić