[Qgis-user] Shared/common library for PyQGIS scripts

[Raymond Nijssen]

If the code snippets are not suitable for the cookbook (because they are 
too odd cases and/or they do not match the cookbook chapters) and you 
decide to put them anywhere else, it would be good practice to add the 
QGIS version number somewhere.

Raymond

On 20-10-2020 11:20, Charles Dixon-Paver wrote:
> I agree that the cookbook is a great resource (which is why I put it 
> first on my list), but I think it's better suited to general examples 
> and giving a solid outline of the best practices. If it's not kept 
> concise, it could become a bit of a convoluted mess, in addition to all 
> the broken code issues Richard raises.
> 
> As much as it provides a place for scripts that have common use cases, 
> there are some scripts I feel are useful to the community that have no 
> place there, nor do they warrant their own plugin.
> 
> For example, if you wanted to print out a list of all the typefaces used 
> in a project, AFAIK there's a fair number of nested attributes you have 
> to loop through which I expect a novice would find rather challenging. 
> At the same time, this hardly seems a relevant use case for the 
> cookbook. In GIS, I find a lot of people who aren't developers find 
> themselves with a need to leverage code, so having a way to support 
> copy-paste programmers is beneficial in my view, but maybe that's just me.
> 
> 
> 
> On Tue, 20 Oct 2020 at 10:59, Richard Duivenvoorde <rdmailings at duif.net 
> <mailto:rdmailings at duif.net>> wrote:
> 
>     On 10/20/20 10:48 AM, Jorge Gustavo Rocha wrote:
>      > Hi,
>      >
>      > I think the PyQGIS Cookbook is the perfect place to share these
>     scripts. The Cookbook is not the API reference documentation. It is
>     the place to share solutions for common problems using the QGIS API.
> 
>     While I agree with this, note that it currently is not 'simple' to
>     paste some scripts in the cookbook.
> 
>     Because the cookbook became ... uh a mess, because there were
>     non-running old examples in it, the cookbook is now build in a way
>     that the examples IN the cookbook are actually ran/tested
>     (against/in a Docker QGIS instance). This means that if some api
>     changes, the build of the cookbook of the examples using that api
>     would make the build fail. Which is a good check.
> 
>     But... it also means that 'just copy pasting' some handy examples is
>     not so easy. You have to make sure that there is data to work with,
>     or make some mockup first to be able an example etc etc...
> 
>     So: yes, the cookbook is a good place to showoff use of PyQGIS
>     examples (and to show the use of (sometimes not so intuitive) PyQGIS
>     api)... but for practical examples, it takes (for an average PyQGIS
>     user) maybe too much energy?
> 
>     OR (not sure if that is possible) we should add some 'sketchy' page
>     where indeed people can add working examples and which are not
>     tested... (and which will probably become stale and nobody cares to
>     fix them... like the old cookbook examples)
> 
>     Not sure what others think about this though...
> 
>     Regards,
> 
>     Richard Duivenvoorde
>     _______________________________________________
>     Qgis-user mailing list
>     Qgis-user at lists.osgeo.org <mailto:Qgis-user at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> 
> 
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>