Zeep and other forks

[phillbaker]

Just opening an issue to track forks and alternative projects for python soap consumption.

Suds forks

• suds: originally located at svn.fedorahosted.org, service retired on March 1st, 2017. Mirrored at https://github.com/jortel/suds.
  • https://github.com/cackharot/suds-py3
  • https://github.com/htj/suds-htj
  • https://github.com/unomena/suds
  • https://github.com/heroku/sf-suds/
  • https://github.com/samkuehn/suds
  • https://github.com/felixonmars/suds-ng
  • https://github.com/satiani/suds
  • https://github.com/thurloat/appengine-suds
  • https://github.com/hheimbuerger/suds-gzip
• jurko (https://bitbucket.org/jurko/suds/)
  • https://github.com/andersinno/suds-jurko
  • https://bitbucket.org/philpem/suds
  • https://github.com/Affirm/suds-jurko/
  • https://github.com/seatgeek/suds
  • https://github.com/arnaudsj/suds
  • https://github.com/andersinno/suds-jurko

Zeep

If for some reason migrating to Zeep is prohibitive or otherwise impeded by implementation details, this library may help.

[ovnicraft]

Good detail, so i can review some repos and add and issue per repo to try get provements from others

[drice]

Why was the original jortel/suds abandoned? Jeff's actively contributing on github as of July 8th, 2019. His e-mail address is listed on his profile. Are the changes for the suds-jurko fork not backwards compatible? It looks like there hasn't been a single PR to fix the issues with that repo. If it's truly abandoned, you should be able to become a maintainer through the PEP 541 process.

[phillbaker]

Why was the original jortel/suds abandoned?

@tbsf good question. My understanding is that the original jortel/suds was not actively maintained and/or not compatible with python 3, which led to the suds/jurko fork. There was a brief conversation with him on #6. His fork on github hasn't been updated in several years: https://github.com/jortel/suds

Are the changes for the suds-jurko fork not backwards compatible?

I believe this is true, but I haven't done any deep digging. There are certainly a lot of changes.

If it's truly abandoned, you should be able to become a maintainer through the PEP 541 process.

Interesting, I'll take a look, thanks for pointing it out.

[drice]

I found out using this fork that it loses some suds functionality such as client.last_sent/client.last_received. https://github.com/cackharot/suds-py3 retains this functionality, though there are issues with that branch as well (such as WSDLs not being cached). I think it would be worth working from suds forward to make sure functionality isn't lost. If @jortel is open to PRs or new maintainers, that seems like a better path forward for consolidation.

[ovnicraft]

Possible @cackharot would contribute here with a PR to reintroduce the functionality.

So @tbsf can you guide me to found this on repo https://github.com/cackharot/suds-py3 ?

[phillbaker]

Specifically on last_sent / last_received, it looks like Jurko removed them in this commit: 8eaf105

They served no visible purpose, were not mentioned in the documentation or
anywhere in code and were only complicating the reply processing code we are
trying to refactor. If needed, can be easily readded later on, together with
proper testing.

The purpose was likely for debugging - it may be possible to simply revert that commit (and add tests).

[drice]

The last_sent and last_received functions have been incredibly useful to me for seeing what the client has sent or received, especially for WSDLs that need/use plugins or an ImportDoctor. It would be great if this version could support them and remain backwards compatible with suds.

[hansfn]

Following forks of forks of forks has become a full time job ;-) Thanks for the summary / overview.

Some comments:

• Maybe rewrite "original svn (http://svn.fedorahosted.org/svn/suds)" to "Original located at svn.fedorahosted.org - service retired on March 1st, 2017" so people don't have to click the link to read that it is retired. It will not return.
• For Zeep you write: "If for some reason migrating to Zeep is prohibitive or otherwise impeded by implementation details, this library may help." I read this as a recommendation to use Zeep, but if not possible, use Suds (this library). If so, I think you should moved the Zeep the section to the top. If not, make it clearer what you try to say.

[graingert]

If for some reason migrating to Zeep is prohibitive or otherwise impeded by implementation details, this library may help.

that link 404s for me: see https://web.archive.org/web/20200728185259/https://bitbucket.org/jurko/suds/issues/122/zeep-is-the-new-python-soap-library-go-for

[jaraco]

Ugh. While struggling with getting suds-jurko working without use_2to3, I searched around but only found https://github.com/andersinno/suds-jurko, so I created yet another fork, suds-bis. I didn't realize there was this suds community with all of this activity. I'll probably abandon suds-bis in favor of this effort.

I did a lot of cleanup work in that fork, so I welcome this project to copy any of those techniques or commits.

[graingert]

Ugh. While struggling with getting suds-jurko working without use_2to3, I searched around but only found https://github.com/andersinno/suds-jurko, so I created yet another fork, suds-bis. I didn't realize there was this suds community with all of this activity. I'll probably abandon suds-bis in favor of this effort.

I did a lot of cleanup work in that fork, so I welcome this project to copy any of those techniques or commits.

Do you think it's worth starting a pep 541 take over for suds and suds-jurko?

I kind of want to get all this stuff in one place eg jazzband

[jaraco]

I do think it’s worth it for suds but not suds-jurko. The maintainer of the latter is still reachable, so may be amenable to contributing/consulting on suds.

It sure would be nice for there to be one prominent, actively-maintained version, and preferably one with the namesake matching the package name.

I personally won’t take on this effort, but I support it.

[graingert]

Ah that would be @jurko-gospodnetic ?

[phillbaker]

Please also see #6 (comment) for pinging the author of the original package.

[graingert]

@phillbaker would you be happy to take over the suds and or suds-jurko pypi project names?

[phillbaker]

I'd be willing to do that as an interim step, but in the long term, I agree, it'd be better to move this to either jazzband or get additional collaborators on this repo. (If either of you @graingert or @jaraco are interested, please let me know.)

[graingert]

I'd be willing to do that as an interim step, but in the long term, I agree, it'd be better to move this to either jazzband or get additional collaborators on this repo. (If either of you @graingert or @jaraco are interested, please let me know.)

Moving all three projects suds-community, suds and suds-jurko under one banner on @jazzband sounds great to me

[graingert]

@phillbaker do you want to start the process? https://www.python.org/dev/peps/pep-0541/#how-to-request-a-name-transfer

[phillbaker]

Thanks, I've opened pypi/support#1338 to start.

[graingert]

@phillbaker congratulations on the successful pep 451 pypi/support#1338 (comment)

[phillbaker]

Fantastic! I'll work on getting the suds package updated.

[ovnicraft]

Amazing!

[emezeta]

Greetings to you community
a tiny little of foamy each... suds rocks!