<div dir="ltr">I strongly agree with Nyall analysis about versioning. We had similar problems in Boundless when adding new features to already available modules... there weren't a simple way to load a specific module version, especially when these different version are available in different python plugins all listed in the pythonpath.<div>The simples solution was to version the module from qgiscommon to qgisocmmon2 and rebuild all in-house plugin at averey update tof qgisocmmons. Something impossibile with third party plugin, in Boundless case we had control on deployment and packaging of the product, something radically different for the standard QGIS.</div><div>So I would link the package version to QGIS version avoiding a different relase math and versioning.</div><div><br></div><div>I also agree to avoid ti add snippets that can be solved usign core API. </div><div>Btw, for the case of NetworkAccessManager it was introduced to allow upgrade comnon plugins using QgsNetowkrAccessManager or requests to use the integrated auth system, something hard to describe into a docstring... btw I documented it in the PyQGIS coockbook in the auth system paragraphs.</div><div><br></div><div>cheers</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Luigi Pirelli<br><br>**************************************************************************************************<br>* LinkedIn: <a href="https://www.linkedin.com/in/luigipirelli" target="_blank">https://www.linkedin.com/in/luigipirelli</a><br>* Stackexchange: <a href="http://gis.stackexchange.com/users/19667/luigi-pirelli" target="_blank">http://gis.stackexchange.com/users/19667/luigi-pirelli</a><br>* GitHub: <a href="https://github.com/luipir" target="_blank">https://github.com/luipir</a><br>* Mastering QGIS 2nd Edition:<br>* <a href="https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition" target="_blank">https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition</a><br>* Hire me: <a href="http://goo.gl/BYRQKg" target="_blank">http://goo.gl/BYRQKg</a><br>**************************************************************************************************</div></div>
<br><div class="gmail_quote">On 6 April 2018 at 01:55, Nyall Dawson <span dir="ltr"><<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 April 2018 at 05:06, Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net">rdmailings@duif.net</a>> wrote:<br>
<br>
> So my main point:<br>
> - how to give everybody the possibilty to implement a locator class, BUT<br>
> also share a common base class or use the same QgsNetworkAccessManager<br>
> moduel?<br>
><br>
> Some options:<br>
> - we create a separate repo for 'common' python classes, and via git<br>
> submodules everybody pulls in it's own copy of those classes<br>
> - we create a common-qgis-python module which would ship with QGIS (with<br>
> filterbaseclass, QgsNetworkAccessManager, and other ideas from the<br>
> Boundless commons lib).<br>
<br>
</span>My concern with the second approach is (and always has been) that<br>
these common modules effectively become part of the stable API. We'd<br>
need to carefully decide on things like:<br>
<br>
- how are releases of the module handled? Is it bound to QGIS<br>
releases, or on its own release schedule?<br>
- Would the module be versioned (i.e. if it's not tied into QGIS<br>
releases and packaged accordingly, will the code need to work with any<br>
QGIS version from 3.0 up?)<br>
<br>
We'd also need to very carefully vet all contributions to this module,<br>
to ensure that they aren't reproducing functionality which is already<br>
present in the core/gui modules. A lot of the code in common python<br>
modules I've seen is just re-implementations of widgets and classes<br>
which are already present in the master codebase, and which should<br>
always be used instead. If Python syntactical sugar is desired for<br>
these existing c++ classes then I'd much prefer to see it implemented<br>
in the core QGIS module, such as is done here:<br>
<br>
- <a href="https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L192" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>blob/master/python/core/__<wbr>init__.py#L192</a><br>
- <a href="https://github.com/qgis/QGIS/blob/master/src/core/qgsreadwritecontext.h#L84" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>blob/master/src/core/<wbr>qgsreadwritecontext.h#L84</a><br>
(Via <a href="https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L216" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>blob/master/python/core/__<wbr>init__.py#L216</a><br>
and<br>
- <a href="https://github.com/qgis/QGIS/blob/master/src/core/qgsproject.h#L1316" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>blob/master/src/core/<wbr>qgsproject.h#L1316</a><br>
(via <a href="https://github.com/qgis/QGIS/blob/master/python/core/__init__.py#L240" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/<wbr>blob/master/python/core/__<wbr>init__.py#L240</a>)<br>
<br>
This is a nice approach to adding standard Python coding patterns into<br>
the QGIS API, with the benefit that it's already tied into the QGIS<br>
releases, packaged accordingly, and are all unit tested on Travis.<br>
Maybe the same approach should be taken for adding the network access<br>
manager.<br>
<br>
Just my 2c!<br>
<span class=""><br>
> PS, wannatry? Download<br>
> <a href="https://github.com/rduivenvoorde/qgislocator/raw/master/qgislocator_0.1.1.zip" rel="noreferrer" target="_blank">https://github.com/<wbr>rduivenvoorde/qgislocator/raw/<wbr>master/qgislocator_0.1.1.zip</a><br>
> and use Install from ZIP in the plugin manager. Use '2022zj' to search<br>
> PDOK, or 'eiffel' to search Google. Note that you may need a google key<br>
> to use their geocoder.<br>
<br>
</span>Yep, can't wait to give this a spin :)<br>
<span class="HOEnZb"><font color="#888888"><br>
Nyall<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org">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/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
______________________________<wbr>_________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org">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/<wbr>mailman/listinfo/qgis-<wbr>developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/qgis-<wbr>developer</a></div></div></blockquote></div><br></div>