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

[Alexander Bruy]

+1 to drop the old Processing 2.x API in the future 4.x release.

But as mentioned by Even and Alessandro, it would be nice to make this
deprecation warning clearly visible.

пн, 19 січ. 2026 р. о 23:16 Nyall Dawson via QGIS-Developer
<qgis-developer at lists.osgeo.org> пише:
>
> 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
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alexander Bruy