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

[Alessandro Pasotti]

I agree with Even:
deprecation with a clear warning seems the best solution.

On Tue, Jan 20, 2026 at 12:29 AM Even Rouault via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> 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.
>
> _______________________________________________
> 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



-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it