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

[Loïc BARTOLETTI]

+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