<div dir="ltr">Also +1 for deprecation plus removal during the lifecycle of QGIS 4.<div><div>I'd also be in favor of embracing this approach more widely, like Even proposed.</div></div><div>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.</div><div><br></div><div>Matthias</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 20, 2026 at 10:34 AM Loïc BARTOLETTI via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+1 <br>
<br>
On 20/01/2026 09:35, Alessandro Pasotti via QGIS-Developer wrote:<br>
>I agree with Even:<br>
>deprecation with a clear warning seems the best solution.<br>
><br>
>On Tue, Jan 20, 2026 at 12:29 AM Even Rouault via QGIS-Developer<br>
><<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank">qgis-developer@lists.osgeo.org</a>> wrote:<br>
>><br>
>> Nyall,<br>
>><br>
>> I don't have particular knowledge about that bit, but your plan sounds<br>
>> good. Is there a way we could emit runtime deprecation warning "You are<br>
>> using a deprecated QGIS 2 Python API for custom parameter GUI widgets<br>
>> that is going to be removed in a later QGIS 4.x release. Proceed to<br>
>> migrating it to newer C++ based processing classes ASAP" (or something<br>
>> like that) that would be user visible (in log panel e.g., or maybe even<br>
>> a notification. Bonus point if we can mention the component/plugin that<br>
>> triggered the warning). Generally I think this strategy could be used in<br>
>> other similar instances. Gradual removal of advertized deprecated APIs<br>
>> rather than doing everything at once during n->n+1 upgrades might be<br>
>> more practical for us to do<br>
>><br>
>> Even<br>
>><br>
>> Le 20/01/2026 à 00:15, Nyall Dawson via QGIS-Developer a écrit :<br>
>> > Hey list,<br>
>> ><br>
>> > Soo.. back when we were planning 4.0 and deciding if we would break<br>
>> > any of the QGIS api, we made the decision that none of the existing<br>
>> > deprecated API was particularly painful and could be dragged along<br>
>> > with 4.x without too much effort.<br>
>> ><br>
>> > I've come to the realisation that there's an exception here -- the old<br>
>> > Processing 2.x purely python based API for custom parameter GUI<br>
>> > widgets. This is/was a pure Python API that was kept in 3.0, because<br>
>> > at that stage we hadn't yet moved any of the Processing GUI classes to<br>
>> > c++. When the c++ GUI classes were introduced we had to keep a lot of<br>
>> > crufty code and Python messiness to avoid breaking this. It's been<br>
>> > painful to drag through to 3.44, and it's going to be even more<br>
>> > painful to maintain throughout 4.x. (Especially given the heavy churn<br>
>> > that's currently going on in the model designer, eg<br>
>> > <a href="https://github.com/qgis/QGIS/pull/64591" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/64591</a>).<br>
>> ><br>
>> > In retrospect I think we should have made an exception to the "no<br>
>> > PyQGIS API breakage for 4.0" rule and dropped all of that old API for<br>
>> > 4.0. Unfortunately it's too late to do this now -- it's not as simple<br>
>> > as just deleting a bunch of deprecated code. Rather the roots of the<br>
>> > hackiness and old API are very deep, and there's a non-trivial amount<br>
>> > of (complex, challenging) work associated with pulling out these roots.<br>
>> ><br>
>> > So -- I'd like to propose that we approach this by making it very<br>
>> > clear in the 4.0 release notes that the old Processing 2.x API is<br>
>> > considered completely deprecated, that it is no longer considered part<br>
>> > of stable API, and that it WILL be removed at some stage during the<br>
>> > lifespan of 4.x. We don't advertise a fixed schedule for this, but<br>
>> > state that "When preparing for 4.0 support, plugin authors should port<br>
>> > their plugins away from the deprecated Processing GUI API to ensure<br>
>> > that they will work for all future 4.x releases".<br>
>> > This would buy us time to do a proper considered removal of that API,<br>
>> > while ensuring that we aren't blocked from implementing nice changes<br>
>> > to Processing and the modeler when that API becomes impossible to work<br>
>> > around anymore.<br>
>> > Thoughts?<br>
>> ><br>
>> > Nyall<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > QGIS-Developer mailing list<br>
>> > <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>><br>
>> --<br>
>> <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
>> My software is free, but my time generally not.<br>
>><br>
>> _______________________________________________<br>
>> QGIS-Developer mailing list<br>
>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
><br>
>-- <br>
>Alessandro Pasotti<br>
>QCooperative:  <a href="http://www.qcooperative.net" rel="noreferrer" target="_blank">www.qcooperative.net</a><br>
>ItOpen:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
>_______________________________________________<br>
>QGIS-Developer mailing list<br>
><a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>