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

[Matthias Kuhn]

Also +1 for deprecation plus removal during the lifecycle of QGIS 4.
I'd also be in favor of embracing this approach more widely, like Even
proposed.
I'd like to have the possibility to make deprecation user visible warnings
in prod installations (typical desktop, server installations) and have it
raise an exception when run in a typical test/ci environment.

Matthias

On Tue, Jan 20, 2026 at 10:34 AM Loïc BARTOLETTI via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> +1
>
> On 20/01/2026 09:35, Alessandro Pasotti via QGIS-Developer wrote:
> >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
> >_______________________________________________
> >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
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260120/c37227f3/attachment-0001.htm>