[QGIS-Developer] Processing 2.x API and 4.0 regrets

Nyall Dawson nyall.dawson at gmail.com
Mon Jan 19 15:15:54 PST 2026


Hey list,

Soo.. back when we were planning 4.0 and deciding if we would break any of
the QGIS api, we made the decision that none of the existing deprecated API
was particularly painful and could be dragged along with 4.x without too
much effort.

I've come to the realisation that there's an exception here -- the old
Processing 2.x purely python based API for custom parameter GUI widgets.
This is/was a pure Python API that was kept in 3.0, because at that stage
we hadn't yet moved any of the Processing GUI classes to c++. When the c++
GUI classes were introduced we had to keep a lot of crufty code and Python
messiness to avoid breaking this. It's been painful to drag through to
3.44, and it's going to be even more painful to maintain throughout 4.x.
(Especially given the heavy churn that's currently going on in the model
designer, eg https://github.com/qgis/QGIS/pull/64591).

In retrospect I think we should have made an exception to the "no PyQGIS
API breakage for 4.0" rule and dropped all of that old API for 4.0.
Unfortunately it's too late to do this now -- it's not as simple as just
deleting a bunch of deprecated code. Rather the roots of the hackiness and
old API are very deep, and there's a non-trivial amount of (complex,
challenging) work associated with pulling out these roots.

So -- I'd like to propose that we approach this by making it very clear in
the 4.0 release notes that the old Processing 2.x API is considered
completely deprecated, that it is no longer considered part of stable API,
and that it WILL be removed at some stage during the lifespan of 4.x. We
don't advertise a fixed schedule for this, but state that "When preparing
for 4.0 support, plugin authors should port their plugins away from the
deprecated Processing GUI API to ensure that they will work for all future
4.x releases".

This would buy us time to do a proper considered removal of that API, while
ensuring that we aren't blocked from implementing nice changes to
Processing and the modeler when that API becomes impossible to work around
anymore.

Thoughts?

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260120/6e16a294/attachment.htm>


More information about the QGIS-Developer mailing list