<div dir="ltr">Hi !<div><br></div><div>Thanks Sebastian for willing to work on this !</div><div><br></div><div>I'd suggest drafting a QEP already, as adding support for pip/conda dependencies (which would be awesome !!) raises a few important questions (for example whether we have virtualenvs or similar on all systems, how plugins would declare their deps, how to deal with incompatible deps, or if we even go one step further and support distribution qgis plugin as pip packages, etc...). And there may be some other ideas around worth sharing at an early stage (such as proper multiple plugin versions support, also improving the plugin repository API - which by the way is also Python code, etc).</div><div><br></div><div>As for the Python or C++ discussion, I don't have enough experience to help decide, but what's sure is that either will be better than status quo in terms of maintenance !</div><div><br></div><div>Cheers,</div><div><br></div><div>Olivier</div><div><br></div><div></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 16 Mar 2020 at 12:10, Sebastian M. Ernst <<a href="mailto:ernst@pleiszenburg.de" target="_blank">ernst@pleiszenburg.de</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">Hi Nyall, Paolo, Alexander, Javier,<br>
<br>
> The issues we see most often stem not from any particular use of<br>
> Python, but (as Matthias has pointed out) through the nature of<br>
> Pythons weak typing and lack of compile time checks. A simple example:<br>
> if I alter the signature of a virtual method in one of the c++ classes<br>
> to add an extra argument or change a return type, I'll know right away<br>
> (well, when I next compile) if I've broken some existing code. If I do<br>
> the same in Python, I'm basically trusting that my particular IDE can<br>
> correctly identify ALL use of that method, because I won't get any<br>
> warning if I did break something. Unit tests help, but will never<br>
> completely avoid this kind of breakage.<br>
<br>
agreed. One can significantly reduce the risk with the right tooling, a<br>
lot of discipline, experience and tests. But one can never rule this<br>
sort of thing out entirely. It is the nature of what Python allows you<br>
to do (whether or not some of this stuff can be considered good or bad<br>
practice) vs. what static analysis tools can understand. Most of what I<br>
am interested in doing here does not require pitch-black Python magic,<br>
so a good tool-chain should be able to handle it if the code is written<br>
adequately (at least in my personal experience).<br>
<br>
Javier, you alluded on type hints. Yes, they are one of the interesting<br>
options one has in modern Python. And if your code is not too<br>
performance-critical, there are actually ways to make the interpreter<br>
respect then at run-time, i.e. Python with static types in<br>
function/method signatures :) None of this is currently being used in QGIS.<br>
<br>
> Another HUGE factor with Python+QGIS is that the actual methods of<br>
> creating the Python bindings + the PyQt library itself is a mysterious<br>
> black box, full of weird inconsistencies, random results, memory<br>
> mismanagement and crashy code practices. I shudder to think of the<br>
> amount of time I've wasted fighting with SIP and its unpredictable<br>
> behavior. You could write the BEST Python code the world has ever<br>
> seen, using all the Python best practice coding techniques you want,<br>
> and you'll still hit random regressions and issues due to these<br>
> libraries. QGIS c++ code is just MUCH more predictable, transparent,<br>
> and easier to debug.<br>
<br>
Ok, this sounds like serious issues with SIP. The smaller your SIP<br>
interface is, the smaller your surface of attack becomes. Which makes me<br>
wonder ... even if you shift as much of QGIS' logic from Python to C++,<br>
you'll always be stuck with some SIP due to your Python integration and<br>
the plugin ecosystem. From what I have seen, QGIS (in its current form)<br>
is the ultimate stress-test for SIP as in QGIS does some really wild<br>
stuff with it. Would not it make sense to clean up a lot of those SIP<br>
interfaces and limit them to what actually makes sense?<br>
<br>
> But please please please can I ask you to seriously reconsider your<br>
> approach? I've been working on this project for nearly 10 years now,<br>
> and my experience time and time again is that large blocks of Python<br>
> code in QGIS end up unstable. Modern c++ + qt is really not that much<br>
> trickier to write then Python, and if you include good test coverage,<br>
> then the code becomes almost self-maintaining*.<br>
<br>
I have not seen any self-maintaining code in my life ;)<br>
<br>
Personally, but that's just a non-technical preference, I am way faster<br>
& better with prototyping / developing in Python than I am in C++. I<br>
usually port code away from Python in a later work step once stuff is<br>
working (and tested). Other than that, while understanding your points,<br>
I can still see how a Python solution / prototype could make sense from<br>
a technical perspective and still address your concerns. Allow me to<br>
elaborate on it.<br>
<br>
I want to manage Python plugins, Python packages and Python dependencies<br>
as well as load, unload and inspect Python code while remaining on top<br>
of things by catching and treating all possible exceptions in this<br>
process. Therefore, I want to work closely with some Python modules,<br>
e.g. `ast`, `inspect`, `importlib` and `conda.api`. I am heavily tapping<br>
into the interpreter for that. The closer I remain to my objective, the<br>
more flexibility I have and the more stability I gain. Even if I move as<br>
much as possible over to C++, i.e. the GUI and some logic, the actually<br>
required Python layer (plus C++ interface code) would remain<br>
substantial. It would also lead to a convoluted logic, probably in the<br>
end only little better than the current plugin installer. This is<br>
precisely what I want to get away from. Having said that, the plugin<br>
manager is - from my perspective at least - different from processing or<br>
the db manager. They are significantly different technical problems.<br>
While I agree with you that, due to SIP, it is a good idea to move as<br>
much of processing and db manager over to C++, I am thinking that going<br>
the opposite direction specifically *here* makes more sense. While QGIS<br>
is a hybrid, I'd attempt to limit my exposure to SIP by limiting my<br>
interaction with QGIS (and PyQt) APIs to a bare minimum. After all, I<br>
see a good plugin manager more as an "independent" Python package (with<br>
all of its typical infrastructure) than something that is heavily woven<br>
into QGIS core (while it might actually be distributed / deployed with<br>
QGIS core).<br>
<br>
How does this sound?<br>
<br>
Best regards,<br>
Sebastian<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></blockquote></div>