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

[Even Rouault]

Nyall,

I don't have particular knowledge about that bit, but your plan sounds 
good. Is there a way we could emit runtime deprecation warning "You are 
using a deprecated QGIS 2 Python API for custom parameter GUI widgets 
that is going to be removed in a later QGIS 4.x release. Proceed to 
migrating it to newer C++ based processing classes ASAP" (or something 
like that) that would be user visible (in log panel e.g., or maybe even 
a notification. Bonus point if we can mention the component/plugin that 
triggered the warning). Generally I think this strategy could be used in 
other similar instances. Gradual removal of advertized deprecated APIs 
rather than doing everything at once during n->n+1 upgrades might be 
more practical for us to do

Even

Le 20/01/2026 à 00:15, Nyall Dawson via QGIS-Developer a écrit :
> 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

-- 
http://www.spatialys.com
My software is free, but my time generally not.