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
[email protected]
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
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
