Chris Austin and I were discussing the upcoming beta 2.0 release, and are thinking seriously about separating out the code for the soaplib client. Supporting the soaplib client is not a priority for us given that suds works well, and the client tests are failing. We don't want to produce a release which includes failing tests.
We can treat soaplib as a namespace package, as long as the existing soaplib's top level __init__.py does not contain any code. That would open the door to other soaplib.* packages, giving us the following family: soaplib -- the main package which still includes the server, services, models, etc. Top level namespace entities need to be relocated. soaplib.client -- the lxml-based alternative to suds (still experimental) soaplib.zope -- support for Zope and accompanying tests soaplib.0mq -- support for 0mq and accompanying tests Each of these will be a separate repo under the soaplib organization in GitHub. Only soaplib and soaplib.zope will be maintained with PyPI releases, unless someone else volunteers to handle releases for soaplib.client and soaplib.0mq. I'll grant the necessary GitHub access to any such volunteers. Any opinions/thoughts? _______________________________________________ Soap mailing list [email protected] http://mail.python.org/mailman/listinfo/soap
