Welcome to Spyne documentation! We hope you find it useful. Please do not hesitate to get in touch with us if you think you can help us improve Spyne or its documentation one way or another. Contact information is below.
Spyne aims to save the protocol implementers the hassle of implementing their own remote procedure call api and the application programmers the hassle of jumping through hoops just to expose their services using multiple protocols and transports.
In other words, Spyne is a framework for building distributed solutions that strictly follow the MVC pattern, where Model = spyne.model, View = spyne.protocol and Controller = user code.
Spyne comes with the implementations of popular transport, protocol and interface document standards along with a well-defined API that lets you build on existing functionality.
Spyne currently supports the WSDL 1.1 interface description standard, along with SOAP 1.1 and the so-called HttpRpc, XmlDocument, JsonDocument, YamlDocument, MessagePackDocument and MessagePackRpc protocols which can be transported via Http or ZeroMQ. The transports can be used in both a client or server setting.
The following are the primary sources of information about spyne:
Spyne is a generalized version of a Soap library known as soaplib. The following legacy versions of soaplib are also available in the source repository at github as branches:
Spyne is known to work on Python versions 2.6 and 2.7. We’re also looking for volunteers to test Python 3.x.
The only hard requirement is pytz which is available via pypi.
Additionally the following software packages are needed for various subsystems of Spyne:
You are advised to add these as requirements to your own projects, as these are only optional dependencies of Spyne, thus not handled in its setup script.
You can get spyne via pypi:
or you can clone from github:
git clone git://github.com/arskom/spyne.git
or get the source distribution from one of the download sites and unpack it.
To install from source distribution, you should run its setup script as usual:
python setup.py install [--user]
To run the tests use:
pyhon setup.py test
The test script first installs every single library that Spyne integrates with, in the current directory, so be ready to do some fiddling with your distro’s package manager in case you don’t want this, or have a fully functional python development environment ready so that packages like lxml can compile.
Finally if you want to make any changes to the Spyne code, just use
python setup.py develop [--user]
so that you can painlessly test your patches.
The main developers of Spyne lurk in the official soap implementors forum kindly operated by python.org. That’s mostly because Spyne is the continuation of soaplib, but also because Soap is an important part of Spyne.
You can also use the ‘spyne’ tag to ask questions on Stack Overflow.
If you wish to contribute to Spyne’s development, create a personal fork on GitHub. When you are ready to push to the upstream repository, submit a pull request to bring your work to the attention of the core committers. They will respond to review your patch and act accordingly.
To save both parties time, make sure the existing tests pass. If you are adding new functionality or fixing a bug, please have the accompanying test. This will both help us increase test coverage and insure your use-case is immune to feature code changes. You could also summarize in one or two lines how your work will affect the life of Spyne users in the CHANGELOG file.
Please follow the PEP 8 style guidelines for both source code and docstrings.
Regular contributors may be invited to join as a core Spyne committer on GitHub. Even if this gives the core committers the power to commit directly to the core repository, we highly value code reviews and expect every significant change to be committed via pull requests.
Github’s pull-request feature is awesome, but there’s a subtlety that’s not totally obvious for newcomers: If you continue working on the branch that you used to submit a pull request, your commits will “pollute” the pull request until it gets merged. This is not a bug, but a feature – it gives you the ability to address reviewers’ concerns without creating pull requests over and over again. So, if you intend to work on other parts of spyne after submitting a pull request, please do move your work to its own branch and never submit a pull request from your master branch. This will give you the freedom to continue working on Spyne while waiting for your pull request to be reviewed.