Mathieu, what is the __str__() of the client object you've created? You
should be able to see a list of services, ports, methods, and types
and Gauthier, I think that question deserves its own thread
On Wed, Jun 12, 2013 at 9:17 AM, Gauthier Bastien <gauthier(a)imio.be> wrote:
Hi,
we use suds 0.4 in several projects and we could update our package to use
your fork.
But what I would like to know is, what is the real current state of the
project? I understand that forking to bitbucket/github and so on is easy,
but is there a plan to make it useable by everybody and what is the current
official repository?
The current svn seems dead, is it possible to specify on the suds home
page that the code to use is on another repos? We could even configure
TRAC to display another official repository on bitbucket or any other
source repo...
I think it would be great because looking at the current state, and last
changes (nothing done for years) make people believe the project is dead,
and maybe it is not the case...
Thank you and have a nice day,
Gauthier Bastien <
http://www.imio.be>
Zoning industriel, 34
5190 Mornimont
Tél: 0032(71)78 09 79
Fax: 0032(65)32 96 79
gauthier.bastien(a)imio.be
La mutualisation informatique
au service des pouvoirs locaux
Le 12/06/13 14:29, Jurko Gospodnetić a écrit :
Hi.
So far I was using a patched version of suds 0.3.7, patched for
dealing better with EWS SOAP (suds-ews :
https://bitbucket.org/daevaorn/suds-ews/). But I don't want to use
that outdated version anymore.
I grabbed the last version of suds from pip, the one from jurko which
contains most of the patchs proposed since the development have
stalled, and I have got the following error (I have it too even with
the "regular" suds 0.4.0 release):
In general I suggest using suds-jurko from the sources at the moment.
There have been many fixes & cleanups since the last formal release. For
that matter, I would like to package the current state as the next formal
release, just waiting for some people using it to sent me back a
confirmation that everything is working fine for them.
In that versions we've added automated tests checking parts of suds
without having to connect to an external web service, e.g. by using
hardcoded WSDL schemes, injecting fake server responses etc. That code can
now easily be used to reproduce any problematic behaviour without having to
use an externally provided web service. And once you have such a working
locally reproducible test case, you can even change the naming, remove
unnecessary details and such - making both the problem easier to debug and
removing any proprietary information that might have otherwise prevented
you from sending out the code needed to reproduce the problem.
I'm really can't figure out what causes the problem. It should work
fine out of the box.
I hope you people of the suds ML can bring some help.
We have not done anything related to EWS there (nor have we ever used
it) so its doubtful your problem has been fixed out-of-the-box.
And as for that, if you can let me know how to connect to that web
service, or at least get me the WSDL in question I can take a look at
what's breaking and what workarounds for any of the problems involved have
been made in the patched SOAP version you mentioned. I have not tried out
your code, assuming I'd need some sort of a username & password to make it
work.
Best regards,
Jurko Gospodnetić
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds