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

[Nyall Dawson]

On Tue, 20 Oct 2020 at 19:40, Raymond Nijssen <r.nijssen at terglobo.nl> wrote:
>
> 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.

If I can make one other suggestion here, it's that someone manages the
collection of scripts with an "iron fist"!

I've seen previous efforts in collecting PyQGIS helper functions tend
to bloat out and become unmanageable because they end up being a
random collection of very mixed quality and utility. I would
personally attribute this to the collection's maintainers being too
friendly, and accepting the majority of contributions sent in. While
it doesn't sound nice to phrase it this way I think having someone be
very picky and selective about the quality and type of submissions
which are permitted into the collection is ultimately a good thing.

Specifically, I'd suggest putting some firm guidelines in place about
what's acceptable, so that submitters know upfront about what type of
scripts will be accepted and there's no misunderstanding. Some ideas
could be:

- No scripts which duplicate inbuilt PyQGIS (or PyQt) functionality.
(E.g. no scripts for a slightly different way of retrieving project
layers vs what QgsProject gives, no reimplementation of built in
widgets such as field selection combo boxes, etc).
- Scripts should rely as heavily as possible on existing PyQGIS
methods in order to minimise the amount of Python code required
- Since it's a PyQGIS based collection, scripts should use QGIS
classes wherever possible, even if the result might be less
performant. E.g. no use of other libraries like shapely, rasterio,
pandas, raw gdal calls, use QgsNetworkAccessManager instead of the
python requests library, etc. If a script is designed to use these
libraries then I'd suggest having a separate collection for them!

Just my 2c :)
Nyall


>
> 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
> >
> _______________________________________________
> 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