PyWPS-4.2.0 Released

At long last, a new PyWPS release is out. A new chapter in the PyWPS 4 story is now complete and as 2018 comes to an end, it is time to look back at what happened since the major release in December of 2016.

PyWPS remains fully reliant on pro bono contributions without any sort of commercial organisation around it. This means the project largely depends on how the community is able to contribute at any given time. However, it also means there are no clients to attend or shareholders to appease, no hard deadlines or sales demos. PyWPS evolves organically, to the tune of the community’s wishes.

Relying on voluntary contributions does not mean progress is slow, much to the contrary. In recent times PyWPS has had more simultaneous contributors than at any moment before in its history. This is largely due to the major step taken with PyWPS 4 towards modern Python technologies, but also to regular contributions from the Google Summer of Code (GSoC) programme and various students thesis. During these two years the Project Steering Committe (PSC) was expanded to six members, and last May PyWPS finally graduated as an OSGeo project.

In order to manage development, the Project Steering Committe (PSC) meets regularly (usually at FOSS4G events) and performs basic housekeeping: issues are reviewed and split among a series of milestones that set out a development plan. As development progresses, new issues naturally pop up, and there is always a patch or an improvement that developers wish to include in the next release. Like the Red Queen from Alice in Wonderland, the backlog for the next release seems to always have as many issues resolved as new ones to resolve. Time drags on and the perfect tidy release remains ellusive. So in the end PyWPS 4.2 is mostly a commemorative release, celebrating two years since the major release and making official all the improvements introduced since.

What are then the main improvements introduced with PyWPS 4.2? Foremost is the progressive improvement of the class model, step by step making the library more solid, agile and easier to maintain. Among other things, the input/output handling classes were refactored, the test battery was expanded and streamlined with continuous integration tools. Other relevant improvements include:

• Introduction of Jinja2 templates to automate the generation of outputs.
• Support for process execution in HPC environments, using Slurm or GridEngine.
• Support for streamed URL-based data inputs (e.g. OpenDAP).
• Automated process documentation with Sphinx.
• New validators for JSON, DODS links and netCDF formats.

And along the way, many bugs were fixed.

The organic nature of the project has meant that the goals set out by the PSC are not always met. For instance, PyWPS 4.2 still does not fully support version 2 of the WPS standard. But such is the nature of community driven projects: evolution goes along the needs of the community and not necessarily according to grand plans. There are instead other great improvements in the pipeline, like the containerisation of processes, or the automatic storage of outputs in a database. Please get involved if these developments interest you, or if you would like other improvements to be introduced.

A word also regarding the WSGI applications provided as example services using PyWPS. pywps-flask remains the most popular but a backlog of small issues has built up. During the holiday season developers will be lending attention to these issues. Usability issues with the containers of both pywps-flask and pywps-django will also be addressed during this time.

Finally the PSC would like to thank everyone that has contributed to PyWPS these past two years: from those doing the code heavy lifting, to testers, bug reporters, documentation contributors. Every bit of contribution is precious. Thank you all for making PyWPS what it is today!

Merry Christmas and a Happy New Year.